universidad de chile facultad de ciencias físicas y matem
Transcription
universidad de chile facultad de ciencias físicas y matem
UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN UN MODELO ABIERTO DE PROXIMIDAD PARA EL DESCUBRIMIENTO DE SERVICIOS EN COMPUTACIÓN PERVASIVA TESIS PARA OPTAR AL GRADO DE MAGÍSTER EN CIENCIAS, MENCIÓN COMPUTACIÓN MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN VICTOR ALEJANDRO RAMIRO CID PROFESOR GUÍA: ÉRIC TANTER MIEMBROS DE LA COMISIÓN: JOHAN FABRY PATRICIO INOSTROZA FAJARDIN LUCIANO AHUMADA FIERRO SANTIAGO DE CHILE JUNIO 2009 Resumen La relación entre personas y computadores ha cambiado dramáticamente en los últimos años. Hoy en dı́a las personas interactúan, cada vez más, con un mayor número de dispositivos, como el computador personal, notebook, reproductores musicales y de video, celulares, etc. Estos dispositivos a su vez han empezado a interactúar entre ellos, compartiendo informació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 fácil la publicación y descubrimiento de servicios. El descubrimiento de estos puede ser una tarea relativamente compleja en un ambiente donde interactú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 investigación en sistemas distribuidos y desarrollo de middleware especı́fico hasta nuevas abstracciones en lenguajes de programació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 interés definidos por el usuario. Este contenido de interé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 percepció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 interés. Esto sin considerar el carácter dinámico del grafo de conexiones que simplemente no se toma en cuenta, y por lo tanto no se permite la actualización de la relación de proximidad entre dispositivos. Este trabajo presenta el diseño de un modelo abierto de proximidad. La integración de este modelo con el descubrimiento de servicios permite definir, a través de funciones de proximidad, el alcance de la búsqueda del cliente y de la publicación del servidor. Presentamos las componentes necesarias para definir la noción de “relaciones de proximidad”. Dicha relación considera los cambios periódicos que ocurren entre nodos en una red ad-hoc. Además se presenta la semántica distribuida de las relaciones y tres estrategias para implementarlas. Estas estrategias muestran, en base a un análisis de peor caso, las decisiones de diseño tomadas entre simpleza y eficiencia. Finalmente, se muestra la implementación de este modelo en el lenguaje de programación AmbientTalk. Este lenguaje está 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. Además presentamos un análisis experimental del descubrimiento de servicios de AmbientTalk y lo comparamos con nuestro modelo abierto de proximidad. Esta comparación nos muestra como el modelo abierto de proximidad disminuye las interacciones innecesarias, permitiendo definir una noció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 ésta, y menos aún describir las infinitas ayudas que recibı́ de ellos, pero sin duda puedo resumir acá 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 Mamá, gracias Papá. Su apoyo siempre ha sido imprescindible para cada paso que he dado en mi vida. A mis hermanos, gracias por hacer más fácil el pasar por la universidad, gracias por compartir una risa, una conversación, un minuto de tranquilidad. Palabras especiales tengo para mi amada Cata, quien ha sabido acompañarme fielmente durante todo este proceso. Muchas gracias por tu comprensión y por todo el tiempo que te he robado. Segundo quiero agradecer a mis amigos. A los largo de estos años he aprendido que no hay nada mejor que trabajar con ellos. Los de siempre, desde el plan comú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 investigación: Rodolfo Toledo, Paul Leger, Guillaume Pothier, Oscar Alvarez y Richard Ibarra. A la gente de la VUB en Bélgica, que me recibió 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 compañeros de Niclabs, que han soportado mi tema de tesis durante todo este tiempo: Tomás Barros (¡gracias por todo!), Carlos Collao, Jonathan Frez y Nicolás Singh. Por último un saludo muy especial a Angélica Aguirre que me apoyó en todo el infinito papeleo para poder terminar. A mis profesores de la comisión les agradezco mucho por sus comentarios que permitieron mejorar varios aspectos de la tesis, y en particular les agradezco su disposición para coordinar y facilitar la defensa de esta tesis. Simplemente ¡me salvaron!. Finalmente quiero agradecer a mi profesor guı́a É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 también por darme la oportunidad de conocer el mundo de la investigación y por las largas conversaciones de orientación que tuvimos. Solo las vueltas de la vida dirá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 acompañaron en este camino. Este trabajo recibió 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 : É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 2.2. AmbientTalk in a Nutshell • 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 2.2. AmbientTalk in a Nutshell 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 2.2. AmbientTalk in a Nutshell • 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 2.2. AmbientTalk in a Nutshell 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 2.2. AmbientTalk in a Nutshell 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 2.2. AmbientTalk in a Nutshell 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. Figure 3: Invoking a method on an omnihandle 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 plicitly unexported: 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: Figure 4: A unihandle 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 Figure 3: Invoking a method on an omnihandle Once exported, an object stays exp plicitly unexported: plicitly unexported: 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 Figure 4: A unihandle ing mechanism [15, 1] expl Figure 2.4: M2MI Unihandle 3.4 Unihandles Figure 4: A unihandle 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 5: Invoking a method on a unihandle Figure 5: Invoking a method on a unihandle 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 3.3. Open proximity model for scoping service discovery 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 3.3. Open proximity model for scoping service discovery 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 3.3. Open proximity model for scoping service discovery 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 3.3. Open proximity model for scoping service discovery 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 3.3. Open proximity model for scoping service discovery 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 3.3. Open proximity model for scoping service discovery 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 3.3. Open proximity model for scoping service discovery 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 3.3. Open proximity model for scoping service discovery 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 3.3. Open proximity model for scoping service discovery 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 4.2. Open Proximity Model in AmbientTalk 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 4.2. Open Proximity Model in AmbientTalk 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 4.2. Open Proximity Model in AmbientTalk 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 4.2. Open Proximity Model in AmbientTalk 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 4.2. Open Proximity Model in AmbientTalk 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 4.2. Open Proximity Model in AmbientTalk 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 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 ; 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 4.2. Open Proximity Model in AmbientTalk 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 4.2. Open Proximity Model in AmbientTalk 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 4.2. Open Proximity Model in AmbientTalk 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 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 ; 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 4.2. Open Proximity Model in AmbientTalk SD Layer (C) Client Gatherer Multicast Server Gatherer SD Layer (S) export (type, serv handler) registerHandler (type, client handler) 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() CG.retrieveService(Service) alreadySeen(Service) ? updateLastTimeSeen : 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 4.2. Open Proximity Model in AmbientTalk 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 4.2. Open Proximity Model in AmbientTalk SD Layer (C) Client Gatherer Server Gatherer Multicast SD Layer (S) export (type, serv handler) registerHandler (type, client handler) 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() alreadySeen(Service) ? updateLastTimeSeen : trackNewService CG.retrieveService(Service) 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 5.1. Experiment Design 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 5.1. Experiment Design (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 Valé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, É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 É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, É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