universidad de chile facultad de ciencias físicas y matem

Transcription

UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN
UN MODELO ABIERTO DE PROXIMIDAD PARA EL DESCUBRIMIENTO DE
SERVICIOS EN COMPUTACIÓN PERVASIVA
TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN CIENCIAS,
MENCIÓN COMPUTACIÓN
MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN
COMPUTACIÓN
VICTOR ALEJANDRO RAMIRO CID
PROFESOR GUÍA:
ÉRIC TANTER
MIEMBROS DE LA COMISIÓN:
JOHAN FABRY
PATRICIO INOSTROZA FAJARDIN
LUCIANO AHUMADA FIERRO
SANTIAGO DE CHILE
JUNIO 2009
Resumen
La relación entre personas y computadores ha cambiado dramáticamente en los últimos años.
Hoy en dı́a las personas interactúan, cada vez más, con un mayor número de dispositivos, como
el computador personal, notebook, reproductores musicales y de video, celulares, etc. Estos dispositivos a su vez han empezado a interactúar entre ellos, compartiendo información o proveyendo
servicios para ser usados por otros dispositivos. En particular, se espera que ellos se comuniquen
de manera distribuida en el ambiente.
En esta clase de sistemas distribuidos es muy importante soportar de manera fácil la publicación y descubrimiento de servicios. El descubrimiento de estos puede ser una tarea relativamente
compleja en un ambiente donde interactúan muchos dispositivos. Es por ello que distintos enfoques
han sido desarrollados para proveer dicho soporte de manera de limitar las interacciones superfluas.
El desarrollo de soluciones ha ido desde la investigación en sistemas distribuidos y desarrollo de
middleware especı́fico hasta nuevas abstracciones en lenguajes de programación.
Sin embargo, el estado del arte no contempla un sistema abierto y flexible que permita, tanto
al dispositivo cliente como al dispositivo servidor, filtrar conexiones basadas particularmente en
contenidos de interés definidos por el usuario. Este contenido de interés se puede definir como
la proximidad entre un cliente y un servidor. El concepto de proximidad se asocia al estado de
cercanı́a, como la percepción de estar cerca de algo o de alguien. En general, en el estado del arte
se presentan herramientas donde, o bien no se filtra absolutamente nada, o solamente el cliente
es capaz de filtrar basado en el contenido de su interés. Esto sin considerar el carácter dinámico
del grafo de conexiones que simplemente no se toma en cuenta, y por lo tanto no se permite la
actualización de la relación de proximidad entre dispositivos.
Este trabajo presenta el diseño de un modelo abierto de proximidad. La integración de este
modelo con el descubrimiento de servicios permite definir, a través de funciones de proximidad,
el alcance de la búsqueda del cliente y de la publicación del servidor. Presentamos las componentes necesarias para definir la noción de “relaciones de proximidad”. Dicha relación considera
los cambios periódicos que ocurren entre nodos en una red ad-hoc. Además se presenta la semántica
distribuida de las relaciones y tres estrategias para implementarlas. Estas estrategias muestran, en
base a un análisis de peor caso, las decisiones de diseño tomadas entre simpleza y eficiencia.
Finalmente, se muestra la implementación de este modelo en el lenguaje de programación
AmbientTalk. Este lenguaje está altamente especializado en el desarrollo de sistemas orientados
al ambiente y provee soporte para desarrollar nuevas abstracciones y construcciones que permiten
experimentar con modelos como el propuesto. Además presentamos un análisis experimental del
descubrimiento de servicios de AmbientTalk y lo comparamos con nuestro modelo abierto de proximidad. Esta comparación nos muestra como el modelo abierto de proximidad disminuye las interacciones innecesarias, permitiendo definir una noción flexible de proximidad entre servicios que se
descubren en el ambiente.
Agradecimientos
Escribir esta tesis ha sido un paso muy importante, un gran final para el termino de una hermosa
etapa de mi vida. Es casi imposible enumerar a todas las personas que me han apoyado, de una u
otra forma, en el desarrollo de ésta, y menos aún describir las infinitas ayudas que recibı́ de ellos,
pero sin duda puedo resumir acá unas mı́nimas palabras que muestran mi infinito agradecimiento
hacia ellos.
Primero quiero agradecer el incondicional apoyo de mi familia, y por sobre todas las cosas el
gran esfuerzo que hicieron en inculcarme el gusto por aprender y estudiar. Gracias Mamá, gracias
Papá. Su apoyo siempre ha sido imprescindible para cada paso que he dado en mi vida. A mis
hermanos, gracias por hacer más fácil el pasar por la universidad, gracias por compartir una risa,
una conversación, un minuto de tranquilidad. Palabras especiales tengo para mi amada Cata, quien
ha sabido acompañarme fielmente durante todo este proceso. Muchas gracias por tu comprensión
y por todo el tiempo que te he robado.
Segundo quiero agradecer a mis amigos. A los largo de estos años he aprendido que no hay nada
mejor que trabajar con ellos. Los de siempre, desde el plan común hasta el DCC: Hernan Figueroa,
Javier Miranda, Daniel Valenzuela, Valentina Quiroga, Ignacio Ortega, Cristian Serpell, Hugo
Mora, Cristina Melo, Gustavo Garcia, Diego Bonilla, Francisco Claude, Mauricio Farah y muchos
otros. Mis amigos de PLEIAD, por sus innumerables aportes durante toda esta investigación:
Rodolfo Toledo, Paul Leger, Guillaume Pothier, Oscar Alvarez y Richard Ibarra. A la gente de la
VUB en Bélgica, que me recibió muy bien, un saludo especial para: Jessie Dedecker, Boriss Mejı́as,
Tom Van Cutsem, Elisa Gonzalez Boix, Coen De Roover, Wolfgang De Meuter, Yves Vandriessche.
A mis compañeros de Niclabs, que han soportado mi tema de tesis durante todo este tiempo: Tomás
Barros (¡gracias por todo!), Carlos Collao, Jonathan Frez y Nicolás Singh. Por último un saludo
muy especial a Angélica Aguirre que me apoyó en todo el infinito papeleo para poder terminar.
A mis profesores de la comisión les agradezco mucho por sus comentarios que permitieron
mejorar varios aspectos de la tesis, y en particular les agradezco su disposición para coordinar y
facilitar la defensa de esta tesis. Simplemente ¡me salvaron!.
Finalmente quiero agradecer a mi profesor guı́a Éric Tanter. Gracias por la oportunidad de
trabajar contigo y por todo el apoyo que me diste durante este trabajo (sobretodo en la fase final).
Gracias también por darme la oportunidad de conocer el mundo de la investigación y por las largas
conversaciones de orientación que tuvimos. Solo las vueltas de la vida dirán cuando nos volveremos
a encontrar.
Obviamente la lista no puede incluir a todos, ası́ que espero me perdonen los que se me pasaron.
Solo puedo decir gracias, gracias a todos los que me acompañaron en este camino.
Este trabajo recibió el apoyo del proyecto FONDECYT 11060493: Modularization and Adaptation of Complex and Dynamic Software Systems.
Santiago 10 de Junio de 2009
Victor Ramiro
University of Chile
Faculty of Physics and Mathematics
Graduate School
An Open Proximity Model for Service Discovery in
Pervasive Computing
by
Victor Ramiro
Submitted to the University of Chile in fulfillment
of the thesis requirement to obtain the degree of
MSc. in Computer Science
and
Engineering in Computer Science
Advisor
: Éric Tanter
Committee
: Johan Fabry
: Patricio Inostroza Fajardin
: Luciano Ahumada Fierro
Departament of Computer Science - University of Chile
Santiago - Chile
June 2009
Abstract
Interactions between people and computers have dramatically changed over the last years.
Nowadays, people interact with a larger number of devices, such as personal computers, notebooks,
music and video reproducers, cell phones, etc.. Moreover, devices have started to interact with other
devices, they may share information and provide services to be used by other devices. In particular,
they can communicate through the ambient.
An important challenge for this kind of distributed systems is to easily support the advertising
and discovery of services. Service discovery may be a hard task in environments where a lot of
services interact with each other. Several approaches have been developed to provide such support
in order to delimit the number of superfluous connections. Solutions go from distributed systems
and middleware development to new programming language abstractions.
Nonetheless, the state of the art does not include an open and flexible system that allows both
the client and the service provider to filter connections based on particular content of interest
by the user. Generally existing tools can either not define such filters, or just allow the client to
implement filtering based on content of interest. Those tools also do not take care of the dynamics
of the connection graph, which is a must in an ambient-oriented programming setting.
This thesis work presents the design of an open proximity model. Integrating this model with
service discovery allows the programmer to define the scope of both service advertising and discovery. These scopes are defined by means of proximity functions. We present the necessary components to define the notion of “proximity relationships”. Such relations take care of periodical
changes between nodes in an ad-hoc network. We also present the distributed semantics of the
relationships and three strategies to implement them. These strategies show, based on a worst case
analysis, the design decision and trade-off between simplicity and efficiency.
Finally, we present the actual implementation of the open proximity model in the AmbientTalk
language. The AmbientTalk language is highly specialized for ambient-oriented system development. AmbientTalk provides support to develop new abstractions and constructions to define such
models. We also present an experimental analysis. This analysis compares the native AmbientTalk
service discovery with the open proximity model we propose. This comparison shows how the open
proximity model decreases unnecessary connections between devices. This allows to define a flexible
notion of proximity in service discovery in the ambient.
Contents
1 Introduction
1.1 Motivation . . . .
1.2 Goals . . . . . . .
1.3 Contribution of the
1.4 Organization of the
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
3
4
4
5
2 Context
2.1 Jini and service discovery . . . .
2.1.1 Introduction . . . . . . .
2.1.2 Service discovery in Jini .
2.1.3 Summary . . . . . . . . .
2.2 AmbientTalk in a Nutshell . . . .
2.2.1 AmbientTalk objects . . .
2.2.2 Concurrent programming
2.2.3 Distributed programming
2.2.4 Metaprogramming . . . .
2.2.5 Reflection . . . . . . . . .
2.2.6 Summary . . . . . . . . .
2.3 Many-to-Many Invocation library
2.4 Related work . . . . . . . . . . .
2.4.1 Multi-agent systems . . .
2.4.2 Service discovery . . . . .
2.5 Summary . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
6
9
9
10
11
13
13
14
16
16
18
19
20
21
.
.
.
.
.
22
22
23
24
24
25
. . . .
. . . .
thesis
thesis
.
.
.
.
.
.
.
.
.
.
.
.
3 The Open Proximity Model
3.1 Proximity definition . . . . . . . . . . . .
3.1.1 Physical vs. Abstract proximity . .
3.1.2 Composite proximity . . . . . . . .
3.1.3 Objective vs. Subjective proximity
3.2 Requirements for proximity relationships .
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.3
3.4
3.5
Open proximity model for scoping service discovery
3.3.1 Service discovery . . . . . . . . . . . . . . .
3.3.2 Model components . . . . . . . . . . . . . .
3.3.3 Distributed evaluation semantics . . . . . .
3.3.4 Evaluation strategies . . . . . . . . . . . . .
Discussion and conclusions . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 The Open Proximity Model in AmbientTalk
4.1 Service Discovery in AmbientTalk . . . . . . . . . . . . . . . . . . . .
4.2 Open Proximity Model in AmbientTalk . . . . . . . . . . . . . . . .
4.2.1 Primitives for service discovery in the open proximity model .
4.2.2 Defining properties and proximity functions in AmbientTalk .
4.2.3 Extending AmbientTalk’s service discovery . . . . . . . . . .
4.2.4 Implementing the distributed evaluation strategies . . . . . .
4.2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
26
27
28
29
36
37
.
.
.
.
.
.
.
.
38
38
40
40
41
43
44
53
53
5 Experiments with the Open Proximity Model
5.1 Experiment Design . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3 Common setup . . . . . . . . . . . . . . . . . . . . . . . .
5.1.4 Uses and conflicts with Many-to-Many invocation library
5.2 Scale on number of nodes in the ambient . . . . . . . . . . . . . .
5.3 Scale on size of properties . . . . . . . . . . . . . . . . . . . . . .
5.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
55
55
56
56
57
59
61
63
64
6 Conclusions
6.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Proximity taxonomy and relationships . . . . . .
6.1.2 Open proximity model . . . . . . . . . . . . . . .
6.1.3 Open proximity model in AmbientTalk . . . . . .
6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Improvements on AmbientTalk’s implementation
6.2.2 Publish-Subscribe service discovery . . . . . . . .
6.2.3 A new communication layer for AmbientTalk . .
6.2.4 Proximity references . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
65
65
65
67
68
68
68
68
69
Bibliography
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
70
iii
List of Figures
2.1
2.2
2.3
2.4
2.5
AmbientTalk actors as communicating event loops
M2MI Omnihandle . . . . . . . . . . . . . . . . . .
M2MI Omnihandle invocation . . . . . . . . . . . .
M2MI Unihandle . . . . . . . . . . . . . . . . . . .
M2MI Unihandle invocation . . . . . . . . . . . . .
.
.
.
.
.
12
17
17
18
18
3.1
3.2
3.3
3.4
3.5
3.6
Different notions of physical proximity (B is “near” A, but C is not). . . . . . . . .
Different notions of abstract proximity . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation of proximity between server and client in basic evaluation strategy. . .
Evaluation of proximity between server and client in selective evaluation strategy.
Composite tree for the (f1 &&f2 )||(f3 &&(f4 ||f5 )) formula . . . . . . . . . . . . . .
Evaluation of proximity between server and client staged evaluation strategy. . . .
23
23
30
32
34
35
4.1
4.2
4.3
4.4
4.5
Channel architecture to communicate among peers . . .
Communication flow of the basic evaluation strategy . .
Communication flow of the selective evaluation strategy
Composite class structure . . . . . . . . . . . . . . . . .
Communication flow of the staged evaluation strategy .
.
.
.
.
.
45
48
50
51
52
5.1
5.2
5.3
5.4
5.5
Discovery process viewer for the experiments . . . . . . . . . . . . . . . . . . . . .
(Id ) Data sent over the network with increasing numbers of nodes in the graph . .
(Id ) Data sent with increasing numbers of nodes for different evaluation strategies
(It ) Discovery time with increasing number of nodes in the graph . . . . . . . . . .
(Id ) Data sent with increasing properties size . . . . . . . . . . . . . . . . . . . . .
58
60
61
62
63
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Listings
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
3.1
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
Jini interface for service exporting . . . . . . . . . . . . . . . . . . . .
Jini implementation object for service exporting . . . . . . . . . . . . .
Jini AbstractEntry extension for service match . . . . . . . . . . . . .
Jini client query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jini service filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AmbientTalk printer object definition . . . . . . . . . . . . . . . . . .
Actor creation in AmbientTalk . . . . . . . . . . . . . . . . . . . . . .
AmbientTalk asynchronous method call . . . . . . . . . . . . . . . . .
Future resolution in AmbientTalk . . . . . . . . . . . . . . . . . . . . .
M2MI omnihandle creation . . . . . . . . . . . . . . . . . . . . . . . .
M2MI unihandle creation . . . . . . . . . . . . . . . . . . . . . . . . .
Proximity definitions in YABS . . . . . . . . . . . . . . . . . . . . . .
AmbientTalk’s service discovery exporting primitives . . . . . . . . . .
AmbientTalk’s service discovery querying primitives . . . . . . . . . .
AmbientTalk’s Service Discovery patterns . . . . . . . . . . . . . . . .
AmbientTalk’s new Service Discovery exporting primitives . . . . . . .
AmbientTalk’s new Service Discovery querying primitives . . . . . . .
Properties definition in AmbientTalk . . . . . . . . . . . . . . . . . . .
Proximity function definition in AmbientTalk . . . . . . . . . . . . . .
Defining a staged proximity function . . . . . . . . . . . . . . . . . . .
Defining a staged proximity function with syntactic sugar . . . . . . .
Defining a property set object in AmbientTalk . . . . . . . . . . . . .
Function EvalDynamicProperties for the basic evaluation strategy . .
Function argumentMap for the basic evaluation strategy . . . . . . . .
Function EvalDynamicProperties for the selective evaluation strategy
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
7
7
8
8
10
12
13
13
16
18
25
39
39
39
40
41
41
42
42
43
44
46
47
49
Chapter 1
Introduction
Computer technology is becoming cheaper and cheaper. Moore’s law has affected in a drastic
way how we interact with computers. At the beginning of computer history, users and computers
were in a “many to one” relationship: working with computers was restricted to using a slice of
CPU time on large shared mainframes. The Personal Computer revolution brought us the “one
to one” relationship between users and machines. Nowadays, we are surrounded by many devices
and we interact with them as part of our everyday life: smart-phones, PDA’s, notebooks, etc.; we
are in a “one-to-many” relationship. Moreover, all these machines have incredible capabilities of
processing and communication, since they are even more powerful than the first computers. Since
interaction with one computer has been prove to be difficult to many people, today’s challenge is to
make interaction with a multitude of devices as natural as possible: we want invisible technology,
but visible intelligence. The research developed to solve such problems has been called Pervasive
computing [Wei91]1 .
All models of pervasive computing share a vision of small, inexpensive and robust networked
processing devices, distributed at all scales throughout everyday life. Pervasive computing has a
lot of challenges across computer science: systems modelling and design, user interface design,
scalability, data communication. Different approaches have been proposed to solve pervasive
computing problems: distributed computing, middleware solutions, language abstraction, etc.. In
this context, Dedecker et al. present AmbientTalk, a language designed to develop solutions in
order to satisfy the demands of pervasive software [DCM+ 05, DVM+ 06a]. AmbientTalk is meant
to serve as a platform to experiment with new language features and programming abstractions
to facilitate the construction of software that has to run in highly volatile networks exhibiting
intermittent connectivity and little infrastructure.
Software developed for pervasive computing necessarily has to be aware of its environment to a
certain degree, as well as of the various interactions that take place within this environment.
An interesting concept related with the environment is the proximity in pervasive computing
1 Also
known as Ubiquitous computing
2
1.1. Motivation
systems [Sat01, KF02]: most probably things of interest are near by (sense of scope), not in the
whole environment. Besides defining the scope of interest, introducing proximity also allows for
better scalability both at the interaction level and content of interest level.
Proximity can be defined as a state of nearest, the perception of being close to something or
someone. As a concept it naturally plays a significant role in how, as humans, we interact with our
environment. This can be observed in the relationships we maintain with others, or in the manner in
which we interact with everyday objects around us. For instance, how we hold one friendship above
another, or in the way we relate the topics of different books to each other. The actual semantics
of what it means to be close is very often reliant on the context in which it is applied. Traditional
forms of proximity in mobile ad-hoc networks are based on the physical distance between entities.
Nevertheless, some applications require different metrics to calculate proximity between entities.
Service discovery is the combination of two processes: a service query, issued by a client, and a
service advertisement, issued by a server. Typically, a service advertisement includes a number of
attributes characterizing the service, and a service query defines constraints on these attributes,
specifying what the client is looking for. Service discovery is inherently restricted to the proximity
scope in ad-hoc networks.
We propose to define explicit scopes based on proximity for both the query and advertising
processes. This allows a server to restrict its advertisements so that they are visible only to clients
within a given scope. Reciprocally, a client is able to specify the scope within which it is interested
in querying services. Only if the scope of both parties intersect can the client actually see the
service, check its specific characteristics according to the query, and start using it if appropriate.
1.1
Motivation
We introduce the idea of proximity and how this concept is of interest to the field of pervasive
computing and ambient intelligence, where the focus is on unobtrusively managing and assisting
the tasks of users. In these systems the introduction of proximity allows interactions to be bounded
locally. The approach aids scalability [Sat01] as entity interaction is scoped. In addition, the
application of proximity allows entities to demarcate content of interest [KF02] making it easier
to discover services or data that are of relevance.
For example, consider a proximity defined by a geometric distance of 10 meters and a degree of
separation between friends of 1. The former scopes interactions to a 10 meter radius and recognises
that content exceeding the boundary is of less relevance. The later demarcates content which, in
this case, are from close friends.
But the proximity concept is ambiguous. It is possible to have multiple definitions of proximity.
Even in the same device the definition may change based on specific contexts. The correct definition
of proximity eventually depends on the application that is being developed. The required notion
of proximity may be based on physical distances (i.e. physical proximity) or based on application
specific proximity definitions (i.e. abstract proximity). Computation of these notions of proximity
can require both parties to collaborate. However, since definitions of proximity are sometimes
3
1.2. Goals
application-specific it is impossible to have all these definitions pre-installed on all nodes in the
network. Hence, each node in the network can have its own definition of proximity (i.e. subjective
proximity) or can be based on a standardized notion of proximity (i.e. objective proximity).
Unfortunately, such an open application of proximity is currently not supported by the state
of the art. In contrast, we claim that open notions of proximity should be supported by pervasive
computing systems. This thesis contributes to the inclusion of the concept of proximity in an open
manner, developing an open proximity model for pervasive computing.
1.2
Goals
In order to address the above issues we propose to define a conceptual model based on an
architecture to support different notions of proximity. The goal of the conceptual model is to
support both physical and abstract notions of proximity. Furthermore, it should provide support
to combine them. This model must support the creation of idiosyncratic proximity definitions.
Hence, nodes may have different proximity definitions.
Current languages and middleware do not provide an open and extensible architecture to
address this problem. On the other hand AmbientTalk [DCM+ 05] is designed to support distributed
applications in the context of mobile computing. AmbientTalk is extensible via an open reflective
interface. This reflective interface reifies the state of the interpreter and supports the introduction
of new programming abstractions. However, AmbientTalk currently lacks a pluggable architecture
to define proximity as discussed above.
The thesis goal is to design an open proximity model and develop such model as a proximity
framework for AmbientTalk. The specific goals of this work are:
• Design an open proximity model: design a model to support both pluggable definitions of
proximity and their combination. The distributed evaluation semantics must be defined as
well.
• Implementation of the open proximity model: develop first a implementation of the open
proximity model in AmbientTalk. This implementation should cover different evaluation
strategies of the proposed model.
• Evaluation of the open proximity model: compare current AmbientTalk capabilities and the
impact of introducing support of the open proximity model.
1.3
Contribution of the thesis
The major contribution of this work is the design of an open proximity model for pervasive
computing. This model provides an easy way to define abstract notions of proximity for both client
and servers. As volatile infrastructure is the rule in pervasive computing, the open proximity model
4
1.4. Organization of the thesis
supports changes of the proximity relationships over time. A first version of the open proximity
model was published in the post-proceedings of the EEMMAS workshop [RDTB08].
The second contribution of this thesis is the AmbientTalk implementation of the open proximity
model. We show a real example of our model. We provide experiments to support the hypothesis
that an open proximity model can reduce interactions and allows applications to better demarcate
content of interest making it easier to discover services or data that are of relevance.
In addition we propose, implement, and evaluate three different evaluation strategies for our
model. This allows us to explore the trade-off between simplicity and efficiency in the model.
1.4
Organization of the thesis
This thesis is structured as follows:
• The second chapter introduces the context of this work. In particular we present several
technologies that are used as reference points in this thesis, the novel language AmbientTalk,
and some other related work.
• The third chapter presents a taxonomy of possible useful notions of proximity. We introduce
the open proximity model design, components and semantics. Three evaluation strategies are
presented to fulfil the distributed semantics.
• The fourth chapter presents the current service discovery mechanism of AmbientTalk, as well
as the implementation of the open proximity model in AmbientTalk.
• The fifth chapter presents the major results of the experiments that compare the proximity
model and its three variations with AmbientTalk’s service discovery.
• The sixth chapter distills the most important conclusions of this thesis and the perspectives
for future work.
5
Chapter 2
Context
This chapter introduces most of the concepts used in this thesis: we present Jini service discovery,
as a starting point to talk about service discovery; the AmbientTalk language, as the language used
to implement the model; the Many-to-Many Invocation Library, as the library used to implement
the communication layer.
We also include a review of the state of the art on proximity based systems to specific tools
used to implement the thesis work.
2.1
2.1.1
Jini and service discovery
Introduction
Jini [Mic] technology was developed by SUN Microsystems. It is a service oriented architecture
that defines a programming model which both exploits and extends Java technology to enable the
construction of distributed systems of well-behaved network services and clients. Jini technology
can be used to build adaptive network systems that are scalable and flexible as is typically required
in dynamic computing environments.
2.1.2
Service discovery in Jini
In order to understand the motivation for supporting open notions of proximity in our programming
infrastructure let us analyze the service discovery code of a simple application developed in Jini.
Listing 2.1: Jini interface for service exporting
1 public i n t e r f a c e P r i n t e r I n t e r f a c e extends Remote {
2
public void p r i n t J o b ( O b j e c t aJob ) throws RemoteException ;
3 }
6
2.1. Jini and service discovery
When providing a Jini service, we need to define an interface that declares the behavior
of the service, based on the declaration of a set of remote methods. In the code above, the
interface PrinterServiceInterface exposes the remote method void printJob(Object aJob).
After that, it is necessary to implement the class providing that behavior, see Listing 2.2.
Listing 2.2: Jini implementation object for service exporting
1 public c l a s s P r i n t e r S e r v i c e extends UnicastRemoteObject implements
2
PrinterInterface {
3
4
public P r i n t e r S e r v i c e ( ) throws RemoteException {
5
super ( ) ;
6
}
7
public void p r i n t J o b ( O b j e c t j o b ) throws RemoteException {
8
// do s t u f f . . .
9
}
10
public s t a t i c void main ( S t r i n g [ ] a r g s ) throws E x c e p t i o n {
11
System . s e t S e c u r i t y M a n a g e r (new RMISecurityManager ( ) ) ;
12
Entry [ ] a t t r = new Entry [ ] { new Name( ” P r i n t e r S e r v e r ” ) ,
13
new P r i n t e r D e s c ( 7 0 0 , 5 ) } ;
14
P r i n t e r S e r v i c e myServer = new P r i n t e r S e r v i c e ( ) ;
15
S e r v i c e I t e m s e r v i c e I t e m = new S e r v i c e I t e m ( null , myServer , a t t r ) ;
16
LookupLocator l o o k u p = new LookupLocator ( ” j i n i : / / l o c a l h o s t ” ) ;
17
S e r v i c e R e g i s t r a r r e g i s t r a r = lookup . g e t R e g i s t r a r ( ) ;
18
r e g i s t r a r . r e g i s t e r ( s e r v i c e I t e m , L e a s e .FOREVER) ;
19
}
20 }
The class PrinterService provides the actual implementation of the printJob method. In
this example, it also adds the service in the Jini server. In order to make the lookup system more
expressive, it is possible to add a set of attributes to describe the service characteristics. The
attributes array Entry[] attr defines two attributes: a name, with a Name instance and printer
properties with a PrinterDesc instance.
Listing 2.3: Jini AbstractEntry extension for service match
1 public c l a s s P r i n t e r D e s c extends A b s t r a c t E n t r y {
2
public I n t e g e r d p i ;
3
public I n t e g e r queue ;
4
public P r i n t e r D e s c ( I n t e g e r dpi , I n t e g e r queue ) {
5
this . dpi = dpi ;
6
t h i s . queue = queue ;
7
}
8 }
The PrinterDesc class (Listing 2.3) is a subclass of AbstractEntry. To improve the description
of the specific service, this class defines the dpi and queue size of a printer.
7
2.1. Jini and service discovery
Listing 2.4: Jini client query
1 public c l a s s PDAClient {
2
public s t a t i c void main ( S t r i n g [ ] a r g s ) throws E x c e p t i o n {
3
System . s e t S e c u r i t y M a n a g e r (new RMISecurityManager ( ) ) ;
4
LookupLocator l o o k u p = new LookupLocator ( ” j i n i : / / l o c a l h o s t ” ) ;
5
S e r v i c e R e g i s t r a r r e g i s t r a r = lookup . g e t R e g i s t r a r ( ) ;
6
Entry [ ] a t t r = new Entry [ ] { new Name( ” P r i n t e r S e r v e r ” ) ,
7
new P r i n t e r D e s c ( 7 0 0 , n u l l ) } ;
8
S e r v i c e T e m p l a t e t e m p l a t e = new S e r v i c e T e m p l a t e ( null , null , a t t r ) ;
9
P r i n t e r I n t e r f a c e myPrinter = ( P r i n t e r I n t e r f a c e ) r e g i s t r a r . l o o k u p ( t e m p l a t e ) ;
10
System . out . p r i n t l n ( ” C a l l i n g p r i n t J o b ( ) ” ) ;
11
myPrinter . p r i n t J o b (new O b j e c t ( ) ) ;
12
}
13 }
Listing 2.4 shows a client looking for a printer service. We can see the attributes array
Entry[] attr defining the expected properties of the service. This array is used to create a
ServiceTemplate instance. The matching algorithm is: each field of the attribute set in the
attributeSetTemplate array of ServiceTemplate must exactly match the corresponding fields
in the attribute sets of the service items, unless the template field is null. Null template fields are
like wildcards: they match anything.
The effect of changing the contents of the template parameters while the invocation is in
progress is undefined. The limit between exact matching and wildcard matching is that many
search criteria, such as including ranges of values to match or sets of values to match, cannot be
expressed with a single ServiceTemplate.
Listing 2.5: Jini service filtering
1 public c l a s s P r i n t e r F i l t e r implements S e r v i c e I t e m F i l t e r {
2
public boolean c h e c k ( S e r v i c e I t e m item ) {
3
f o r ( Entry e n t r y : item . a t t r i b u t e S e t s ) {
4
i f ( e n t r y instanceof P r i n t e r D e s c ) {
5
PrinterDesc desc = ( PrinterDesc ) entry ;
6
return d e s c . queue < 5 ;
7
}
8
}
9
return f a l s e ;
10
}
11 }
It is possible to define a subtype of ServiceItemFilter that implements the
boolean check(ServiceItem i) method. This method can access the set of attributes of the
item and reason about them. In the code above (Listing 2.4), we select a specific printer having
a queue size less than 5 jobs. Though this is an improvement over simple field equality, this filter
8
2.2. AmbientTalk in a Nutshell
only works on services that have already been discovered.
2.1.3
Summary
While providing a number of interesting feature for service discovery, Jini lacks support to define
an expressive and open notion of proximity:
• Class-based proximity: It is not possible to define on-the fly proximity functions, since it is
necessary to have the same description classes in both parties of the communication.
• Changing parameters with the time: In the implementation of the template matching
mechanism is specified that the values of the fields can not change over time. If they change
the result of the invocation is undefined. For instance, this limitation does not allow the
update of fields, such as GPS coordinates, disabling the mobility of the involved parties in
space.
• Language support: There are no language constructs to support and enforce the proximity
of service discovery. In the Jini case, it is also not possible to create such a construct.
2.2
AmbientTalk in a Nutshell
The Ambient-Oriented Programming (AmOP) paradigm [DMVC+ 05] addresses at the
programming language level the distributed computing problems associated with the interactions
of mobile devices. It recognizes that interconnected mobile devices are different from traditional
distributed systems:
• Volatile Connections: Mobile devices communicate using wireless technology, which is
subject to frequent interference and limited range such that failure is the norm rather than
the exception.
• Zero Infrastructure: Mobile devices are expected to operate autonomously in different
environments. These environments can offer infrastructure to support interactions. However,
such infrastructure is not always available and a programming model should support software
that does not rely on infrastructure.
The AmOP paradigm [DMVC+ 05] define a number of criteria for distributed programming
models in order to address these characteristics:
• Time decoupling implies that it is not necessary to have both parties of the communication
connected at the same time. This criterium supports communication between mobile devices
that are temporarily unavailable due to volatile connections.
9
• Synchronization decoupling means that the control flow of the communicating parties is
not blocked upon sending or receiving messages. This criterium ensures that the availability
of shared resources, which can be locked in a thread of control, does not depend on the
availability of other resources in the network.
• Space decoupling implies that the communicating parties do not need to know each others’
addresses beforehand. This criterium is required to support communication that does not rely
on infrastructure.
In order to support these AmOP criteria a distributed programming language called
AmbientTalk [CMB+ 07] has been conceived. AmbientTalk is a distributed object-oriented
programming language specifically designed for composing service objects in mobile (ad-hoc)
networks. AmbientTalk inherits most of its standard language features from Scheme [Sus75],
Self [US87] and Smalltalk [Kay93]. From Scheme, it inherits the notion of lexically scoped closures.
From Self and Smalltalk, it inherits an expressive block closure syntax, the representation of
closures as objects and the use of block closures for the definition of control structures. The object
model of AmbientTalk is derived from Self: classless, slot-based objects using delegation as a reuse
mechanism. The language also supports reflection [MVCTT07]. The remainder of this section
summarizes AmbientTalk’s (distributed) object model and syntax.
2.2.1
AmbientTalk objects
AmbientTalk is a complete object-based language with dynamic typing support. That bases
its object model on the prototype model from Self [US87]. To explain how objects work in
AmbientTalk, consider the definition of a printer object in Listing 2.6.
Listing 2.6: AmbientTalk printer object definition
1 def P r i n t e r := object : {
2
def d p i ;
3
def queue ;
4
def i n i t ( d p i ) {
5
s e l f . d p i := d p i ;
6
s e l f . queue := Queue . new ( 1 0 ) ;
7
};
8
def addJob ( aJob ) { queue . add ( aJob ) ; } ;
9
def g e t Q u e u e S i z e ( ) { queue . l e n g t h ( ) ; } ;
10
def p r i n t ( ) {
11
queue . f o r e a c h : { | doc |
12
doc . p r i n t ( ) ;
13
queue . remove ( doc ) ;
14
};
15
};
16 } ;
In the code excerpt above we define a Printer object ex-nihilo [Lie86] with the object:
construct. This printer object has two fields: the printer resolution dpi and an internal queue to
10
store the incoming jobs. The init method is used to initialize new objects when the new method
is invoked. Rather than creating a new instance like in class based object oriented languages, the
new message returns a clone of the receiver object. The init method initializes the object with a
coherent value to all fields. There are three methods defined in the Printer object to manipulate
the object’s internal state, addJob, getQueueSize and print. The print method illustrates the
use of keyword syntax and closures. The queue object has a method foreach: that takes a closure1
as its argument. A closure is syntactically created with { |arg1 ... argN| exp1; ... expN }.
The foreach: method is, unlike the other methods in the example, not of a canonical form. Instead
it is based on the keyword syntax, which was first introduced in Smalltalk [Kay93].
Keyword syntax can be recognized by the trailing colons after each word
and can take multiple arguments. For example, an iteration is expressed as
1.to: 10 do: { |i| system.println(i); }, where the keyword to:do: represents a function
that take two arguments, an integer and a closure. In the code excerpt above a closure is used
in the print method to iterate (using foreach:) over the printer’s queue. The closure has one
argument doc, it prints the document and removes the documents from the queue. In other words,
the print method iterates over the documents in the queue and removes each document after it
has been printed.
2.2.2
Concurrent programming
The concurrency model of AmbientTalk is based on the communicating event loops model from the
E distributed programming language [MTS05], which is an extension of the Actor Model [Agh86].
The E model combines actors and objects into a unified concurrency model. Unlike other actor
languages such as Act1 [Lie87], ABCL [YBS86] and Actalk [Bri88] an actor is a container of regular
objects that can be individually sent asynchronous messages. Hence, whereas in traditional actor
languages only actors can be sent asynchronous messages, regular objects can now also be sent
asynchronous messages. The actor is only a container, responsible for executing these messages
one at a time. To have a better understanding on how AmbientTalk actors behave, we first need
to describe the fundamental concurrency properties of the event loop concurrency model.
Event Loop Concurrency. The communicating event loop of the E language is an event-driven
concurrency model. In this model, the event loop is a thread that perpetually processes events from
its event queue by invoking a corresponding event handler. In addition, an event loop can enforce
three concurrency control properties:
• Serial execution: An event loop processes incoming events from its event queue one by one,
i.e. in a strictly serial order.
• Non-blocking communication: An event loop never suspends its execution to wait for another
event loop to finish a computation. Rather, all communications between event loops occurs
by means of asynchronous event notifications.
1A
closure is a nameless function that encapsulates its lexical scope.
11
• Exclusive state access: Event handlers and their associated state belong to a single event
loop. In other words, an event loop has exclusive access to its mutable state.
Actors. In AmbientTalk concurrent event loops are created with actors. Actors represent the
event queue with a message queue. This means that events are represented as messages, event
notifications as asynchronous messages and event handlers are represented as methods or closures.
The thread event loop of the actor is perpetually dispatching the messages of the message queue to
the corresponding method in the receiver object of the message. Messages in the event queue are
processed serially to avoid race conditions on shared state of objects. By default, all objects created
belong to the virtual machine actor. Other actors can be created as well as shown in Listing 2.7.
Listing 2.7: Actor creation in AmbientTalk
1 def anActor := actor : { | arg1 , arg2 ,
2
...
3 };
...
, argN |
In the code above a new actor anActor is defined with the actor: constructor. An actor is
isolated from its lexical scope to avoid sharing state with the actor that spawned it, a set of
arguments can be given to be copied in the lexical scope of the created actor.
Actor
Actor
Message from A to B
Event
Loop
Message
queue
B
A
Object
Far reference
Figure 2.1: AmbientTalk actors as communicating event loops
Communication. Each object belongs to one and only one actor. If objects belong to different
actors, the communication between them must be asynchronous by means of a far reference. A far
reference is a proxy to the object belonging to another actor. Figure 2.1 illustrates AmbientTalk
actors as communicating event loops. The dotted line represent the event loop threads of the
actors which are taking messages from the actor’s message queue and synchronously executing the
corresponding method on the actor’s owned objects. If two objects belong to the same actor, they
can communicate either asynchronously or using sequential message passing.
An asynchronous message is enqueued in the message queue of the actor that hosts the target
object. AmbientTalk distinguishes between sequential message passing using the dot operator
(obj.m()); and asynchronous message passing using the arrow operator (obj<-m()). Asynchronous
12
messages can return futures [MTS05]. A future is a placeholder for the real return value of an
asynchronous call.
Listing 2.8: AmbientTalk asynchronous method call
1 def p r i n t e r Q u e u e S i z e F u t := p r i n t e r <−g e t Q u e u e S i z e ( ) ;
The printerQueueSizeFut is bound to a future (Listing 2.8), in this case a placeholder for the
queue size of the printer. After the printer has eventually processed the getQueueSize message
the future will be resolved with the value returned by the getQueueSize method invocation
(Listing 2.9).
Listing 2.9: Future resolution in AmbientTalk
1 when : p r i n t e r Q u e u e S i z e F u t becomes : { | q u e u e S i z e |
2
system . p r i n t ( ”The Queue S i z e i s : ” + q u e u e S i z e ) ;
3 }
The when:becomes: function takes a future and a closure as its arguments, and registers the
closure as an observer of the future. When the future is resolved to a proper value, the closure is
executed with the resolved value of the future as parameter.
2.2.3
Distributed programming
In the previous section we discussed the concurrency model of AmbientTalk. Each actor
encapsulates one thread and a collection of objects that are serially accessible by means of
asynchronous message passing. From a distributed perspective traditional actor languages also
employ actors as the unit of distribution and this is also the case in AmbientTalk. However, as
opposed to traditional actor languages AmbientTalk’s model of distribution makes it possible to
remotely reference regular objects using far references as a communication channel. This means
that, since far references only support asynchronous method invocations, all remote communication
is asynchronous too. Hence, the concept of far references is used both for local and remote
concurrent distributed computations. AmbientTalk also provides programming abstractions to deal
with partial failures [CMB+ 07].
2.2.4
Metaprogramming
Metaprogramming is writing computer programs that write or manipulate other programs (or
themselves) as their data. We present the most important metaprogramming abstractions used
along this work.
13
Quoting. Any valid AmbientTalk expression can be quoted. This prevents the expression from
being evaluated. Instead, it is returned literally. Quoting an expression is done with the ‘ operator.
There are four variants:
• ‘... for quoting literal values
• ‘(...) for quoting expressions
• ‘{...} for quoting statement lists
• ‘[...] for quoting tables
Statements. Statements (definitions, assignments, etc.) can also be quoted, but only inside a
quoted statement list. Trying to quote a statement in the same way as an expression will cause a
parse error. Instead it is necessary to wrap the statements in a closure.
Unquoting. Inside a quotation, an expression can be unquoted as well. An unquotation escapes
from the quotation and causes the unquoted expression to be evaluated. The return value is then
used as the quotation of the unquotation. Unquoting an expression is done with the # operator.
First-Class Grammar. Quoting an AmbientTalk expression results in a parse tree of that
expression. Like any value in AmbientTalk, parse trees are objects that respond to messages. This
means that the abstract grammar of AmbientTalk is first-class: programs can manipulate and
create abstract grammar elements.
Read/Eval/Print. AmbientTalk reifies the read, eval and print operations. This means that
you can read an string and get the responding syntax tree for it, evaluate any syntax tree and get
a value for it, and print any value and get a string representation of the value.
The use of the metaprogramming facilities presented before make easily to create on the fly new
objects based on the internal structure of other objects.
2.2.5
Reflection
Reflection is the process by which a computer program can observe and modify its own structure
and behavior. Reflection is a particular kind of metaprogramming. Reflection is an integral part
of the AmbientTalk programming language. Through the use of reflection, the core language can
be extended with both programming support as well as new language constructs. Both require a
different kind of reflective access.
AmbientTalk supports mirrors reminiscent of those in Self and Strongtalk, which can be used
to perform introspection and self-modification [BU04]. AmbientTalk calls such mirrors explicit
mirrors. The novelty of AmbientTalk’s metalevel architecture are its implicit mirrors, which can be
14
used to additionally perform intercession as well. More information on the metalevel architecture
of AmbientTalk can be found in [MVCT+ 09].
The following enumeration provides a comprehensive overview of the API exposed by explicit
mirrors on objects. These methods may be invoked by metaprograms to introspect or modify
objects. In fact, these methods may also be invoked by the interpreter and are also part of the API
of implicit mirrors.
1. Structural access protocol
• addSlot(slot): Adds a field or a method slot to the object
• removeSlot(selector): Removes an owned slot from the object
• grabSlot(selector): Returns an owned slot whose name matches the selector
• listSlots(): Returns an array of all owned slots
• select(delegate,selector): Returns a closure which, when applied, invokes the slot
corresponding to the selector on the mirrored object
2. Method invocation protocol
• invoke(delegate, invocation): Invokes a method (with self bound to delegate)
• receive(message): Makes the object receive an asynchronous message
• send(receiver,message): Makes the object send an asynchronous message
• respondsTo(selector): Asks the object whether or not it (or one of its parents) has a
slot matching the selector
3. Object instantiation protocol
• clone(): Creates a shallow copy of the object (except for the object’s super slot, whose
value is recursively cloned as well)
• newInstance(arguments): Clones the object and invokes init on the clone
4. Type tag protocol
• isTaggedAs(typeTag): Asks the object whether it or one of its parents is tagged as a
subtype of the given type tag
• listTypeTags(): Returns an array of type tags with which the object is tagged
This powerful API lets us easily inspect an object and change the contents of its slots. It
also allows to change the method invocation protocol. The use of these reflective facilities of
AmbientTalk allows to change the behaviour of AmbientTalk’s objects. This API is used in next
chapters to extends the AmbientTalk language by changing common object semantics.
15
2.3. Many-to-Many Invocation library
2.2.6
Summary
AmbientTalk is a language for distributed computing in mobile networks. Its concurrency and
distribution model is based on actors and communicating event loops. This model is based
on asynchronous messages exchanged between objects encapsulated in actor. The programming
language features a number of language constructs, such as futures and first-class event-handlers, to
marry an object-oriented distributed programming style with distributed asynchronous concurrent
computations. Also, AmbientTalk provides a powerful reflective and metaprogramming layer that
allows to grow the language with new user defined constructs.
2.3
Many-to-Many Invocation library
This section describes the Many-to-Many Invocation (M2MI) library [KB02], for building
collaborative systems that run in wireless ad hoc networks of fixed and mobile computing devices.
M2MI is useful for building a broad range of systems, including multi-user applications; systems
involving networked devices; wireless sensor networks; and collaborative middleware systems.
M2MI provides an object-oriented method call abstraction based on broadcasting. An M2MIbased application broadcasts method invocations, which are received and performed by many
objects in many target devices simultaneously. An M2MI invocation means “Everyone out there
that implements this interface, invoke this method”. The calling application does not need to know
the identities of the target devices ahead of time, does not need to explicitly discover the target
devices, and does not need to set up individual connections to the target devices. The calling device
simply broadcasts method invocations, and all objects in the proximal network that implement
those methods will execute them.
Omnihandles. An omnihandle for an interface stands for “every object out there that
implements this interface”. An application can ask the M2MI layer to create an omnihandle for a
certain interface X , called the omnihandle’s target interface. (A handle can implement more than
one target interface if desired). Figure 2.2 depicts an omnihandle for interface Foo; the omnihandle
is named allFoos. It is created by code shown in Listing 2.10.
Listing 2.10: M2MI omnihandle creation
1 Foo a l l F o o s = ( Foo ) M2MI . getOmnihandle ( Foo . c l a s s ) ;
16
2.3. Many-to-Many Invocation library
objects A, B, and D, happen to be
that time; so all three objects perf
Note that even though object D did
the omnihandle allFoos was created
nonetheless invoked on object D.
The target objects invoked by an
objects
B,inand
D, happe
call need
not A,
reside
the same
proce
that
time;
so
all
three
object. The target objects can obje
resid
Note
thatdevices.
even though
cesses
or other
As longobjec
as th
therange
omnihandle
wasf
are in
to receiveallFoos
a broadcast
object
over the network,
theon
M2MI
la
nonetheless
invoked
object
target objects
and perform
remote
Figure 2: An omnihandle
The target
objectsa invoked
Figure 2.2: M2MI Omnihandle
tion call
on each
one.
remote
me
need
not(M2MI’s
reside in
the sam
does not, however, use the same mec
object. The target objects c
Once an omnihandle is created, calling method m on the omnihandle forRMI.)
interface
cessesXormeans,
other devices. As lo
“Every object out there that implements interface X , perform method m”. The method
is
actually
are in range to receive a bro
3.3
Exporting
Objectsthe M
performed by whichever objects implementing interface X exist at the time the
method
isover
invoked
object
the network,
on the omnihandle. Therefore, different
respond to an omnihandle
invocation
at andonperform
target
objects
To receive
invocations
a certaina
Figureobjects
2: Ancould
omnihandle
application
creates
an object
thatrem
im
different times. Figure 2.3 shows what happens when the statement allFoos.m();
tionisonexecuted.
each one.
(M2MI’s
X and
exports
to sa
th
does
not,
use the
Three objects implementing interface Foo, objects A, B, and D, happen to beface
in existence
at however,
that the object
Thereafter,
the
M2MI
layer
will
invo
time; so all three objects perform method y. Note that even though object D didRMI.)
not exist when
method Y whenever anyone calls m
the omnihandle allFoos was created, the method is nonetheless invoked on object
D.
omnihandle
for interface X. An ob
The target objects invoked by an M2MI method call need not reside in the
same
with3.3
code process
like
this:as
Exporting
Objec
the calling object. The target objects can reside in other processes or other devices.
As long(b,
as Foo.class);
M2MI.export
To the
receive
on ain
Foo.class
is
the invocations
class of the target
the target objects are in range to receive a broadcast from the calling object
over
network,
application
createswill
an come
object
which
M2MI
invocations
to
the M2MI layer will find the target objects and perform a remote method invocation
on each
one.
say the
is “exported
F
faceobject
X and
exports as
thetype
obje
(M2MI’s remote method invocation does not, however, use the same mechanism as Java RMI [rmi]).
lets Thereafter,
an object be the
exported
more w
M2MIaslayer
interface.
Figure 3: Invoking a method on an omnihandle
method Y whenever anyone
Once
exported, for
an object
staysX.
ex
omnihandle
interface
plicitly unexported:
with code like this:
M2MI.unexport (b);
allFoos.m()
M2MI.export
(b,does
Foo.cla
In other
words, M2MI
not
Foo.class
is
the
class
the
garbage collection (DGC). Inofmany
whichapplications,
M2MI invocations
will
laborative
DGC is unwa
thatsay
is exported
by one
device as part
the object
is “exported
as
application
should
remain
exported
lets an object be exported ae
no other
devices invoking the objec
interface.
where
DGC
needed, it can be pro
Figure 2.3: M2MI Omnihandle invocation
Once isexported,
an object s
ing mechanism [15, 1] explicit in the
Figure 4: A unihandle
Unihandles. A unihandle for an interface stands for “one particular object out
there that
M2MI.unexport
(b);
3.4
Unihandles
Inlayer
other
words,
M2MI do
implements this interface”. An application can export an object and have the M2MI
return
a
garbage
collection
(DGC).
unihandle for that object. Unlike an omnihandle, a unihandle is bound to one Aparticular
object
unihandle
for
anatinterface
standsIn
f
lar
object
out
there
that
implements
laborative
applications,
DGC
the time the unihandle is created. Figure 2.4 shows a unihandle for object B implementing interface
An application
can export
andevice
objec
that is exported
by one
M2MI
layer
return
a
unihandle
application should remainforext
17
like an
a unihandle
no omnihandle,
other devices
invokingis bo
th
ticular object at the time the uniha
where DGC is needed, it can
Figure 4 depicts a unihandle for objec
ing mechanism
1] explicit
Figure 5: Invoking a method on a unihandle
ing interface
Foo; the [15,
unihandle
is n
is created by code like this:
3.4
Unihandles
RMI.)
To receive invocations on
an obj
3.3 application
Exportingcreates
Objects
face X and exports the o
To receive
invocations
a certain
Thereafter,
theonM2MI
layei
application creates an object that im
method Y whenever anyo
face X and exports the object to th
forlayer
interface
2.4. omnihandle
Related
Thereafter,
the work
M2MI
will invoX
with
code
like
this:
method Y whenever anyone calls m
omnihandle
for interface X.
obj
M2MI.export
(b,An
Foo.
code
like this:
Foo, the unihandle is named b Foo. It is created by the piece of code show inwith
Listing
2.11.
Foo.class is the class of th
M2MI.export (b, Foo.class);
which
M2MI invocations w
Foo.class is the class of the target in
Listing 2.11: M2MI unihandle creation
theinvocations
object iswill
“exported
whichsay
M2MI
come to
1
Foo b Foo = ( Foo ) M2MI . g e t U n i h a n d l e ( b , Foo . c l a s s ) ;
lets
an isobject
be exported
say the
object
“exported
as type Fo
object be exported as more t
Figure 3: Invoking a method on an omnihandle lets aninterface.
interface.Once exported, an objec
Once exported, an object stays exp
M2MI.unexport
(b);
M2MI.unexport
(b);
In other
M2MI
In other
words, words,
M2MI does
not
garbage
collection
(DGC). In
many
garbage
collection
(DGC).
laborative
applications,
DGC is unwa
laborative
applications,
DG
that is exported by one device as part
that
is
exported
by
one
dev
application should remain exported e
application
shouldthe
remain
no other
devices invoking
object
other
devices
invoking
whereno
DGC
is needed,
it can
be prov
ing mechanism
[15, 1]isexplicit
in the
where DGC
needed,
it c
ing mechanism [15, 1] expl
Figure 2.4: M2MI Unihandle
3.4
Unihandles
A unihandle
an interface stands fo
3.4 for
Unihandles
lar object out there that implements
An application
can export
objec
A unihandle
for anan
interfa
M2MIlar
layer
return
a
unihandle
for th
object out there that
i
like an omnihandle, a unihandle is bo
An application can expor
ticular object at the time the uniha
layer
return for
a unih
FigureM2MI
4 depicts
a unihandle
objec
like anFoo;
omnihandle,
a unih
ing interface
the unihandle
is na
is created
by code
like this:
ticular
object
at the time
b_Foo.m()
Figure 2.5: M2MI Unihandle invocation
4
Figure 4 depicts a unihand
ing interface Foo; the unih
is created by code like this
Once a unihandle is created, calling method m on the unihandle means, “The particular object
out there associated with this unihandle, perform method m”. When the statement
4 b Foo.m();
is executed, only object B performs the method, as shown in Figure 2.5. As with an omnihandle,
the target object for a unihandle invocation need not reside in the same process or device as the
calling object.
2.4
Related work
We now focus discuss on work related to the use of proximity in managing system interaction. In
particular, we investigate the use of proximity in multi-agent systems. Also, we look at how the
concept of proximity has been applied to service discovery in pervasive and ubiquitous computing.
18
2.4. Related work
2.4.1
Multi-agent systems
The concept of proximity, or that of locality, is a technique that multi-agent systems have used
to manage and coordinate agent interaction. This can be particularly seen in systems inspired by
stigmergy [Gra59], where the locality of interaction with the environment is an essential construct
in determining agent behavior. For instance, Brueckner and Parunak [BP02] use stigmergy in a
multi-agent system to find global patterns across spatially distributed real-time data. Each agent’s
interaction is limited spatially to the local pheromone concentrations on the individual nodes. Other
applications of stigmergy can also be observed in [Gul99, MZ05, ROV+ 06, VKB+ 01]. In these
instances, while the environment used to perform stigmergy may differ, the notion of proximity is
still evident.
The application of proximity is also apparent in other multi-agent systems using different
forms of swarming such as flocking and shoaling [OS06, TJP03a, TJP03b]. In these cases, agents
coordinate their behavior based on that of neighboring agents. In [NHWC06, NH06], for example,
De Nardi et al. control a fleet of miniature helicopters using the concept of flocking. Neighboring
helicopters are determined through their physical presence or proximity to each other. In another
instance, Cui and Potok [CP07] have developed a technique for clustering documents using a multiagent system based on flocking. Neighbours are determined via similarities between the documents.
The use of proximity is not just limited to multi-agent systems inspired by biology. Castelli
et al. [CMZ07] presents a system that allows agents to retrieve context information via a spatial
proximity centered around a specific physical location. In a different approach, to aid collaboration
among agents in a ubiquitous computing environment, Locatelli et al. have devised a method
[LV07] that allows agents to perceive the physical or logical presence of other nearby agents. In
[HKTH02], Hanssens et al. structures agents within societies that represent, and which also act on
behalf of a user or space. Interaction is bound to agents within a society, and hence to a specific
physical proximity.
Julien and Roman have developed a middleware abstraction [JR06] that provides agents with
a view of the data in the system. The view, in terms of proximity, is defined using either a metric
based on the geometric distance or the hop count between an agent and the data within an adhoc network. It is also possible for agents to define multiple views in which further access to the
data can be gained using a tuple based mechanism. In a similar approach, Schelfthout et al. have
developed a framework called ObjectPlaces [SHB05]. The distance metric, in this case, is defined
on a per application basis. However, in practice it would appear the metric needs also to include
a hop count between nodes to ensure correct operation.
In reviewing the usage of proximity it is evident that the concept, whether it is used implicitly
or explicitly, is one that is prevalent among research in multi-agent systems. This is most likely due
to multi-agent systems using the environment as a primary abstraction [WOO07] in their design.
However, the extensive support that we propose for proximity, and which we have outlined in this
thesis, has not been fully realised in the multi-agent systems we have reviewed. As such, there is
limited support for open, idiosyncratic and composite proximity relationships, as well as for their
19
2.4. Related work
distributed evaluation.
2.4.2
Service discovery
Within pervasive computing and ambient intelligence, service discovery is one of the more
useful techniques for supporting spontaneous interoperability between components [KF02, EG01].
The approach facilitates the dynamic location of components that allows interaction between
components to occur with little or no prior knowledge. It is a technique that has been applied
successfully to a number of pervasive computing systems [PLF+ 01, HHM+ 00]. However, traditional
service discovery systems such as SLP [GPVD99], Jini [Mic] and Salutation [Con99], do not fully
meet the demands of pervasive systems. They tend to be designed for fixed infrastructures rather
than mobile ad hoc environments which are more prevalent in pervasive computing. Also, the
use of proximity to improve the discovery mechanism, as outlined in Section 3.2, is not explicitly
supported.
For instance, Jini [Mic] does service discovery based on an attribute matching system. The
default matching system checks for object equality and treats null values as wildcards. The default
matching process can be customized such that boolean expressions can be used to match the
attribute objects. While the combination of attribute objects with a customized matching process
enables one to support open proximity relationships, it does not permit dynamic relationships,
because attributes cannot be changed at run time. As a result, it is not possible to manage devices
with changing GPS positions or to look up a printer with a small number of documents in its queue.
However, it is feasible to define composite relationships using object composition techniques such
as aggregation and inheritance. It is not possible to support idiosyncratic proximity relationships
because the attribute classes need to be known beforehand in order for the clients to be able to
refer to the attributes of the system. Finally, while Jini does support some of the underlying system
requirements of evaluating proximity relationships, it is not explicitly provided for, nor is there the
ability to operate such functionality in, a mobile ad hoc environment.
There is, however, a number of service discovery systems that have been designed for mobile
ad hoc environments. Some of these systems have also used proximity to improve their service
discovery mechanism. For instance, Meier et al. [MCNC05] have developed a system where service
providers can define a proximity in which their services are available from. The definition of the
proximity is limited to a geometric distance - physical proximity. The notion of abstract proximity
is not supported, nor is the concept of idiosyncratic or composite proximity relationships. Once a
client registers an interest in a service they are continuously notified of any matching services as
they move through the environment.
In a different approach, Yoon et al [YLJK04] have developed an overlay routing algorithm
based on proximity. The approach is aimed at improving the discovery of services in mobile ad hoc
networks. While the algorithm does not allow for the explicit definition of proximity, it does return
the nearest service in terms of the current state of the network. This is determined periodically
through measuring different aspects of the network. Liu and Issarny also use a similar approach
20
2.5. Summary
[LI05] to determining proximity. In this case they use the signal strength between nodes to measure
the nearness of services to a client. Open proximity relationships are not supported by these
approaches, nor is the ability to compose or distribute the evaluation of these relationships.
While the use of proximity is evident among service discovery systems its application tends to
be limited. In our approach we have looked to provide a verbose implementation of the concept
that is both open and flexible.
2.5
Summary
This chapter has introduced most of the concepts used in this thesis: we have shown Jini and its
service discovery mechanism as a starting point of inspiration. We have presented AmbientTalk, a
novel programming language designed to develop ambient-oriented solutions; the Many-to-Many
Invocation library, a communication library providing an easy way to deploy ambient-oriented
programs. We finished the chapter presenting a review of the state of the art on other proximitybased systems.
Next chapter presents the open proximity model. This model introduces the notion of proximity
into service discovery in an open manner. We present a definition of the proximity concept and
a taxonomy of proximity. We also introduce the idea of proximity relationships and a set of
requirements that define it. Then we introduce the open proximity model design, concepts and
semantics and three evaluation strategies showing the tradeoff between simplicity and efficiency.
21
Chapter 3
The Open Proximity Model
In this chapter we present the open proximity model. The open proximity model introduces
the notion of proximity into service discovery in an open manner. We present a definition of
the proximity concept and a taxonomy of proximity. We also introduce the idea of proximity
relationships and a set of requirements that define it. Then we introduce the open proximity
model design, concepts and semantics and three evaluation strategies showing the tradeoff between
simplicity and efficiency.
3.1
Proximity definition
“Proximity is defined as the state, quality, sense, or fact of being near or next” – The
American Heritage
The above definition of proximity leads us to considering two orthogonal dimensions when
it comes to analysing proximity. First, being near or next depends on the notion of distance
used; that is, one entity is close to another with respect to a given metric. Such a metric can be
based on physical properties of the entities (physical location), or on a more abstract criteria, not
related to the material world (nearness of relatives). We discuss physical vs. abstract proximity in
Section 3.1.1, and then consider the interests of being able to compose several proximity metrics
in Section 3.1.2.
Second, the definition mentions the word “sense” in addition to “state” or “fact”, which tends
to suggest a subjective notion of proximity, that depends on the actual perception of the subject
entity. This is in contrast to objective criteria or metrics, for which all entities share the same
understanding of what it means to be close. We elaborate on this dimension in Section 3.1.3
22
3.1. Proximity definition
(a) Defining proximity in the form a
polygon.
(b) Defining proximity using a physical
boundary of a room.
(c) Defining proximity using the signal propagation of a
wireless network.
Figure 3.1: Different notions of physical proximity (B is “near” A, but C is not).
(a) Defining proximity using the relationships of users. Distance is determine
by the degree of separation between two
users.
(b) Defining proximity base on the
interests or hobbies of users. Weightings on links indicate similarity of
hobbies.
Figure 3.2: Different notions of abstract proximity
3.1.1
Physical vs. Abstract proximity
3.1.1.1
Physical proximity
In current pervasive computing and ambient intelligence systems, the proximity of entities is
primarily determine by physical considerations. For example in YABS [BC06], a domain specific
language developed for pervasive computing, interactions are limited to the local environment,
where “local” is defined by a geometric parameter (Fig. 3.2(a)). In Gaia [RHC+ 02] a middleware
framework developed for pervasive computing, proximity is administratively bound to a physical
location which, in this case, is a meeting room (Fig. 3.2(b)). Taking a different approach, systems
such as AmbientTalk [DVM+ 06b] implicitly define proximity based on the signal strength of
wireless communications (Fig. 3.2(c)): interactions can only take place when entities are in range
of communication.
3.1.1.2
Abstract proximity
Physical notions of proximity are very useful in developing pervasive computing systems [KF02,
Sat01], but it is also possible to extend the benefits of proximity considerations by examining
23
3.1. Proximity definition
abstract notions of proximity: an abstract proximity does not directly map to physical
characteristics of the considered entities, but rather relies on logical, domain specific criteria.
First of all, one may consider a virtual rather than physical concept of place: e.g. although
video conference participants may be in geographically different places, they all share the same
virtual meeting room. On another line, one can define proximity based on the relationships of users
- friends, acquaintances, or friends of friends. The distance between two users (or entities owned
by users) is the degree of separation between them, i.e. the length of the path relating them on
a relationship graph (Fig. 3.3(a)). This metric can be used for instance to allow access to your
personal devices to yourself, your friends, and friends of friends (that is, a friendship distance
of at most 2). One can consider that present instant messenger applications consider the buddy
relationship, restricting interactions to a distance of 1. In a different vein, it is possible to define
proximity based on the interests or hobbies of users. The distance in this case can be described
in terms of the similarity of one hobby or interest to another. For instance, jogging is arguably
much more similar to trekking than to knitting (Fig. 3.3(b)). It is likewise possible to devise a wide
number of abstract proximities, related to particular domains or applications.
3.1.2
Composite proximity
Most pervasive computing systems consider proximity as a singular concept: the idea of composing
different proximities to refine the overall scope of interactions is generally not considered. This is
a strong limitation, because considering the potentially wide variety of proximity notions we have
discussed above, it is clear that there is a lot to gain in being able to combine different types of
proximity to express a more subtle requirement.
For example, composing a proximity based on geometric distance (Fig. 3.2(a)) and user hobbies
(Fig. 3.3(b)) would first, aid scalability through the scoping of interactions within the local
environment, and secondly, highlight content in the local environment that may be of interest.
One could also consider spatio-temporal proximity, relating entities that are or have been, within
a given time frame, in the same local environment. Another example is to combine spatial locality
with network link quality, e.g. to aid in the development of an application disseminating multimedia
content to local participants.
Alternatively, combining geometric distance (Fig. 3.2(a)) with the wireless signal strength
(Fig. 3.2(c)) between nodes would define a proximity that not only scopes interactions of nodes to
their physical locality but by their closeness in terms of signal strength. Such a proximity might be
useful in disseminating multimedia content to local participants where link quality is important.
3.1.3
Objective vs. Subjective proximity
We now turn to a crucial issue when it comes to considering different notions of proximity in the
context of open networks.
24
3.2. Requirements for proximity relationships
3.1.3.1
Objective proximity
Existing pervasive computing systems support a notion of proximity that can be defined as objective
in the sense that the semantics of the proximity function are hardwired in the middleware layer.
That is, all entities in the system share the same notion(s). In a system like AmbientTalk, where
network connectivity is the only proximity factor, this shared understanding is obvious. In Gaia
as well, proximity is defined by physical presence in an active space, a meeting room. In a system
like YABS, each entity can define its own proximity requirement using the proximity function
(Listing 3.1). Although the actual parameters of the proximity functions are specific to each entity,
the interpretation of the proximity function is defined in the infrastructure, and cannot be changed.
Listing 3.1: Proximity definitions in YABS
1 proximity ( 5 ) ;
// c i r c l e o f r a d i u s 5
2 p r o x i m i t y ( − 5 , − 5 , − 1 0 , 5 , − 1 0 , 2 0 , 1 0 , 2 0 , 1 0 , 5 , 5 , − 5 ) ; // p o l y g o n as i n Fig . 1 ( a )
3 p r o x i m i t y ( F34 ) ; // s y m b o l i c l o c a t i o n as i n Fig . 1 ( b )
3.1.3.2
Subjective proximity
The way systems reliant on objective proximity work implies that the different shared
interpretations of proximity are installed or configured upfront in the infrastructure. Although this
approach is feasible if we consider a limited and fixed number of interpretations (like in YABS),
it does not fit our claim that many proximity notions are of interest, both physical and abstract,
and that these notions are potentially specific to certain applications or domains. It is necessary
that clients be able to define, compose and use new notions of proximity.
In other words, if a new entity joins a certain environment and looks for services of a certain
type that are “close” to it, this entity ought to be able to use its own notion of what it means to be
nearby. This means that the proximity function should possible be defined by the client itself, not
predefined by the underlying infrastructure. In this case there is no globally shared understanding
of the proximity, rather a subjective view of the client, that reflects the particular requirements of
the application.
3.2
Requirements for proximity relationships
In order for a software system to support a notion of proximity it must be capable of defining
proximity relationships. A proximity relationship (PR) defines when a party is considered to be in
proximity of another party. The type of proximity relationship that can be expressed in a system
determines its support for the notions of proximity we identified above. For example, a system will
support physical proximity when it supports the proximity relationship to be expressed in terms
of a physical distance.
25
3.3. Open proximity model for scoping service discovery
To express the different notions of proximity we described above the underlying system needs
to support evaluating proximity relationships. We distilled five requirements for these PRs, that
need to be supported by the underlying system, such that they can express the identified types of
proximity:
1. Open PRs: proximity relations should be general such that they can support both physical
and abstract proximity. PRs can be defined in terms of physical location parameters (such
as GPS coordinates) or application-specific parameters (such as database information).
2. Composite PRs: proximity relations can be constructed as a composition of a set of simpler
or more comprehensible proximity relations.
3. Idiosyncratic PRs: proximity relations should be custom definable by both clients and
servers in the network. Since a network is built from heterogeneous components, each having
their own requirements, it is impossible to define a set of shared definitions of proximity.
Being able to define idiosyncratic proximity relationships enables one to express subjective
proximity.
4. Distributed PR evaluation: proximity relations are defined over a set of networked parties
with the aim to reduce the number of interactions in the system. Hence, it is important that
the proximity evaluation process scales and is therefore distributed over the network.
5. Dynamic PRs: proximity relationships should be definable with values that change in time.
A model where it is possible to define PRs with these properties provides a good basis to express
the different notions of proximity we defined above. These notions ought to be supported by system
software for pervasive computing. In the remainder of this thesis we study how proximity can be
used to scope the context in which service discovery and advertising is performed.
3.3
Open proximity model for scoping service discovery
Whitout particular provisions, the scope of service discovery is typically defined by the broadcasting
range of packets in the network. In practice this broadcasting range is limited to the subnet of the
network to reduce unnecessary network traffic in other subnets. The scope of this mechanism is
implicit and determined by the network configuration rather than the application requirements.
In this work, we propose to scope the service discovery based on a proximity model. In this
section, we first give a brief overview of the proposed model, and then discuss its semantics in
details. We finally evaluate it in the light of the PR requirements established in section 3.2.
3.3.1
Service discovery
Service discovery is the combination of two processes: a service query, issued by a client, and a
service advertisement, issued by a server. Typically, a service advertisement includes a number of
26
attributes characterizing the service, and a service query defines constraints on these attributes,
specifying what the client is looking for.
We propose to define explicit scopes based on proximity for both the query and advertising
processes. This allows a server to restrict its advertisements so that they are visible only to clients
within a given scope. Reciprocally, a client is able to specify the scope within which it is interested
in querying services. Only if the scope of both parties intersect can the client actually see the
service, check its specific characteristics according to the query, and start using it if appropriate.
The scope of a particular process is defined by a proximity function. Such a function is a
predicate over the properties that characterize the other party. Properties are key-value pairs, that
can include information such as the physical location and application-specific data such as a social
network database from an application. The type and naming of the property information that is
included should be based on an ontology shared by the involved parties.
In this section, we present an abstract design of the open proximity model. In this model we
introduce some general concepts that will be used along all the thesis. With these concepts and
their interactions, we present three different ways to express and compute proximity relationships.
For each of them we present an overview, a complete explanation of the design and considerations
about them to highlight the tradeoff made in each case.
3.3.2
Model components
The open proximity model includes three basic components: properties, proximity functions and
proximity relationships. In this section we define these components and their semantics.
Properties. We define a set of properties, or simply properties, as a group of values that are
meant to expose interesting attributes to be exported in order to define a proximity relationship.
As the proximity relationships are based on a distributed computation of functions, the proximity
attributes names must be agreed upon beforehand to ensure the correct interaction of peers.
Definition 1 (Proximity Properties). We define a property set of n attributes (i.e. a property set
of size n) as a map props = {(ki , vi )}ni=1 , where each variable name ki is bound to a value vi .
Proximity properties may, and will, change over time. Peers in a mobile ad hoc network are
intended to change internal attributes over time such as position, battery level, signal intensity.
Also, they may adapt their behavior based on related attributes from network topology such as
numbers of peers in the network, number of peers in contact, peers with common friends, etc.. This
implies the need to define properties as a set of values that may change over time. In that case,
the v value must represent a function over time T to a set of values V , this is v(t) : T → V . Time
changing properties imply the necessity to recompute the proximity relationships as properties
change.
Proximity functions. We define a proximity function as a function that is computed with the
properties of both parties and returns a boolean value. Basically it is a logical predicate that
27
defines if, given two set of properties (function evaluation environment), the predicate is true or
false, meaning if the proximity relationship exists or not at a given time t.
Definition 2 (Proximity Functions). Given props1 and props2 as property sets, P1 and P2 as
power-set of properties such as props1 ∈ P1 , props2 ∈ P 2, and B is the boolean space {true, f alse}.
We define a proximity function f as f (props1 , props2 ) : P1 × P2 → B.
Given these definitions we can define a peer in our model.
Definition 3 (Proximity Peer). A peer is defined by a pair < props, f >, where props is a property
set and f is a proximity function that consumes the local properties props and some other properties
defined by other peers.
Proximity relationship Given the definitions of properties and proximity functions we need to
define what it means that two peers are in a proximity relationship. Two peers are in a proximity
relationship requires to determine first if both parties are proximity complete, second if they can
compute their proximity function with the properties that each peer defines, and third if both
proximity functions are true.
Definition 4 (Proximity Relationships). Given a peer A =< propsA , fA > and a peer
B =< propsB , fB >. We will say that there exists a proximity relationship between A and B if
and only if fA (propsA , propsB ) && fB (propsB , propsA ).
It is important to notice that both propsA and propsB may change over time, thereby changing
the value of fA (propsA , propsB ) && fB (propsB , propsA ).
3.3.3
Distributed evaluation semantics
The process to determine if two peers are in a proximity relationship involves evaluating the
proximity function of each peer. Since each peer defines its proximity function locally it is necessary
to retrieve the needed properties and exchange evaluation information between them. In the first
phase, the client starts querying in the network the requested service with its desired properties.
In this phase the scope of service query and service advertisement is determined, by evaluating
both the client and server proximity functions. Each function is evaluated at the site where it
has been defined using the properties that characterize the other party. The second phase, the
execution of the service query, is only performed when both client and server consider each other
in proximity, meaning that a proximity relationship has been established. In this stage the client
considers whether the service properties match its application requirements.
In section 3.3.4, we present several strategies to implement the desired semantics, giving a clear
analysis of cost and benefits of each implementation. In general, given two proximity complete
peers A and B, defined by pairs < propsA , fA > and < propsB , fB >, we define the distributed
semantics to compute the advertising scope (ads-scope) and the query scope (query-scope) as
follows1 :
1 The
notation [e]s denotes the evaluation of expression e on node s.
28
ads − scope `
[fA ([propsA ]A , [propsB ]B )]A
(3.1)
query − scope `
[fB ([propsB ]B , [propsA ]A )]B
(3.2)
where (3.1) defines the evaluation of the proximity function of peer A on the A node, and (3.2)
defines the evaluation of the proximity function of B on the B node. Notice that [f ([props]s , ·)]s
means that both p and f are evaluated at node s, this is [f ([props]s , ·)]s = [f (props, ·)]s . Then we
can simplify the distributed semantics of proximity as follows:
3.3.4
ads − scope `
[fA ([propsB ]B )]A
(3.3)
query − scope `
[fB ([propsA ]A )]B
(3.4)
Evaluation strategies
In this section we discuss three different strategies to perform the semantics defined in section 3.3.3.
To understand the evolution of these strategies, we moved from simplicity to complexity, but from
inefficiency to efficiency. We discuss the design and a cost/benefits analysis for each strategy. We
present an example with two proximity peers, a client peer C =< propsC , fC > and a service peer
S =< propsS , fS >. Besides there exist a multicast channel where both peers are listening.
3.3.4.1
Basic evaluation strategy
Strategy. The basic evaluation strategy defines the basic interaction between peers as shown
in figure 3.3. It consist of three phases. In the first phase, the client initiates a message
m = f ind(S, propsC ) to the multicast channel querying for a service S. Note that the request
embeds the client properties propsC . Each time a multicast beacon is sent, the properties are
evaluated to check changes over time. If there exists a service S listening on the same multicast
channel, this will evaluate its proximity function fS , using the locally-defined properties propsS
and the properties sent over the network by the client. If this process yields true, the service
responds with its set of properties propsS . In the second phase, the client performs the evaluation
of its proximity function fC . If this yields true, both advertising and querying scope are intersected
and a proximity relationship is created. In phase three, the client requests the object representing
to the service S through the call of request and retrieve.
29
C: Client
S: Server
M: Multicast
[find(S, propsc)]
[S, propsc]
fs(propsc)
[propss]
Server resolution
fc(propss)
[request]
Client resolution
[retrieve]
Object retrieval
Figure 3.3: Evaluation of proximity between server and client in basic evaluation strategy.
Discussion. The basic evaluation strategy is a simple model that realizes the semantics defined in
section 3.3.3. Following simple design principles, we provide a solution that covers the functionality
required. However, we can anticipate that in some scenarios this solution would behave inefficiently.
As a matter of fact, the whole property set is being broadcasted over the multicast channel, all
the time, even though the proximity functions may just use a small subset of these properties.
Therefore, we flood the channel with information that could be both heavyweight and useless in
some cases. This tradeoff is made since our principle goal is to give an open proximity model,
capable of defining any kind of properties or proximity functions, so no restrictions are set at this
point.
3.3.4.2
Selective evaluation strategy
Strategy. The selective evaluation strategy is a variation of the strategy presented above. As
we discussed, the basic evaluation strategy is broadcasting all the property set to the multicast
channel when just a few of them could be necessary to compute the proximity functions. This
behavior can overflow the network and therefore be inefficient since a lot of packet collisions will
be expected.
This model is shown in Figure 3.4. It consist of four phases. In the first phase, the client starts
a querying message m = f ind(S, varC ) containing the expected service type S and the set varC
30
containing the names of variables needed as arguments for its own proximity function fC . Each
time that a multicast beacon is sent, the properties are evaluated to check changes over time.
If there exists a service S listening on the same multicast channel, it checks that its properties
set contains the properties needed by the client. If so, S responds with a message m = (varS ),
specifying the properties required from the client to compute the service proximity function fS .
The client then checks if it defines the properties needed by the service. At this point, just property
names have been transmitted over the network, creating an acknowledgment process to define two
subsets of the property sets that will be really transmitted. In the second phase, If the client can
respond it sends the subset of the properties, ss − propsC , corresponding to the client properties
that the service expects. The service evaluates its proximity function fS , using its locally-defined
properties and the subset properties sent by the client. If this process yields true, the service will
respond with its subset of properties ss − propss , corresponding to the service properties that the
client expects. In the third phase, the client performs the evaluation of its proximity function fC . If
this yields true, both advertising and querying scope are intersected and a proximity relationship
is created. Finally the client requests the provider of service S through the call of request and
retrieve.
Discussion. This strategy fulfills the lack of precision of the basic evaluation strategy, since
it refines the proximity sets transmitted to the effectively needed subset, while preserving the
distributed semantics. In average, we reduce the properties sent over the network. The worst case
scenario for this model is when all properties are required to compute the proximity functions.
31
C: Client
S: Server
M: Multicast
[find(S, varc)]
[S, varc]
have?(varc)
[vars]
have?(vars)
[ss-propsc]
selective properties verification
fs(ss-propsc)
[ss-propss]
Server resolution
[request]
Client resolution
fc(ss-propss)
[retrieve]
Object retrieval
Figure 3.4: Evaluation of proximity between server and client in selective evaluation strategy.
3.3.4.3
Staged evaluation strategy
Strategy. Even though a complex proximity function may require a large set of properties, it is
certainly possible to split the predicate in smaller parts and evaluate them in a staged manner. It
can then be possible to short-circuit evaluation of some parts. We now can define a staged process
to compute the proximity functions. First we introduce some basic logic concepts needed to define
a staged proximity function:
Definition 5 (Conjunctive normal form). A Conjunctive normal form (CNF) is a normalization
of a logical formula which is a conjunction of disjunction clauses. A logical formula is considered
to be in CNF if an only if it is a conjunction of one or more disjunctions of one or more literals.
Definition 6 (Disjunctive normal form). A Disjunctive normal form (DNF) is a normalization
of a logical formula which is a disjunction of conjunctive clauses. A logical formula is considered
to be in DNF if and only if it is a disjunction of one or more conjunctions of one or more literals.
Definition 7 (Short-circuit evaluation). Short-circuit evaluation or minimal evaluation denotes
the semantics of boolean operators in some programming languages in which the second argument
is only evaluated if the first argument does not suffice to determine the value of the expression:
when the first argument of and evaluates to false, the overall value must be false; and when the
first argument of or evaluates to true, the overall value must be true.
32
Finally, we define the staged proximity function as follows:
Definition 8 (Composite Proximity Function). Given a set of proximity function {fi }ni=1 . We
define a composite proximity function F as a function representing a logical formula composed
by ∧ and ∨ operations. This function can be transformed to its conjunctive normal form or in
disjunctive normal form.
The staged evaluation strategy is a model that allows to define a complex proximity function
as a composition of proximity functions. This composition is useful in cases where short-circuit
evaluation of the composite proximity function may speed up the evaluation. When a function
does not need to be evaluated then their required properties need not be sent over the network.
As it is shown in figure 3.6, we have four different phases:
1. Handshake: The first phase starts with the client querying for a type service S. If there
exists a service S listening on the same multicast channel, this starts a private channel of
communication between both peers.
2. Client composite resolution: On the second phase, we start a loop that evaluates each
proximity function from the composite proximity function on the client peer. For each
proximity function fic , the client sends a message varsci , containing a set with names of
the properties needed as arguments to compute the client proximity function fi . Each time a
multicast beacon is sent, the properties are evaluated to check changes over time. The service
S checks if its property set contains the properties needed by the client. If so, the service
responds with a subset of properties ss − propssi . The client performs the evaluation of its
proximity function fic . At this point, just the cumulative properties from steep 1 to i − th
have been transmitted over the network. Then we follow with (i+1)−th step of the iteration.
3. Server composite resolution: On the third phase we compute the server composite in the
same way we explained for the client.
4. Service retrieval: Finally if all the evaluation of the staged proximity yields true, both
advertising and querying scope are intersected and a proximity relationship is created. Then
the client requests the object representing to the service S through the call of request and
retrieve.
As the staged proximity function is composed of boolean operation, we are iteratively
composing the F function. It is important to notice that the boolean composition may include
parenthesized expressions. This impacts on the iteration style from a linear selection onto a
tree traversal selection, where both cases are an iteration at all. Let’s take by example the
figure 3.5. Given a boolean formula (f1 &&f2 )||(f3 &&(f4 ||f5 )), where each fi is a proximity
function. To show the evaluation process let’s assume that the evaluation of the functions is
the following: {f1 = f alse, f2 = true, f3 = true, f4 = f alse, f5 = f alse}. Let’s write the tree as
Or(And(f1 , f2 ), And(f3 , Or(f4 , f5 ))). Hence, the evaluation process for the tree is the following:
33
1. Select the last node: And(f1 , f2 ). As f1 is false, the whole evaluation is false.
2. The new tree is Or(f alse, And(f3 , Or(f4 , f5 )))
3. Select the last node: Or(f4 , f5 ). As f4 is false, we need to evaluate f5 , which is false too.
Therefore, the whole evaluation is false.
4. The new tree is Or(f alse, And(f3 , f alse))
5. Select the last node: And(f3 , f alse). As f3 is true, we need to evaluate the right node, which
is obviously false. Therefore, the whole evaluation is false.
6. The new tree is Or(f alse, f alse)
7. Select the last node: Or(f alse, f alse). As the left node is false, we evaluate the right node,
which is false too. Hence the whole evaluation is false
8. The new tree is evaluated to f alse.
9. As the tree has size zero, the evaluation process stops and returns as evaluation value false.
OR
AND
f1
AND
f2
f3
(f1 && f2 ) || (f3 && (f4 || f5 ))
OR
f4
f5
Figure 3.5: Composite tree for the (f1 &&f2 )||(f3 &&(f4 ||f5 )) formula
Discussion. The downside of this strategy is its complexity for the programmer. Instead of
defining a single predicate p, he has to define a set of smaller predicates {pi }i and explicitly define
their composition in a way that is both semantically correct (w.r.t. the simple predicate p) and
potentially amenable to short-circuit evaluation.
The evolution of this model support the worst case scenario of the proximity model. Although
a big trade-off has been made with respect to simplicity. Such a model needs a specific way to
define the complex semantics of boolean composition and resolution in an asynchronous scenario.
The way to define both the proximity function and the properties will need an expertise of the
programmer to create such a staged proximity function.
34
C: Client
S: Server
M: Multicast
[find(S)]
[S]
[S]
varc1
Handshake
have?(varc1)
[ss-props1]
fc1(ss-props1)
varc2
have?(varc2)
[ss-props2]
fc2(ss-props2)
inProximity
Client composite resolution
vars1
have?(vars1)
[cs-props1]
fs1(cs-props1)
vars2
have?(vars2)
[cs-props2]
fs2(cs-props2)
inProximity
Server composite resolution
[request]
[retrieve]
Object retrieval
Figure 3.6: Evaluation of proximity between server and client staged evaluation strategy.
35
3.4. Discussion and conclusions
3.4
Discussion and conclusions
Efficiency of the Model. Our objective in presenting the open proximity model was simplicity
in its design and usability. However, among the motivation for scoping service discovery with
proximity functions is the fact of increasing the scalability of the system. For this reason it is
important that the model can be implemented efficiently. In the strategies presented before, we
have seen different ways to address the tradeoff between simplicity and efficiency.
Costs of Proximity. We claim that proximity relationships can reduce interactions among peers
in the environment because a client and a service will not initiate an interaction when they are not
considered to be in each other’s proximity. In particular, the actual service query is not executed
unless both client and server have agreed that they are in scope.
In the overall cost model, we have to consider (a) the amount of data that is transferred over the
network, (b) the number of connections that are established, and (c) the computational resources
used to compute the proximity.
Of course, we have to keep in mind what the cost would be if no support for proximity were
provided. For obtaining the same semantics without the support of proximity relations, for instance
in Jini [Mic], a client first retrieves all the available services that match the query,including all their
properties, and then has to filter them according to his criteria of proximity.
So, our model implies the transmission of the properties required to compute proximity on both
sides. In Jini, server properties used to compute client-defined scope would have to be passed also,
after the query has succeeded. Client properties are not passed over the network, but this is due
to the fact that it is impossible to express server-side proximity with Jini: a published service is
visible to any client in reach. This is like a service with a true proximity function and interested
in zero properties of the client.
So overall, the gain of our approach in terms of efficiency is that queries do not have to be
evaluated against service providers that are out of scope, including properties that are not used. For
this to represent a gain, the cost of evaluating a query should be higher than the cost of evaluating
proximity. We believe this makes sense in most cases, where proximity is a first approximation of
the range in which services should be found, while the actual service query potentially discriminates
on each and every detail of the provided services. This of course depends on a design decision that
the programmer has to commit to.
Conclusions. Now that we have defined a model of proximity functions we can review its
capabilities to express the required types of proximity relationships we distilled in Section 3.2:
1. Open PRs: proximity functions can express open PRs because they can be used to express
both proximity based on a physical location or on application-specific information.
2. Composite PRs: Representing the proximity relationships as functions has the advantage
that the relationships can be composed using function composition operators. In addition
36
3.5. Summary
in the staged evaluation strategy we can take advantage of the use of boolean composition
operators to optimize the overall evaluation.
3. Idiosyncratic PRs: proximity functions are not predefined and both the client applications
and services can define idiosyncratic PRs tailored to their requirements. As a consequence,
both objective (when the functions refer to a shared library of proximity concepts) and
subjective (when the functions define custom semantics for proximity) PRs be expressed in
the model.
4. Distributed PR evaluation: In our model a PR is defined by two proximity functions, one
for the client and one for the server, such that each proximity function is computed locally
given the properties of each party.
5. Dynamic PRs: The model can support partially dynamic proximity relationships because
the properties can be re-evaluated each time they are sent over the network.
3.5
Summary
In this chapter we presented the open proximity model. The open proximity model introduced
the notion of proximity in the service discovery in an open manner. We presented a definition of
the concept of proximity and a taxonomy of proximity. We also introduced the idea of proximity
relationships and a set of requirements that define it. The proposed model of proximity functions
is capable of expressing the required proximity relationships.
In order to experiment with this model, in the next chapter we extend the service discovery
abstractions of a contemporary distributed programming language for mobile networks, called
AmbientTalk [DVM+ 06b, CMB+ 07]. We present an implementation of the model extending
AmbientTalk’s service discovery abstractions.
37
Chapter 4
The Open Proximity Model in
AmbientTalk
In this chapter we present an implementation of the open proximity model in a contemporary
distributed programming language for mobile networks: AmbientTalk [DVM+ 06b, CMB+ 07].
We first introduce the service discovery mechanism of AmbientTalk and then we present an
implementation of the three evaluation strategies of the open proximity model disscussed in the
previous chapter.
4.1
Service Discovery in AmbientTalk
In this section we explain AmbientTalk’s current service discovery abstractions and discuss their
limitations. In the light of these limitations we then present an extension of AmbientTalk’s service
discovery language constructs based on the proximity model we propose at Chapter 3.
Service Discovery in AmbientTalk. Service discovery is an important feature in ambientoriented programming [DVM+ 06b]. This paradigm assumes no network infrastructure such that
service discovery is important to bootstrap the system and find services as users move from one
location to another. Therefore an expressive and scalable manner to publish and subscribe services
in the network is required. AmbientTalk uses a basic service discovery strategy, based on objects
type tags. Each object can be marked with a tag, which is a way to provide structural information
of the prototypes based on an agreement of names.
Exporting and Querying Objects. An object is advertised together with a type tag using the
export:as: construct. Since AmbientTalk is a dynamically-typed language a type tag is used to
universally identify the type of objects. In listing 4.1, the printer service creates a Printer object
and then exports it tagged as a PrinterServer.
38
4.1. Service Discovery in AmbientTalk
Listing 4.1: AmbientTalk’s service discovery exporting primitives
1
2
def hp := P r i n t e r . new( Port . new( ” usb ” ) , ” h p 9 2 0 0 x l ” ) ;
export : hp as : P r i n t e r S e r v e r ;
On the client side we register a handler that, upon discovery of an object matching the
printerSpecs, sends an addJob message to the discovered printer object. Registering the handler,
which is a closure parametrized with printer, is done using the when:discovered: construct. An
example is shown in Listing 4.2.
Listing 4.2: AmbientTalk’s service discovery querying primitives
1
2
3
when : p r i n t e r S p e c s discovered : { | p r i n t e r |
p r i n t e r <−addJob ( j o b ) ;
}
Pattern-Based Discovery. In AmbientTalk, service discovery is facilitated with a pattern
matching system. A pattern has a similar structure as regular objects but differs in the
interpretation of its fields. In objects, fields always refer to values (methods are also values in
the form of closures) whereas a pattern’s fields represent matching expressions. These matching
expressions are evaluated with the service’s fields. The matching expressions can be:
• Equality: a field must have a specific value, for instance x := 10 means that the field obj.x
must be 10 in the exported service obj.
• Wildcards: a field may have any value, for instance x := * means that the field obj.x may
have any value in the exported service obj.
• Constraints: a field may have any value in the range defined by the constraints, for instance
x := constraint: { < 10} means that obj.x can be any value less than 10. Notice that
“ ” is bound to the runtime value of the field.
As an example, a pattern to match the printer object we defined in Section 2.2.1:
Listing 4.3: AmbientTalk’s Service Discovery patterns
1 def p r i n t e r S p e c s := pattern : {
2
def t y p e := P r i n t e r S e r v e r ;
3
def d p i := 7 0 0 ;
< 5 };
4
def queue := c o n s t r a i n t : {
5 };
39
4.2. Open Proximity Model in AmbientTalk
In the code above, note that the pattern uses a subset of the fields defined by the properties of
the printer. The printerSpecs defines that the expected service must have exactly seven hundred
dpi and less than five jobs in its queue. Furthermore, the pattern defines the field type, which
specifies the desired type of the exported service. This type field is matched against the type tag
of the service.
The when:discovered: function initiates a service query based on the pattern we defined
above. Note that this function does not block until a service has been found. Instead it
immediately terminates and the registered handler is asynchronously invoked when a printer has
been discovered.
Discussion. AmbientTalk has an expressive pattern matching system to specify service queries.
However, the programming constructs do not provide support for an evaluation of proximity prior
to evaluating the queries. As a consequence, a client has to encode proximity requirement in the
query itself. Also, as in Jini, the service provider has no means to scope his advertisement. Services
are advertised in the network based on a datagram broadcasting protocol. As a consequence, service
advertisements are propagated to all clients in the network broadcasting range.
4.2
Open Proximity Model in AmbientTalk
In the open proximity model (Section 3.3), we introduced two constructs to support proximity:
properties and proximity functions. In this section we present how these components are
implemented in AmbientTalk.
4.2.1
Primitives for service discovery in the open proximity model
In this section we introduce the new primitives for AmbientTalk’s advertising and querying for
service discovery using the open proximity model. This new primitives remains the same for all
evaluation strategies presented on section 3.3.3.
Advertising the service within its scope We have extended AmbientTalk’s export:as:
construct to include the properties and proximity functions of the service.
Listing 4.4: AmbientTalk’s new Service Discovery exporting primitives
1 export : hp with : p r i n t e r P r o p s in : e u c l i d e a n ( p r i n t e r P r o p s , 1 0 ) ;
Listing 4.4 shows how export:with:in: exports the object hp with its properties. The scope
of the service advertisement is defined using the euclidean proximity function later (Listing 4.7).
In this example we specify that the client restricts its service discovery scope based on a physical
proximity of ten meters radius.
40
Initiating the service discovery We have defined the scope of service query we can register
handlers to discover a service matching our description. An example is shown in Listing 4.5.
Listing 4.5: AmbientTalk’s new Service Discovery querying primitives
1 when : P r i n t e r S e r v e r discovered : { | p r i n t e r |
2
p r i n t e r <−addJob ( j o b ) ;
3
when : p r i n t e r <−l o c a t i o n ( ) becomes : { | l o c a t i o n |
4
gu i <−showDialog ( ” Job added t o p r i n t e r @ ” + l o c a t i o n ) ;
5
}
6 } with : c l i e n t P r o p s in : e u c l i d e a n ( c l i e n t P r o p s , 1 0 ) ;
The client registers with the when:discovered:with:in: primitive the PrinterServer to
match services for the same type in the network and a handler to execute when a matching service
is found. This handler adds the printing job in the queue of the printer server and announces
where the document is being printed. It also attaches the properties of the client (clientProps)
and scopes the service query to a circular area of ten meters of radius.
4.2.2
Defining properties and proximity functions in AmbientTalk
Properties. As presented in 3.3.2, properties define the context information that is exposed by
servers and clients. In AmbientTalk we represent a property set as a special kind of value defined
by the properties: construct.
Listing 4.6: Properties definition in AmbientTalk
1 def hp := P r i n t e r . new( Port . new( ” usb ” ) , ” h p 9 2 0 0 x l ” ) ;
2
3 def p r i n t e r P r o p s := properties : {
4
def t y p e := P r i n t e r S e r v e r ;
5
def owner := ” Alan Smith ”
6
def d p i := hp . getMaxDPI ( ) ;
7
def queue ( ) { hp . g e t Q u e u e S i z e ( ) } ;
8
def x ( ) { gps . getX ( ) } ;
9
def y ( ) { gps . getY ( ) } ;
10 } ;
The code in listing 4.6 defines a set of printer properties. These properties are parametrized with
three objects hp, gps, and myAddressBook that are defined in the surrounding lexical scope. These
objects are encapsulated in the properties and their values are exposed through the properties via
regular fields and a method invocation protocol. Fields are used to define a constant property
value (such as the maximum resolution of the printer, dpi) whereas the method invocations
are used to compute the latest value of a dynamic property (such as current printer queue size,
queue()). Whenever the properties are requested by a server or a client all dynamic properties are
41
computed and the results are communicated to the requesting party. Notice that only the fields
are communicated and not the encapsulated objects such that this information remains hidden to
the other party.
Proximity functions. As presented in 3.3.2, proximity functions are used to determine the scope
of advertising and querying in the service discovery process. In AmbientTalk’s implementation we
represent a proximity function as follows:
• In the basic evaluation strategy and selective evaluation strategy, we represent a proximity
function as a simple AmbientTalk closure.
• In the staged evaluation strategy a proximity function is represented as a component object
following the Composite design pattern [GHJV94].
In Listing 4.7, we define a function named euclidean that returns a proximity function as a
closure. This closure takes 3 parameters: x and y as a position in the plane and a name. In the
body of the closure we can use values of the lexical scope of the body of the function, in this case
the parameters of the euclidean function: props and radius. This function is parametrized with
the x, y, name arguments that will be bound to the values with the same name on the properties
of the server. The function computes the euclidean distance based on the coordinates it finds in
the client and server’s properties. For instance it checks if the client is within the maximum radius
of the server.
Listing 4.7: Proximity function definition in AmbientTalk
1 def e u c l i d e a n ( props , r a d i u s ) {
2
{ | x , y , name |
3
def d := ( ( p r o p s . x − x ) . e x p t ( 2 ) + ( p r o p s . y − y ) . e x p t ( 2 ) ) . s q r t ( ) ;
4
( d < r a d i u s ) . and : { ( p r o p s . name != name ) != 0 } ;
5
};
6 };
Listing 4.8: Defining a staged proximity function
1 def e u c l i d e a n ( props , r a d i u s ) {
2
def f := Functor . new(
3
{ | x , y | def d := ( ( p r o p s . x − x ) . e x p t ( 2 ) + ( p r o p s . y − y ) . e x p t ( 2 ) ) . s q r t ( ) ;
4
(d < radius ) } ) ;
5
def g := Functor . new ( { | name | ( p r o p s . name <=> name ) != 0 } ) ;
6
def composite := And . new( g , f ) ;
7
composite ;
8 };
42
In Listing 4.8 we see that the euclidean function returns a composite object (line 7). This
composite is the result of the And composition between two Functors objects, f and g, which
represent the basic proximity functions given as closures to the new constructor.
To alleviate the definition of composite objects, we introduce the composite composite:and:
and composite:or: as syntax sugar. An example is provided in Listing 4.9.
Listing 4.9: Defining a staged proximity function with syntactic sugar
1
def e u c l i d e a n ( props , r a d i u s ) {
2
composite :
3
{ | x , y | ( ( props . x − x ) . expt ( 2 ) + ( props . y − y ) . expt ( 2 ) ) . s q r t ( ) < r a d i u s }
4
and :
{ | name | ( p r o p s . name <=> name ) != 0 } ;
5 };
It is important to notice that in the formal model a proximity function is defined as a function
f (p1 , p2 ) : P1 × P2 → B, which takes two property sets. In the AmbientTalk implementation this
definition is respected, but it is expressed in a different way. The function can take any variable
from its lexical scope, hence defining p1 as the union of the properties defined by the peer and the
free variables defined in the lexical scope. This is not a problem, since the properties are defined
in the enclosing lexical scope of the function, therefore any variable used from the lexical scope by
the function can be defined in the property set. Besides, the proximity function is defined with a
list of formal parameters, which are mapped to properties pertaining to p2 . All this changes were
made to avoid overwhelming syntax.
4.2.3
Extending AmbientTalk’s service discovery
To implement the open proximity model components defined and the distributed evaluation
strategies it is possible to proceed by two paths: extending the AmbientTalk interpreter or
implementing the open proximity model using the reflective and meta-programming interface of
AmbientTalk. The following list presents a review of these paths:
• AmbientTalk’s interpreter: It is possible to create the properties and proximity functions
as a native object in the AmbientTalk interpreter to provide the desired semantics. This
path involves modifying several classes of the AmbientTalk interpreter and to tie up specific
components and strategy implementation with the AmbientTalk interpreter.
• AmbientTalk’s reflective and meta-programming facilities: It is possible to create simple
AmbientTalk objects and change their semantics using the reflective interface of
AmbientTalk. This is done by accessing or changing the mirror of an AmbientTalk object
and overwriting the desired methods (recall Sections 2.2.4 and 2.2.5). Using the metaprogramming facilities it is possible to create AmbientTalk objects on the fly, by the use
of the eval function. It is also possible to modify existing objects and methods by the use
of the first-class grammar interface.
43
We use the reflective and meta-programming facilities of AmbientTalk. This decision was made
to keep both modularity of the open proximity model and to easily experiment with the different
evaluation strategies presented in section 3.3.4.
Listing 4.10: Defining a property set object in AmbientTalk
1 def properties : c l o taggedAs : t y p e s {
2
object : { } taggedAs : [ I s o l a t e ]
3
mirroredBy : ( e x t e n d : d e f a u l t M i r r o r with : {
4
/ / code o f t h e e x t e n d e d m i r r o r
5
/ / s t o r e t h e c l o p a r a m e t e r as a m i r r o r i n s t a n c e v a r i a b l e
6
/ / r e d e f i n e d e s i r e d methods t o change s e m a n t i c s o f t h i s empty object
7
});
8 };
The implementation of the distributed evaluation strategies presented in the next section
is based on a simple tradeoff between simplicity and efficiency. We have previously presented
properties and proximity functions components in AmbientTalk. We now present the design
decisions that show the tradeoff in the components of the open proximity model.
• Basic evaluation strategy: a simple AmbientTalk isolate object1 is used to keep the property
set. Listing 4.10 shows an skeleton for the property set. We change its mirror to support
dynamic evaluation of properties before each multicast beacon is done. A proximity function
is defined by a simple AmbientTalk closure.
• Selective evaluation strategy: we change the mirror of the AmbientTalk object representing
the properties to just pass a subset of properties when needed. We keep the basic
representation of a proximity function as an AmbientTalk closure.
• Staged evaluation strategy: we keep the selective evaluation strategy representation of
properties. We introduce a new way to represent proximity functions. Particularly we
introduce an object to represent the proximity functions. We can compose them by the
use of the Composite design pattern [GHJV94].
4.2.4
Implementing the distributed evaluation strategies
We present the different evaluation strategies to express the model semantics. This distributed
implementation is developed on top of the Many-to-Many Invocation Library [KB02].
Using M2MI as a communication layer. An Omnihandle object is used to represent a
multicast channel. Each AmbientTalk virtual machine responds to any call to this channel.
1 An
isolate object is an object that is passed by value between actors. The default passing strategy between
actors in AmbientTalk is passing by reference, creating a far-reference.
44
Hence this is the basic conduit for peer communication, establishing the first handshake. If
more communication must be done, each peer communicates to the multicast channel a personal
channel represented by a Unihandle object. Therefore, basic communication is done over the
multicast channel (handshake), but further communications are made by means of a private channel
represented by Unihandle objects.
App Space
Actor A
SD Layer
Multicast Layer
Actor B
M
Service
Multicast Layer
Gatherer
Multicast Channel
Multicast
Channel
SD Layer
App Space
Gatherer
M
Multicast
Channel
Query
Actor C
Multicast
Channel
M
Multicast Layer
Gatherer
SD Layer
Query
App Space
Figure 4.1: Channel architecture to communicate among peers
Each actor can be viewed as a three layer application: Application Space, where objects are
created; Service Discovery Space, where services and handlers to queries are stored and fired; and
the Multicast Layer, where the Communications are done. On Figure 4.1 we depict three actors,
A, B and C. Each actor can communicate to each other through the multicast channel object, but
also we can see a direct path communicating Actors B and C by means of a unihandle object: the
Gatherer object, representing a private channel among B and C.
4.2.4.1
Basic evaluation strategy
Implementation. In this strategy, all properties defined in properties: object are sent over
the network. As properties change over time, we need to create a new object each time we send
data through the network. The basic idea is to return an empty object with an extended mirror
when the properties: is called. The mirror changes the behaviour of the object, specifically
its meta function pass(@args) is, which is the function used to serialize objects, and the meta
function invokeField(target,method), which is used to access a field on an object. When
we create a property set, we save the properties in the mirror as a new instance variable of
the mirror named propertiesClosure. Therefore, when pass or invokeField are called, we
create a new object to evaluate the dynamic properties that may have changed invoking to the
45
evalDynamicProperties() . This behavior is possible to define in AmbientTalk since the language
provides full access to the meta level of the interpreter. Moreover, it is possible to iterate each
sentence defined in a closure to check if it is a field definition statement or a method definition
statement. If it is a method definition statement we reduce the method definition to a new field
definition statement containing the value of the evaluation of the function.
Listing 4.11 shows the definition of the function evalDynamicProperties(), which uses the
meta programming interface of AmbientTalk.
Listing 4.11: Function EvalDynamicProperties for the basic evaluation strategy
1 def e v a l D y n a m i c P r o p e r t i e s ( ) {
2
def mth := p r o p e r t i e s C l o s u r e . method ;
3
def s t a t e m e n t s := [ ] ;
4
5
mth . b o d y E x p r e s s i o n . s t a t e m e n t s . each : { | e x p r |
6
i f : ( r e f l e c t : e x p r ) . typeTags ( ) . c o n t a i n s ( M e t h o d D e f i n i t i o n ) then : {
7
def varname := e x p r . s e l e c t o r ;
8
def v a r v a l u e := eval : ‘ (#( e x p r . b o d y E x p r e s s i o n ) )
9
in : p r o p e r t i e s C l o s u r e . c o n t e x t . l e x i c a l S c o p e ;
10
s t a t e m e n t s := s t a t e m e n t s + [ ‘ { def #varname := #v a r v a l u e } ] ;
11
} else : {
12
s t a t e m e n t s := s t a t e m e n t s + [ e x p r ] ;
13
};
14
};
15
16
eval : ‘ ( object : { |#@( mth . p a r a m e t e r s ) | #s t a t e m e n t s }
17
taggedAs : [#C l o s u r e ,# I s o l a t e ,# P r o x i m i t y P r o t o c o l O b j e c t ,# @types ] )
18
19 } ;
On the other hand, proximity functions in this model are just represented as normal
AmbientTalk closures. Proximity functions must do a map between proximity properties fields
and the formal parameters expected by the proximity function. In Listing 4.12 we show
the mapping done by the function argumentMap(function, properties), which consumes a
proximity function and a property set to check if the property set contains all the formal parameters
needed by the function. This mapping is done by name equality. If there is a map between properties
and formal parameters, the function is evaluated, otherwise false is returned.
The communication’s data flow of this model is presented in Figure 4.2. In the sequence diagram,
we can distinguish the Omnihandle object called Multicast, the Omnihandle objects: Client gatherer
and Server gatherer. The diagram also depicts the service discovery layer on both client and
server, responsive to register handlers and export objects. We can identify in the data flow how
the complete set of properties is sent in the multicast beacon. Hence available services in the
environment can immediately evaluate their proximity functions, using the argumentMap function.
If this succeeds, the service reports to the client sending its properties. Similarly, the client evaluates
46
Listing 4.12: Function argumentMap for the basic evaluation strategy
1 def argumentMap ( f u n c t i o n , properties ) {
2
def arguments := [ ] ;
3
def fparams := f u n c t i o n . method . p a r a m e t e r s ;
4
def f c o n t e x t := f u n c t i o n . c o n t e x t . l e x i c a l S c o p e ;
5
6
fparams . each : { | fparamname |
7
try : {
8
def v a l := eval : ‘ (#p r o p e r t i e s .#fparamname ) i n : f c o n t e x t ;
9
arguments := arguments + [ v a l ] ;
10
} catch : Exception using : { | e |
system . p r i n t l n ( e . message ( ) ) ; }
11
};
12
13
i f : fparams . l e n g t h ( ) == arguments . l e n g t h ( ) then : {
14
f u n c t i o n . a p p l y ( arguments ) ;
15
} else : {
16
false ;
17
};
18 } ;
its proximity function. the process may be aborted at any time. The client checks by means of the
alreadySeen function if the service is new or if it is a new beacon of a known service, to finally
call the handler registered by the when:discovered:with:in call.
Discussion. This implementation is completely done in the AmbientTalk language, since the
language offers a powerful meta programming layer, enabling the manipulation of statements of
objects and re-evaluating code on the fly. This meta layer is not fundamental to implement the
model. It is possible to create a new object in the Java interpreter of AmbientTalk to represent
properties, which defines the same behaviour for the pass and invokeField methods. Such a
native implementation in Java would certainly perform better than this reflective implementation.
4.2.4.2
Selective evaluation strategy
Implementation. In this strategy we extend the basic evaluation strategy to limit the properties
sent over the network. As we just discussed, the mirror of the properties object is the most
important piece to change, since it defines the behaviour of the properties. In this case, as we need
to reduce the set of properties, we change the evalDynamicProperties() function to produce an
object with limited properties, filtering the unused properties at that time. This new function is
presented bellow in Listing 4.13.
The new evalDynamicProperties function takes as argument a table of properties names to
be exported. Then a basic filter is performed to determine the variable name, varname, of the
current expression. This is necessary since an statement could be a variable definition, a method
definition or a type tag definition. If the varname exists in the desired properties names, we include
47
SD Layer (C)
Client Gatherer
Multicast
Server Gatherer
SD Layer (S)
export
(type, serv handler)
registerHandler
(type, client handler)
send
(CG, type, client_props)
argumentMap(client_proximity, server_props)
send
(CG, type, client_props)
equal-type? &&
argumentMap(server_proximity, client_props)
CG.reportTo
(SG, server_props)
SG.requestObject()
CG.retrieveService(Service)
alreadySeen(Service) ?
updateLastTimeSeen :
trackNewService
handler(Service)
Figure 4.2: Communication flow of the basic evaluation strategy
the statement to the list of statements that represent the body of the property object that will be
passed.
On the other hand, proximity functions are simple closures with the special mapping described
before in the basic evaluation strategy.
The communication’s data flow is presented in Figure 4.3. It is very similar to the basic
evaluation strategy. We present the major differences here. Instead of sending properties in the
multicast beacon, this approach sends a table of properties names, the client needed props.
Available services check if they have defined properties with equal names. If so, they ask the client
if it can respond to server needed props. If the client may respond, then a process like the one
described for the basic evaluation strategy takes place. The only difference is that only the needed
properties are sent over the network, instead of the whole property set.
Discussion. This strategy is a simple extension addressing the issue of sending all properties
defined instead of just the needed properties. To get the property names, a preliminary handshake
is needed in the discovery process, where both peers exchange the information of the properties
needed to compute the proximity functions.
48
Listing 4.13: Function EvalDynamicProperties for the selective evaluation strategy
1 def e v a l D y n a m i c P r o p e r t i e s ( p r o p e r t i e s T a b l e ) {
2
def mth := p r o p e r t i e s C l o s u r e . method ;
3
def s t a t e m e n t s := [ ] ;
4
5
mth . b o d y E x p r e s s i o n . s t a t e m e n t s . each : { | e x p r |
6
def varname := ” ” ;
7
/ / . . . o m i t t e d c h e c k s t o d e t e r m i n e varname . . .
8
9
i f : p r o p e r t i e s T a b l e . c o n t a i n s ( varname ) then : {
10
i f : ( r e f l e c t : e x p r ) . typeTags ( ) . c o n t a i n s ( M e t h o d D e f i n i t i o n ) then : {
11
def varname := e x p r . s e l e c t o r ;
12
def v a r v a l u e := eval : ‘ (#( e x p r . b o d y E x p r e s s i o n ) )
13
14
s t a t e m e n t s := s t a t e m e n t s + [ ‘ { def #varname := #v a r v a l u e } ] ;
15
} else : {
16
s t a t e m e n t s := s t a t e m e n t s + [ e x p r ] ;
17
};
18
};
19
};
20 } ;
4.2.4.3
Staged evaluation strategy
Implementation. In this implementation, properties are exactly the same as in the selective
evaluation strategy. The major change of this strategy is the definition of proximity functions. This
strategy defines a staged evaluation of a boolean composition of a group of proximity functions.
To accomplish this behaviour, we introduce a composite structure following the Composite design
pattern [GHJV94].
AmbientTalk does not provide classes, but it provides prototype inheritance. Hence we have
a Composite prototype which provides the navigation over the tree structure of the composite.
Particularly in this case, we need to reduce the tree as we get remote evaluation results. From
Composite we extend a Functor prototype and an Operator prototype. The Functor is responsible
to store the closure of a single proximity function. The Operator is the object that creates the tree
by referring two other composites objects: left and right2 . Also the Operator is not an operation
by it self. It have two children: And and Or. Those are the prototypes which perform the logical
operation between Functors.
The semantic for the short-circuit evaluation of a composite tree is the following:
1. Traverse the tree and get the last operator node, ie, the first node where the left and right
composites are Functors. Let’s name this node operator and let’s call the evaluation of
operator as result.
2 The Operator is a binary node. This is for simplicity, because an N-ary relationship between boolean operators
may be reduced to a composition of binary relations. For example: p ∨ q ∨ r is equivalent to p ∨ (q ∨ r)
49
SD Layer (C)
Client Gatherer
Multicast
Server Gatherer
SD Layer (S)
export
registerHandler
send
(CG, type,
client_needed_props)
send
(CG, type,
client_needed_props)
equal-type? &&
respondsTo(client_needed_props)
CG.neededProperties(
SG,
server_needed_props)
respondsTo(server_needed_props)
SG.InProximity?(client_subset_props)
CG.reportTo
(SG, server_subset_props)
argumentMap(server_proximity, client_subset_props)
argumentMap(client_proximity, server_subset_props)
SG.requestObject()
trackNewService
handler(Service)
Figure 4.3: Communication flow of the selective evaluation strategy
2. Case operator is an And instance.
2.1) Evaluate the left node of operator. Let’s call this result lvalue
2.2) If lvalue is false, we know by definition that (false && p) is false for any p. Hence, we
do not need to evaluate the right node. The result is false.
2.3) If lvalue is true, we continue to evaluate the right node of operator. Let’s call this
result rvalue. As (true && p) is p for any p, the result is rvalue
3. Case operator is an Or instance.
3.1) Evaluate the left node of operator. Let’s call this result lvalue
50
Composite
getLastOp
replaceLastOp
getSize
isNode
isLeaf
eval
parameters
Functor
closure
left
right
Operator
And
Or
Figure 4.4: Composite class structure
3.2) If lvalue is true, we know by definition that (true || p) is true for any p. Hence, we do
not need to evaluate the right node. The result is true.
3.3) If lvalue is false, we continue to evaluate the right node of operator. Let’s call this
result rvalue. As (false || p) is p for any p, the result is rvalue
4. Replace the operator node by the result value.
5. Continue evaluating the new tree until it becomes a tree of size 0. This means that the value
of evaluate the whole tree is the value of the Functor that represents the tree.
The communication’s data flow of this model is presented on the figure 4.5. As before, we can
distinguish the same objects to communicate data. The first change is the multicast beacon. It just
includes the service type. Hence, all services tagged with the same type start a staged evaluation.
This step includes the creation of a “channel” represented by the client and server gatherers.
The staged evaluation of the composite requires a deep traversal of the tree. For instance, to
resolve a node Or(f1 , f2 ), we need to evaluate f1 and if necessary evaluate f2 . To evaluate f1 , we
need to exchange the specific subset of properties needed by the function f1 (similar to the selective
evaluation strategy). Then we check if it is possible to perform a logical short-circuit evaluation to
avoid evaluating f2 in the same way. If so, then we can avoid to send all the properties required
by f2 for its evaluation. It is important to notice that all this calls are asynchronous invocations.
Hence, it is necessary to remember which node in the tree is being evaluated and to restart the
computation of the function evaluation when the answer to an asynchronous call is received. This
task is done using futures values as return values of the function evaluations. Hence, when we
evaluate f1 a future is returned. When this future is resolved, we continue with the evaluation of
f2 . Then we can replace the node on the tree (a reduction) and continue the recursive traversal.
We first reduce the client proximity function on the client stage evaluation phase and then we
reduce the server composite on the server stage evaluation phase.
51
SD Layer (C)
Client Gatherer
Server Gatherer
Multicast
SD Layer (S)
export
registerHandler
send(CG, type)
send(CG, type)
CG.createChannel(SG)
equal-type
Object Query
stagedEvaluation(client_composite_proximity)
set function = composite.getLastOperator()
startEval(function)
set props= function.parameters()
resolveFuture(
argumentMap(function,props))
SG.respondsToProperties?(client_needed_props)
respondsTo(client_needed_props)
CG.computeProximity(props)
Repeat stagedEvaluation until the client composite tree is completely resolved
SG.InProximity()
Client Staged Evaluation
stagedEvaluation(server_composite_proximity)
set function = composite.getLastOperator()
CG.respondsToProperties?(server_needed_props)
startEval(function)
set props= function.parameters()
respondsTo(server_needed_props)
SG.computeProximity(props)
resolveFuture(
argumentMap(function,props))
Repeat stagedEvaluation until the server composite tree is completely resolved
CG.InProximity()
Server Staged Evaluation
SG.requestObject()
trackNewService
handler(Service)
Object Retrieval
Figure 4.5: Communication flow of the staged evaluation strategy
52
4.3. Summary
Discussion. This strategy permits to introduce the composite proximity functions as firstclass objects. The evaluation of the composite object allows the implementation of the shortcircuit evaluation. This may reduce the amount of interactions between peers based on the staged
evaluation.
4.2.5
Discussion
We have extended AmbientTalk’s service discovery abstractions such that both service queries and
advertisements can be scoped with proximity functions. These proximity functions are used to
express PRs in AmbientTalk. We evaluate our service discovery extensions to express the different
PRs we defined in section 3.2:
1. Open PRs: functions can be defined using both properties defined values or any variable in
the lexical scope of the function. This includes physical parameters gathered from devices’
sensors or any application-specific value.
2. Composite PRs: functions in AmbientTalk are first-class. Thus proximity function are firstclass and can be composed. Also we presented a composite structure to support distributed
staged evaluation.
3. Idiosyncratic PRs: proximity functions are user defined functions. Furthermore, both
clients and servers can attach such a function to the service query and advertisement such
that each party can define its scope based on its definition of proximity.
4. Distributed PR evaluation: client and service define their own proximity function, just
requiring the properties defined by the other as a parameter to locally evaluate the function.
Properties are distributed in the network where each node evaluates them to determine the
scope of proximity. Staged evaluation further optimizes the process by avoiding evaluating
superfluous conditions; this is at the cost of a manual decomposition of a proximity function
into sub-functions, composed by logical operators.
5. Dynamic PRs: the properties support dynamic fields which are re-evaluated with each
transmission such that only the most recent values of the properties are used to compute the
scope. The issue of how to deal with interactions that have begun based on an assumption of
proximity that turns out to be invalid at some point in time is left unaddressed and represents
a non-trivial challenge for future work.
4.3
Summary
In this chapter we presented an implementation of the open proximity model in a novel
distributed programming language for mobile networks: AmbientTalk [DVM+ 06b, CMB+ 07].
We first introduce the service discovery mechanism of AmbientTalk and then we present an
53
4.3. Summary
implementation of the three evaluation strategies of the open proximity model disscussed in the
previous chapter.
In the next chapter we present the major results of a controlled simulation implemented to test
the behaviour of the different evaluation strategies of the open proximity model and to compare
it with AmbientTalk’s service discovery primitives.
54
Chapter 5
Experiments with the Open
Proximity Model
In this chapter we present the major results of a controlled simulation implemented to test the
behaviour of the different evaluation strategies of the open proximity model and to compare it with
both AmbientTalk’s service discovery primitives and the M2MI definition of service discovery.
5.1
Experiment Design
Our initial plan was to present a real experiment with a set of devices communicating through the
ambient. But an experiment with a few devices in the ambient may not reveal the real performance
of the models. Besides, a real wireless setup is inherently difficult to control and error-prone.
Hence, the goal of this section is to define a controlled simulation, where it is possible to measure
some indicators in several scenarios and to repeat the simulation with statistical confidence. This
section introduces the specific indicators which we are interested in, and the different scenarios
and configurations that show the impact of the strategies defined by the open proximity model.
5.1.1
Indicators
To test the performance of the open proximity model we include the details of the definition of
the experiments we simulated. The idea of the experiments is to measure two specific indicators
of performance defined as follows:
• (Id ) Data sent through the network. This indicator is defined to measure the possible
overhead caused by sending metadata to establish proximity boundaries.
• (It ) Time for service discovery. This indicator is defined to measure the possible delay
introduced by the computation of proximity boundaries in each node of the network.
55
5.1. Experiment Design
5.1.2
Scenarios
In order to measure these indicators, we define five settings that are tested to benchmark different
approaches and optimizations. These scenarios implement the evaluation strategies presented in
this thesis:
• (AT)AmbientTalk Base: Services discover each other without proximity data. This establishes
the lower bound of both: Id and It .
• (AT+Filter) AmbientTalk Filters: Services discover each other using the simplest service
discovery facilities from AmbientTalk and each variable required to compute the proximity
is resolved as a future. This scenario lacks the facilities of defining proximity in the service as
well, but it is interesting to test because it gives a good point to compare the open proximity
model with the current capabilities of the AmbientTalk service discovery.
• (BES) Basic evaluation strategy: Services define properties and proximity functions. All
defined properties are sent over the network as a whole package and each node computes its
proximity function using the values of the properties that were received.
• (SES) Selective evaluation strategy: Services define properties and proximity functions. Each
node sends a set of required properties that must be defined by the other node. Only the
required properties are sent over the network as a whole package and each node computes
its proximity function using the values of the properties that were received.
• (STES) Staged evaluation strategy: Services define a set of properties and a set of proximity
functions. Each properties set is sent over the network as a whole package and each node
computes parts of its proximity function using the values of the properties that were received.
The simulation was tested on a PC computer, with an Intel Core 2 Duo (CPU E4500)
2.2GhZ / 64 bits, 3 Gigabytes of RAM, running Ubuntu Linux, with Kernel 2.6.24-23. The
AmbientTalk distribution used is the release 041108. To run the AmbientTalk interpreter we used
the Sun Java 1.5.0-16 implementation.
5.1.3
Common setup
The setup we present here is inspired in the case where people use wireless devices in the ambient.
They interact with other people just in case they are near in terms of physical distance. Specifically
the euclidean distance less or equal to 3 meters. In this case the scale of the setup is restricted
by the broadcast range of the ad-hoc network. The basic simulation consists in a set of randomly
distributed peers in a plane. Each peer is an AmbientTalk actor, hence a Java thread. Each actor
creates a simple point storing the randomly generated coordinates (x, y) and an actor’s name. Each
point is exported as an object of type Peer in the ambient. Also, each actor starts a discovery for
more peers in the ambient.
56
Two random variables X and Y define each peer position. These random variables follow a
uniform distribution in the Ix = [xmin , xmax ] interval and in the Iy = [ymin , ymax ] interval. Points
are randomly generated in a rectangle area defined by the bounds of the random variables X, Y ,
this is R = Ix × Iy .
An euclidean proximity function is used to determine both the service discovery and the service
advertising scope. This function is composed with a simple function to test name equality in order
to exclude the trivial case to discover the same point that an actor is exporting.
The scenario we want to test is with full proximity connections. This means where each node is
interacting with all the other nodes. Indeed, this scenario is a worst case for proximity management,
because proximity evaluation always yields to an actual discovery. Therefore, this case is when the
most information is transmitted over the multicast channel. To force a large number of interactions
between peers, which is the case of interest of this experiment, the simulation setup guarantees
the intersection of all peers inside the rectangle1 . With these conditions it is possible to have, at
least theoretically, a fully connected graph, this means O(n2 ) number of connections2 . Since O(n2 )
connections is a hard condition to test, each peer is programmed to stop the discovery process
by resuming a future value if it finds another peer in the network. This does not mean that we
measure O(n) connections, because it is very likely that a peer that resolves its future value also
discovers more peers in the ambient due to the multicast call, hence giving more data to measure
the indicators.
The peers are distributed using a numeric random generator with a fixed seed, to get the same
position distribution along each repetition of the simulation. The number of repetition is fixed to
100. We depict the discovery process in the proximity viewer in Figure 5.1.
5.1.4
Uses and conflicts with Many-to-Many invocation library
We discuss the major problems found in the simulation with respect to using M2MI. AmbientTalk
has two implementations of service discovery: A native implementation in the AmbientTalk
interpreter and a modular implementation developed on AmbientTalk itself, based on the M2MI
library as communications layer. We describe problems on each implementation bellow:
1. Native implementation in the interpreter: Each AmbientTalk interpreter communicates
to a broadcast address to start discovering peers. When a peer is found a direct
communication with each discovered virtual machine is established through TCP connections.
This implementation is tightly coupled to the interpreter itself. It does not provide a scalable
way to change the network layer of communication (for instance, change to wifi for bluetooth).
2. M2MI service discovery: This implementation is made in AmbientTalk itself. It uses the
Many-to-Many Invocations library to deal with broadcast communications. M2MI serializes
objects as chunks of UDP messages. The chunks are stored in an output buffer. If a message
is lost, there is no flow control and the communication must be restarted.
1 The
2 The
euclidean distance between peers is upper bounded by the min(|xmin − xmax |, |ymax − ymin |)
n∗(n−1)
number of connections of n points in the plane is
2
57
(a) Starting Discovery
(b) One peer discovered a matching service
(c) Several peers have discovered matching services
Figure 5.1: Discovery process viewer for the experiments
The idea of implementing the service discovery in AmbientTalk is to have as many
implementations as needed to be able to choose the most appropriate for a given case. As we
were growing the language by adding a new service discovery model, we implemented the model
over M2MI. The idea was to have a loose coupling between the model and the network layer.
During the experiments, we discovered several problems with the use of M2MI on AmbientTalk3 .
The M2MI implementation fails to support the semantics of far references, which means that
even though the meta circular service discovery is used, we need to use the base network layer
to communicate with far references. This is because far references just communicate using the
interpreter.
3 We
submitted a bug report on the interpreter for these problems:
http://code.google.com/p/ambienttalk/issues/detail?id=26
58
5.2. Scale on number of nodes in the ambient
Also M2MI does not provide mean to define variables on the data link layer. This implies that
is not possible to measure effectively packet collisions. Also it is not possible to measure the data
transmission velocity and the real data transmission velocity of the network card. This lack of
configurations makes M2MI not suitable for serious testing of the model. Further research must be
done with real network simulators like NS2 [ns2]4 .
As a result, the AmbientTalk service discovery mechanism uses both layers to communicate
data. We present measures for both of them in the results of the experiments. On the other hand,
our model just uses Omnihandle and Unihandle objects to manage network communications. Hence
we do not use far references in the discovery process. Therefore we can run our simulation without
using the AmbientTalk underlaying network.
5.2
Scale on number of nodes in the ambient
This specific setup tests the simulation with increasing numbers of peers in the ambient.
The simulation shows the behaviour of the discovery time and data throughput with several
configurations of peers.
The number of peers considered are: {2, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50}. We could not
experiment with more nodes. This is because as we have a fully connected graph a lot of interactions
take place and the Java virtual machine does not behave as expected. Also, as each node is
represented by an actor, hence by a Java thread, the AmbientTalk virtual machine present issues
with the actor’s scheduler.
The data sent by the peers is a property set including the values of each peer for: {type, actorname, x-pos, y-pos}. In this simulation we test with an increasing number of peers. The peers start
a discovery for surrounding peers in the plane.
(Id ) Data sent. As we can see in Figure 5.2 and Table 5.1, the amount of data sent is increasing
in an exponential manner for AmbientTalk service discovery. It is important to say that two
metrics are presented in the graphic for AmbientTalk base scenario: AT2 and AT2+M2MI. The
difference between them is minimum. We also see that M2MI by itself has a linear growth (difference
between AT2 and AT2+M2MI) . This implies that AmbientTalk native service discovery is growing
exponentially with respect to data. In Figure 5.3 we provide a detailed comparison between different
evaluation strategies.
It is also important to notice that only the basic evaluation strategy and the selective evaluation
strategy could be run until 50 nodes. The staged evaluation strategy works until 35 nodes.
AmbientTalk native service discovery works until 45 nodes. This could be explained by the amount
of data collision in the channel, but is not possible to effectively measure in M2MI. This implies
the need to restart the whole evaluation process each time. Therefore, it performs badly with a
large number of nodes.
4 This
simulation is beyond this thesis work.
59
5.2. Scale on number of nodes in the ambient
Nodes vs Sent data
450000
AT2+M2MI
AT2
BES
SES
StES
400000
350000
Data (Kbytes)
300000
250000
200000
150000
100000
50000
0
0
5
10
15
20
25
30
Number of Nodes
35
40
45
50
55
Figure 5.2: (Id ) Data sent over the network with increasing numbers of nodes in the graph
Strategy
AT2
AT2+M2MI
BES
SES
StES
10
15
20
25
30
35
40
45
50
3197.8
3459.4
224
191.7
273.1
7102.6
7529.2
318.7
284.2
367.5
12518
13043.3
395
372
452
20034.1
21168.4
472.5
454.4
615.2
40787.9
42838.5
569.7
863.8
731.6
76291.5
80207.8
769.8
1362.4
1228.3
119196.7
125892.3
2570.1
2815.2
0
299050.5
317290
11544.4
5420
0
0
0
21277.6
23190.3
0
Table 5.1: (Id ) Data sent over the network (in bytes) with increasing numbers of nodes in the graph
(It ) Time for Service Discovery. With respect to the time spent we do not have a clear output.
As all actors are running in the same device, the time measured is the application time and not
the actual actor’s discovery time. This implies that we can not see if all actor’s discovery time
are statistically equivalent. What we observed is that when several peers are running (more that
35), there is starvation among actors. Several logs showed that simulations count reached 34 peers
discovered, while several connections among the already discovered peers kept happening. But there
was one peer that did not established a single connection. Further details are shown in Figure 5.4
and in Table 5.2. It is not possible to yield a connection based on this experiments. Further research
must be done. Again, we have just run a simulation, therefore we are not considering latency of
the network which impacts the discovery time in an important way.
60
5.3. Scale on size of properties
Nodes vs Sent data
30000
BES
SES
StES
25000
Data (Kbytes)
20000
15000
10000
5000
0
0
5
10
15
20
25
30
Number of Nodes
35
40
45
50
55
Figure 5.3: (Id ) Data sent with increasing numbers of nodes for different evaluation strategies
Strategy
AT2
AT2+Filter
BES
SES
StES
10
15
20
25
30
35
40
45
50
33.1
36.3
37.4
36.6
37
36
41.2
35.8
36.7
36.8
39.4
46.8
36.7
38.2
38.3
43
61.7
35.6
48.4
43.5
77.6
91.5
39.6
56.7
44.2
99.2
115.4
42.8
69.7
58.4
148.4
148.8
69.4
106.9
0
468.3
317
209.3
153.8
0
0
0
380
538.7
0
Table 5.2: (It ) Discovery time (in seconds) with increasing number of nodes in the graph
5.3
Scale on size of properties
In this simulation we fix the number of nodes in the network in 10 peers, but we change the data
sent through the network by changing the properties set. The simulation shows the behaviour of
data throughput with increasing number of properties size.
In this case, the data sent by the peers is a properties set including the values of each peer for:
{type, actor-name, x-pos, y-pos} and an extra field of garbage represented by an integers array of
variable size. The array sizes tested is: {0, 10, 100, 1000, 10000}. As each integer variable is stored
in 4 bytes in the Java interpreter, the total amount of data is increased in: {0, 40, 400, 4000, 40000}
bytes.
61
5.3. Scale on size of properties
Nodes vs Time
700
AT
AT+Filter
BES
SES
StES
600
Time (sec)
500
400
300
200
100
0
0
5
10
15
20
25
30
Number of nodes
35
40
45
50
55
Figure 5.4: (It ) Discovery time with increasing number of nodes in the graph
We simulated to test the behaviour with increasing size of properties. This simulation results
are shown in Figure 5.5. The data of the experiment is presented in table 5.3. As we expected, the
basic evaluation strategy grows heavily on data sent over the network. This is because no filtering
of properties is done, sending the garbage array each time and flooding the discovery process
with non interesting data. The selective evaluation strategy and the staged evaluation strategy
transmitted a bounded amount of data. This is the expected behaviour of sending just the needed
properties on each multicast beacon. We also can see that the basic evaluation strategy behaves
better than staged evaluation strategy until garbage array size of 100. This shows the overhead of
the staged evaluation, even though useless information is being sent on the network.
Strategy
BES
SES
StES
0
10
100
1000
10000
229.31
209.02
268.95
223.98
205.86
280.49
240.78
206.62
300.53
438.63
211.94
292.89
3297.51
214.85
365.01
Table 5.3: (Id ) Data sent (in bytes) with increasing number of properties size
62
5.4. Discussion
Properties size vs Sent Data
4000
BES
SES
StES
3500
Sent Data (Kbytes)
3000
2500
2000
1500
1000
500
0
10
100
Properties size
1000
10000
Figure 5.5: (Id ) Data sent with increasing properties size
5.4
Discussion
We have shown the results of the simulation done in AmbientTalk. Several issues appeared that
made difficult the execution and further comparison of the recollected data. M2MI is not a
library appropriate to execute simulations. It lacks several parameters to configure a real network
simulation: it is not possible to define data link layer parameters, it is not possible to simulate real
timeouts, etc. Even though, it is possible to say that the open proximity model is more efficient
than AmbientTalk service discovery with respect to data transmitted. The open proximity model
is also competitive with AmbientTalk in the discovery time introduced by the service discovery.
The tradeoff between simplicity and efficiency between the evaluation strategies that we have
claimed before is not shown as clearly as we would like. It is just clear that the selective strategies
of properties are better when data that do not need to be transmited is added in the property set.
There is not silver bullet for evaluation strategies. Programmers need to be able to choose between
different evaluation strategies based on specific problem requirements, including the efficiency
needed by the application.
In our implementation, results are intrinsically determined by the M2MI library
implementation. We did not study in details the implementation. We believe that this
implementation is affecting in a negative manner the results of the comparison between the different
evaluation strategies. Future work includes developing a new communication layer to replace the
63
5.5. Summary
M2MI library.
5.5
Summary
In this chapter we have presented the major results of the simulation implemented to test the
behaviour of the different evaluation strategies of the open proximity model. We also compared
the strategies with both the AmbientTalk’s service discovery primitives and the M2MI definition
of service discovery.
Next chapter presents the major conclusions of this work and the open perspectives that we
foresee for future work.
64
Chapter 6
Conclusions
This chapter presents the major contributions of the thesis and discusses the perspectives opened
by this work. As a result of this thesis, a first version of the open proximity model was published
in the post-proceeding of the EEMMAS workshop [RDTB08].
6.1
6.1.1
Contributions
Proximity taxonomy and relationships
In pervasive computing, being able to scope interactions based on a notion of proximity is important
both for scalability and demarcation of content of interest. Still, proximity is a vague concept whose
semantics often rely on the implicit context of its subjects. From this observation we have argued
for the support of open notions of proximity in pervasive computing. We presented a taxonomy of
the concept of proximity from an application perspective.
From the taxonomy we derived a set of requirements for defining proximity relationships
between entities. As such, proximity is not an important component until we define interaction
between services. These interactions create the need for proximity relationships. We provided a
characterization of these proximity relationships. Moreover we presented a formal definition and
requirements needed to fulfill such relationships: They must be open, composable, locally defined,
distributed and dynamically evaluated.
6.1.2
Open proximity model
The set of requirements of proximity relationships was used to design an open proximity model
for service discovery. The major contribution of our work is that our model reduces interactions
between devices by defining a scope for both service query and advertisements. Hence, evaluation
of service queries is scaled down to devices within this scope, thus enhancing the scalability of the
overall system by reducing the number of interactions.
65
6.1. Contributions
A notable difference with other discovery mechanisms is the fact that service providers can
scope the advertising of services. Furthermore, since proximity is an open concept, in this model
we can define the scope of interactions based on any application requirements, not only physical
location. To define the open proximity model we introduced two first class components to define
interactions: properties and proximity functions. Properties define the interest parameters that are
exposed to compute proximity functions. Proximity functions are boolean predicates that consume
properties from client and servers and derive a proximity relationship. In addition, we present three
different models to express the semantics of proximity relationships, considering different scenarios
and characteristics of interest.
• Basic evaluation strategy: This model establishes a fast connection between clients and
services interchanging the complete set of properties defined by the peers.
– Tradeoff: The simplicity of this approach is contrasted by its efficiency.
– Best Case: When set of properties are small or all properties are used to compute the
proximity function.
– Worst Case: When just a small subset of a big set of properties are used to compute
the proximity function.
• Selective evaluation strategy: This model establishes a specific handshake for the properties
needed by each proximity function.
– Trade-Off: This model maintains the simplicity to the programmer based on a smarter
implementation of communications. More steps are needed to compute the proximity
relationship.
– Best Case: When just a small subset of properties are used to compute the proximity
function.
– Worst Case: When the set of properties is small or all properties are used to compute
the proximity function.
• Staged evaluation strategy: This model has a composite object representing a proximity
function.
– Trade-Off: More time is used to compute the service discovery. The simplicity of
definition is jeopardized. Much work is required from the programmer to define a good
composition, but some times the composition of smaller functions may be easier.
– Best Case: Complex proximity function definition. When it is not clear how to define
one proximity function based on a complex domain. When based on the boolean
rules presented on section 3.3.4.3, composition evaluation may on average require less
connections.
66
6.1. Contributions
– Worst Case: Computing the proximity composite is expensive in both time and data,
hence changing dynamics implies recomputing the relationship with the consequent
overhead. On networks with big loss of packets or big latency it is not useful.
Each model makes its contribution by showing the different scenarios that can be faced, making
clear the best and worst scenarios and giving an analysis of the trade off made from simplicity to
efficiency.
As a final remark we say that there is no silver bullet on evaluation strategies. Therefore,
programmers need to be able to choose between different evaluation strategies based on specific
problem requirements.
6.1.3
Open proximity model in AmbientTalk
Finally, we have discussed and illustrated a first integration of this model with the service
discovery abstractions of the AmbientTalk language. We presented the design decisions and
the implementation on AmbientTalk based on both the reflexive and metaprograming layers of
AmbientTalk. We have shown a serious deficiency of the Many-to-Many Invocations library to
implement the meta-circular service discovery of AmbientTalk.
On the AmbientTalk’s implementation of the open proximity model we developed a set of
tests to benchmark both current service discovery and the open proximity model service discovery.
From these results we saw that AmbientTalk has a basic network layer that must be improved
to support real scenarios of pervasive computing. Also we concluded that the implementation of
the open proximity model dramatically reduces the amount of data transmitted over the network.
Furthermore, we showed that the scalability of the models is restricted to the numbers of actors
running on the same virtual machine (each actor is represented by a Java thread). More benchmarks
must be developed on a real distributed scenario with several interacting devices.
67
6.2. Perspectives
6.2
6.2.1
Perspectives
Improvements on AmbientTalk’s implementation
The model we presented above has been implemented but there are two important open issues that
require further work. First, our implementation does not explicitly consider the topology of the
underlying network. This means that our protocols only consider devices within the multicasting
capabilities of the network.
The second issue we see as a problem is how to manage dynamic proximity relations once the
discovery process has occurred. This implies determining an efficient way to recompute proximity
conditions when required, and giving programmers a way to handle the case where a proximity
condition becomes false.
6.2.2
Publish-Subscribe service discovery
In order to expand the range of broadcast communications we consider a publish-subscribe
architecture where certain nodes are selected to act as routers. These routers link devices together
that have an intersecting proximity scope. This model may be based on a infrastructure like a
dynamically deployed DNS system.
It is also interesting to notice that a lot of problems are more easy to solve in a centralized
architecture. Hence is interesting to research what is the impact on Ambient Oriented programming
of having a hybrid service discovery, based on the same ideas from peer to peer networks, where
there exist global trackers to find the peers that have certain resources available.
6.2.3
A new communication layer for AmbientTalk
The current implementation of the AmbientTalk communication layer uses a complete graph
of connections with any peer discovered in broadcast range. Each AmbientTalk machine
communicates to a broadcast address to discover peers. After that a direct communication with
each discovered virtual machine is established through TCP connections [CDS74].
In an effort to improve this layer there is an implementation of the service discovery layer
in AmbientTalk itself (a meta implementation). This implementation uses the Many-to-Many
Invocations library [KB02] to deal with broadcast communications. M2MI serializes objects as
chunks of UDP messages [Pos80]. The M2MI implementation fails to support the semantics of far
references, which means that even though the enhanced service discovery is used, we need to use
the base network layer to communicate far references. Hence AmbientTalk’s communication layer
must be revised.
Since most of the problems faced in this work where related to the use of M2MI as
a communication layer for service discovery, we suggest a re-engineering of AmbientTalk
communication layer.
A scenario could be to use Multicast addresses to discover peers and use the SCTP
protocol [Ste07] to send data to specific peers in the network. In comparison to UDP, SCTP
68
6.2. Perspectives
provides larger sizes of data sent over the network, by using the concept of chunk of data. A
message can be fragmented over a number of data chunks, but each data chunk contains data
from only one user message. SCTP chunks are bundled into SCTP packets. In comparison to TCP,
SCTP provides connection oriented services, without the overhead of TCP to preserve byte order
in the stream.
We have not been able to experiment with this approach, because Sun does not provide support
for SCTP. Therefore, it would be have been required to implement native SCTP drivers for
AmbientTalk and its corresponding JNI libraries.
Since pervasive computing considers a big number of devices active in the same network, it may
be of interest a further explore IPv6 [DH98]. Particularly the IPv6 multicast system grows the scope
from the broadcast domain to a global scope where any listener can subscribe for messages. This
scenario avoid the routing problems in different sub-networks. Hence it would be totally transparent
for the discovery process if peers are or are not in the same IP network.
6.2.4
Proximity references
Ambient references [Van08] are a novel type of remote object references. Remote object references
are “pointers across the network” and are a frequently recurring abstraction in both distributed OO
languages and distributed middleware. Ambient references are designed to refer to objects in mobile
networks. What exactly constitutes a mobile network and how it differs from traditional, stationary
networks is described at [CMB+ 07]. An ambient reference is a remote object reference that allows
programmers to intentionally designate a volatile set of proximate objects. Ambient references
support asynchronous point-to-point or one-to-many communication styles. Programmers can
tweak a message’s expiration period to make message delivery more resilient to temporary failures,
and to perform failure handling.
We did a behaviour preserving re-factoring of the Ambient References to provide Proximity
References. Ambient References notion of proximate object is defined by the service discovery
filtering done by the reference itself in its meta level. Instead, proximity references are created with
a subjective notion of proximity defined by the programmer to take advantage of the proximity
service discovery implemented in this thesis. Further research must be done to define more complex
semantics to support disconnections, effective object selection, resilience to failures, etc.
69
Bibliography
[Agh86]
Gul Agha. ACTORS: a model of concurrent computation in distributed systems. The
MIT Press: Cambridge, MA, 1986.
[BC06]
Peter Barron and Vinny Cahill. YABS: a domain-specific language for pervasive
computing based on stigmergy. In Stan Jarzabek, Douglas C. Schmidt, and Todd L.
Veldhuizen, editors, Proceedings of the 5th ACM SIGPLAN/SIGSOFT Conference on
Generative Programming and Component Engineering (GPCE 2006), pages 285–294,
Portland, Oregon, October 2006. ACM Press.
[BP02]
Sven A. Brueckner and H. Van Dyke Parunak. Swarming agents for distributed
pattern detection and classification. In Workshop on Ubiquitous Computing, AAMAS
2002, 2002.
[Bri88]
J.-P. Briot. From objects to actors: study of a limited symbiosis in smalltalk-80.
In Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent
programming, pages 69–72, New York, NY, USA, 1988. ACM Press.
[BU04]
Gilad Bracha and David Ungar. Mirrors: Design principles for meta-level facilities of
object-oriented programming languages. In Proceedings of the 19th ACM SIGPLAN
Conference on Object-Oriented Programming Systems, Languages and Applications
(OOPSLA 2004), pages 331–344, Vancouver, British Columbia, Canada, October
2004. ACM Press. ACM SIGPLAN Notices, 39(11).
[CDS74]
V. Cerf, Y. Dalal, and C. Sunshine. Specification of Internet Transmission Control
Program. RFC 675, December 1974.
[CMB+ 07]
Tom Van Cutsem, Stijn Mostinckx, Elisa Gonzalez Boix, Jessie Dedecker, and
Wolfgang De Meuter. Ambienttalk: Object-oriented event-driven programming in
mobile ad hoc networks. In SCCC ’07: Proceedings of the XXVI International
Conference of the Chilean Society of Computer Science, pages 3–12, Washington,
DC, USA, 2007. IEEE Computer Society.
70
BIBLIOGRAPHY
BIBLIOGRAPHY
[CMZ07]
Gabriella Castelli, Marco Mamei, and Franco Zambonelli. Engineering contextual
information for pervasive multiagent systems. In Conference on Engineering
Environment-Mediated Multiagent Systems, EEMMAS07, October 2007.
[Con99]
Salutation Consortium.
Salutation
http://www.salutation.org, 1999.
[CP07]
Xiaohui Cui and Thomas E. Potok. Distributed flocking approach for information
stream clustering analysis. In 7th ACIS International Conference on Software
Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing,
SNPD06, 2007.
[DCM+ 05]
Jessie Dedecker, Tom Van Cutsem, Stijn Mostinckx, Theo D’Hondt, and Wolfgang De
Meuter. Ambient-oriented programming. In OOPSLA ’05: Companion to the
20th annual ACM SIGPLAN conference on Object-oriented programming, systems,
languages, and applications, pages 31–40, New York, NY, USA, 2005. ACM Press.
[DH98]
S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC
2460 (Draft Standard), December 1998. Updated by RFC 5095.
architecture
specification
v2.0c.
[DMVC+ 05] Jessie Dedecker, Stijn Mostinckx, Tom Van Cutsem, Wolfgang De Meuter, and
Theo D’Hondt. Ambient-oriented programming. In OOPSLA 2005 Onward! Track,
October 2005.
[DVM+ 06a] Jessie Dedecker, Tom Van Cutsem, Stijn Mostinckx, Theo D’Hondt, and Wolfgang
De Meuter. Ambient-oriented programming in ambienttalk. In Thomas [Tho06],
pages 230–254.
[DVM+ 06b] Jessie Dedecker, Tom Van Cutsem, Stijn Mostinckx, Theo D’Hondt, and Wolfgang
De Meuter. Ambient-oriented programming in AmbientTalk. In Thomas [Tho06],
pages 230–254.
[EG01]
W. Keith Edwards and Rebecca E. Grinter. At home with ubiquitous computing:
Seven challenges. In 3rd International Conference on Ubiquitous Computing, pages
256–272, Atlanta, Georgia, USA, 2001. Springer-Verlag.
[GHJV94]
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns:
Elements of Reusable Object-Oriented Software. Professional Computing Series.
Addison-Wesley, October 1994.
[GPVD99]
E. Guttman, C. Perkins, J. Veizades, and M. Day. Service location protocol, version
2. http://www.ietf.org/rfc/rfc2608.txt, 1999.
[Gra59]
P.-P. Grasse. Le reconstruction du nid et les coordinations inter-individuelles
chez bellicositermes natalensis et cubitermes sp. la theorie de la stigmergie: essai
71
BIBLIOGRAPHY
BIBLIOGRAPHY
d’interpretation du comportement des termites constructeurs. Insectes Sociaux, 6:41–
81, 1959.
[Gul99]
Laszlo Gulyas. Application of stigmergy - a coordination mechanism for mobile
agents.
In 1st Hungarian National Conference on Agent-Based Computing
(HUNABC’98), pages 143–154, Budapest, 1999. Springer.
[HHM+ 00]
Reto Hermann, Dirk Husemann, Michael Moser, Mike Nidd, Christain Rohner, and
Andreas Schade. DEAPspace: Transient ad-hoc networking of pervasive devices. In
1st ACM international symposium on Mobile ad hoc networking and computing, 2000.
[HKTH02]
Nicholas Hanssens, Ajay Kulkarni, Rattapoom Tuchinda, and Tyler Horton. Building
agent-based intelligent workspaces. In The International Workshop on Agents for
Business Automation, 2002.
[JR06]
Christine Julien and Gruia-Catalin Roman.
EgoSpaces: Facilitating rapid
development of context-aware mobile applications. IEEE Transactions on Software
Engineering, 32(5):281–298, 2006.
[Kay93]
Alan C. Kay. The early history of Smalltalk. ACM SIGPLAN Notices, 28(3):69–95,
March 1993.
[KB02]
Alan Kaminsky and Hans-Peter Bischof. Many-to-many invocation: a new object
oriented paradigm for ad hoc collaborative systems. In OOPSLA ’02: Companion
of the 17th annual ACM SIGPLAN conference on Object-oriented programming,
systems, languages, and applications, pages 72–73, New York, NY, USA, 2002. ACM.
[KF02]
Tim Kindberg and Armando Fox. System software for ubiquitous computing. IEEE
Pervasive Computing, 1(1), 2002.
[LI05]
Jinshan Liu and Valérie Issarny. Signal strength based service discovery (s3d) in
mobile ad hoc networks. In 16th Annual IEEE International Symposium on Personal
Indoor and Mobile Radio Communications, 2005.
[Lie86]
Henry Lieberman. Using prototypical objects to implement shared behavior in objectoriented systems. In Norman Meyrowitz, editor, Proceedings of the 1st International
Conference on Object-Oriented Programming Systems, Languages and Applications
(OOPSLA 86), pages 214–223, Portland, Oregon, USA, October 1986. ACM Press.
ACM SIGPLAN Notices, 21(11).
[Lie87]
Henry Lieberman.
Concurrent object-oriented programming in ACT 1.
In
A. Yonezawa and M. Tokoro, editors, Object-Oriented Concurrent Programming,
pages 9–36. MIT Press, 1987.
72
BIBLIOGRAPHY
BIBLIOGRAPHY
[LV07]
Marco P. Locatelli and Giuseppe Vizzari. Environment support to the management of
context awareness information. In Conference on Engineering Environment-Mediated
Multiagent Systems, EEMMAS07, October 2007.
[MCNC05]
Rene Meier, Vinny Cahill, Andronikos Nedos, and Siobhan Clarke. Proximity-based
service discovery in mobile ad hoc networks. In 5th IFIP International Conference on
Distributed Applications and Interoperable Systems, pages 115–129. Springer-Verlag,
2005.
[Mic]
Sun Microsystems. Jini specifications. http://www.sun.com/software/jini/specs/.
[MTS05]
M. Miller, E. D. Tribble, and J. Shapiro. Concurrency among strangers: Programming
in E as plan coordination. In R. De Nicola and D. Sangiorgi, editors, Symposium on
Trustworthy Global Computing, volume 3705 of LNCS, pages 195–229. Springer, April
2005.
[MVCT+ 09] Stijn Mostinckx, Tom Van Cutsem, Stijn Timbermont, Elisa Gonzalez Boix, Éric
Tanter, and Wolfgang De Meuter. Mirror-based reflection in AmbientTalk. Software—
Practice and Experience, 39(7):661–699, May 2009.
[MVCTT07] Stijn Mostinckx, Tom Van Cutsem, Stijn Timbermont, and Éric Tanter. Mirages:
Behavioral intercession in a mirror-based architecture. In Proceedings of the ACM
Dynamic Languages Symposium (DLS 2007), pages 89–100, Montreal, Canada,
October 2007. ACM Press.
[MZ05]
M. Mamei and F. Zambonelli. Spreading pheromones in everyday environments via
rfid technologies. In 2nd IEEE Symposium on Swarm Intelligence, June 2005.
[NH06]
Renzo De Nardi and Owen Holland. Ultraswarm: A further step towards a flock of
miniature helicopters. In SAB Workshop on Swarm Robotics, 2006.
[NHWC06]
Renzo De Nardi, Owen Holland, John Woods, and Adrian Clark. Swarmav: A swarm
of miniature aerial vehicles. In 21st International UAV Systems Conference, April
2006.
[ns2]
The network simulator - ns2. http://www.isi.edu/nsnam/ns/.
[OS06]
R. Olfati-Saber. Flocking for multi-agent dynamic systems: algorithms and theory.
IEEE Transactions on Automatic Control, 51(3):401–420, March 2006.
[PLF+ 01]
Shankar Ponnekanti, Brian Lee, Armando Fox, Pat Hanrahan, and Terry Winograd.
Icrafter: A service framework for ubiquitous computing environments. In 3rd
International Conference on Ubiquitous Computing, 2001.
[Pos80]
J. Postel. User Datagram Protocol. RFC 768 (Standard), August 1980.
73
BIBLIOGRAPHY
BIBLIOGRAPHY
[RDTB08]
Victor Ramiro, Jessie Dedecker, Éric Tanter, and Peter Barron. Experimenting with
language support for proximity in ambient-oriented programming. In Danny Weyns,
Sven A. Brueckner, and Yves Demazeau, editors, Engineering Environment-Mediated
Multi-Agent Systems (EEMMAS 2007), volume 5049 of Lecture Notes in Artificial
Intelligence, pages 259–283. Springer-Verlag, 2008.
[RHC+ 02]
Manuel Roman, Christopher Hess, Renato Cerqueira, Anand Ranganathan, Roy H.
Campbell, and Klara Nahrstedt. Gaia: a middleware platform for active spaces.
SIGMOBILE Mob. Comput. Commun. Rev., 6(4):65–67, 2002.
[rmi]
Java remote method invocation - distributed computing for java.
[ROV+ 06]
Alessandro Ricci, Andrea Omicini, Mirko Viroli, Luca Gardelli, and Enrico Oliva.
Cognitive stigmergy: Towards a framework based on agents and artifacts. In
Environments for Multiagent Systems, E4MAS06, pages 124–140, 2006.
[Sat01]
M. Satyanarayanan. Pervasive computing: vision and challenges. IEEE Personal
Communications, 8(4):10 –17, Aug 2001.
[SHB05]
Kurt Schelfthout, Tom Holvoet, and Yolande Berbers.
Views: Middleware
abstractions for context-aware applications in manets. In 5th International Workshop
on Software Engineering for Large-scale Multi-Agent Systems, 2005.
[Ste07]
R. Stewart. Stream Control Transmission Protocol. RFC 4960 (Proposed Standard),
September 2007.
[Sus75]
Gerald Jay Sussman. Scheme: An interpreter for extended lambda calculus. In Memo
349, MIT AI Lab, 1975.
[Tho06]
Dave Thomas, editor. Proceedings of the 20th European Conference on ObjectOriented Programming (ECOOP 2006), number 4067 in Lecture Notes in Computer
Science, Nantes, France, July 2006. Springer-Verlag.
[TJP03a]
H.G. Tanner, A. Jadbabaie, and G.J Pappas. Stable flocking of mobile agents, part I:
fixed topology. In 42nd IEEE Conference on Decision and Control, December 2003.
[TJP03b]
H.G. Tanner, A. Jadbabaie, and G.J Pappas. Stable flocking of mobile agents, part
II: dynamic topology. In 42nd IEEE Conference on Decision and Control, December
2003.
[US87]
David Ungar and Randall B. Smith. Self: The power of simplicity. In Norman
Meyrowitz, editor, Proceedings of the 2nd International Conference on ObjectOriented Programming Systems, Languages and Applications (OOPSLA 87), pages
227–241, Orlando, Florida, USA, October 1987. ACM Press. ACM SIGPLAN Notices,
22(12).
74
BIBLIOGRAPHY
BIBLIOGRAPHY
[Van08]
Tom Van Cutsem. Ambient References: Object Designation in Mobile Ad Hoc
Networks. PhD thesis, Vrije Universiteit Brussel, Faculty of Sciences, Programming
Technology Lab, May 2008.
[VKB+ 01]
Paul Valckenaers, Martin Kollingbaum, Hendrik Van Brussel, Olaf Bochmann, and
C. Zamfirescu. The design of muilt-agent coordination and control systems using
stigmergy. In International Workshop on Emergent Synthesis, IWES01, March 2001.
[Wei91]
Mark Weiser. The computer for the twenty-first century. Scientific American, pages
94–104, September 1991.
[WOO07]
Danny Weyns, Andrea Omicini, and James Odelli. Environment as a first class
abstraction in multiagent systems. Autonomous Agents and Multi-Agent Systems,
14(1):5–30, 2007.
[YBS86]
Akinori Yonezawa, Jean-Pierre Briot, and Etsuya Shibayama. Object-oriented
concurrent programming in ABCL/1. In Conference proceedings on Object-oriented
programming systems, languages and applications, pages 258–268. ACM Press, 1986.
[YLJK04]
Hyeon-Ju Yoon, Eun-Ju Lee, Hyunku Jeong, and Jin-Soo Kim. Proximity-based
overlay routing for service discovery in mobile ad hoc networks. In International
Symposium on Computer and Information Sciences, pages 176–186. Springer-Verlag,
2004.
75

universidad de chile facultad de ciencias físicas y matem

Transcription

Similar documents

Indala Prox Brochure

Policymakers` Horizon and Trade Reforms

Industrial Heat Protective Clothing And

Fyrepel Industrial Heat Protective Clothing

a PDF copy here

View - Christian PhoneBook

PDF Template - A Door Properties

Simple, SucceSSful compoSite RepaiRS

Remarks Page 1 of 3 MLS 6/2/2013 http://prospector.metrolist.net