Distributed Applications and Interoperable Systems: 10th IFIP WG 6.1 International Conference, DAIS 2010, Amsterdam, The Netherlands, June 7-9, 2010, ... Networks and Telecommunications)

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Alfred Kobsa University of California, Irvine, CA, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen TU Dortmund University, Germany Madhu Sudan Microsoft Research, Cambridge, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Gerhard Weikum Max-Planck Institute of Computer Science, Saarbruecken, Germany

6115

Frank Eliassen Rüdiger Kapitza (Eds.)

Distributed Applications and Interoperable Systems 10th IFIP WG 6.1 International Conference, DAIS 2010 Amsterdam, The Netherlands, June 7-9, 2010 Proceedings

13

Volume Editors Frank Eliassen University of Oslo, Department of Informatics P.O. Box 1080 Blindern, 0316 Oslo, Norway E-mail: [email protected] Rüdiger Kapitza Friedrich-Alexander University Erlangen-Nuremberg, Computer Science 4 Martensstraße 1, 91058 Erlangen, Germany E-mail: [email protected]

Library of Congress Control Number: 2010927935 CR Subject Classification (1998): C.2, D.2, H.4, H.5, H.3, C.4 LNCS Sublibrary: SL 5 – Computer Communication Networks and Telecommunications ISSN ISBN-10 ISBN-13

0302-9743 3-642-13644-3 Springer Berlin Heidelberg New York 978-3-642-13644-3 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. springer.com © IFIP International Federation for Information Processing 2010 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper 06/3180

Foreword

In 2010 the International Federated Conference on Distributed Computing Techniques (DisCoTec) took place in Amsterdam, during June 7-9. It was hosted and organized by the Centrum voor Wiskunde & Informatica. DisCoTec conferences jointly cover the complete spectrum of distributed computing subjects ranging from theoretical foundations to formal specification techniques to practical considerations. The 12th International Conference on Coordination Models and Languages (Coordination) focused on the design and implementation of models that allow compositional construction of large-scale concurrent and distributed systems, including both practical and foundational models, run-time systems, and related verification and analysis techniques. The 10th IFIP International Conference on Distributed Applications and Interoperable Systems in particular elicited contributions on architectures, models, technologies and platforms for large-scale and complex distributed applications and services that are related to the latest trends towards bridging the physical/virtual worlds based on flexible and versatile service architectures and platforms. The 12th Formal Methods for Open Object-Based Distributed Systems and 30th Formal Techniques for Networked and Distributed Systems together emphasized distributed computing models and formal specification, testing and verification methods. Each of the three days of the federated event began with a plenary speaker nominated by one of the conferences. On the first day Joe Armstrong (Ericsson Telecom AB) gave a keynote speech on Erlang-style concurrency, and on the second day Gerard Holzmann (Jet Propulsion Laboratory, USA) discussed the question “Formal Software Verification: How Close Are We?”. On the third and last day Joost Roelands (Director of Development Netlog) presented the problem area of distributed social data. In addition, there was a joint technical session consisting of one paper from each of the conferences and an industrial session with presentations by A. Stam (Almende B.V., Information Communication Technologies) and M. Verhoef (CHESS, Computer Hardware & System Software) followed by a panel discussion. There were four satellite events: the Third DisCoTec Workshop on Contextaware Adaptation Mechanisms for Pervasive and Ubiquitous Services (CAMPUS), the First International Workshop on Interactions Between Computer Science and Biology (CS2BIO) with keynote lectures by Luca Cardelli (Mi´ crosoft Research - Cambridge, UK) and J´erˆome Feret (INRIA and Ecole Normale Sup´erieure - Paris, France), the First Workshop on Decentralized Coordination of Distributed Processes (DCDP) with a keynote lecture by Tyler Close (Google), and the Third Interaction and Concurrency Experience Workshop with keynote lectures by T. Henzinger (IST, Austria) and J.-P. Katoen (RWTH Aachen University, Germany).

VI

Foreword

I hope this rich program offered every participant interesting and stimulating events. It was only possible thanks to the dedicated work of the Publicity Chair Gianluigi Zavattaro (University of Bologna, Italy), the Workshop Chair Marcello Bonsangue (University of Leiden, The Netherlands) and the members of the Organizing Committee, Susanne van Dam, Immo Grabe, Stephanie Kemper and Alexandra Silva. To conclude I want to thank the sponsorship of the International Federation for Information processing (IFIP), the Centrum voor Wiskunde & Informatica and the Netherlands Organization for Scientific Research (NWO). June 2010

Frank S. de Boer

Preface

This volume contains the proceedings of DAIS 2010, the IFIP International Working Conference on Distributed Applications and Interoperable Systems. The conference was held in Amsterdam, The Netherlands, during June 7-9, 2010 as part of DisCoTec (Distributed Computing Techniques) Federated Conference, together with the International Conference on Formal Techniques for Distributed Systems (FMOODS & FORTE) and the International Conference on Coordination Models and Languages (COORDINATION). The DAIS 2010 conference was sponsored by IFIP (International Federation for Information Processing) in-cooperation with ACM SIGSOFT and ACM SIGAPP, and it was the tenth conference in the DAIS series of events organized by IFIP Working Group 6.1. The conference program presented the state of the art in research on distributed and interoperable systems. Distributed application technology has become a foundation of the information society. New computing and communication technologies have brought up a multitude of challenging application areas, including mobile computing, interenterprise collaborations, ubiquitous services, service-oriented architectures, autonomous and self-adapting systems, peer-to-peer systems, just to name a few. New challenges include the need for novel abstractions supporting the development, deployment, management, and interoperability of evolutionary and complex applications and services, such as those bridging the physical/virtual worlds. Therefore, the linkage between applications, platforms and users through multidisciplinary user requirements (like security, privacy, usability, efficiency, safety, semantic and pragmatic interoperability of data and services, dependability, trust and self-adaptivity) becomes of special interest. It is envisaged that future complex applications will far exceed those of today in terms of these requirements. The main part of the conference program comprised presentations of the accepted papers. This year, the technical program of DAIS drew from 53 submitted papers. All papers were reviewed by at least three reviewers. After initial reviews were posted, a set of candidate papers were selected and subject to discussion among the reviewers and Program Committee Chairs to resolve differing viewpoints. As a result of this process, 17 full papers were selected for inclusion in the proceedings. The papers presented at DAIS 2010 address integration and QoS provisioning of ubiquitous services and applications, grid computing including reconfiguration languages and volunteer computing, sensor network distributed programming and middleware, context-awareness, composition and discovery of ubiquitous services, fault-tolerance and fault-tolerant controllers, cloud and cluster computing, and adaptive and (re)configurable systems. Finally, we would like to take this opportunity to thank the numerous people whose work made this conference possible. We wish to express our deepest

VIII

Preface

gratitude to the authors of submitted papers, to all Program Committee members for their active participation in the paper review process, to all external reviewers for their help in evaluating submissions, to the Centrum Wiskunde & Informatics (CWI) for hosting the event, to the Publicity Chairs, to Romain Rouvoy who took care of the practical work with the proceedings, to the DAIS Steering Committee for their advice, and to Frank S. de Boer for acting as General Chair of the joint event. June 2010

Frank Eliassen R¨ udiger Kapitza

DAIS 2010 Organization

Executive Committee Program Chairs:

Publicity Chairs:

Proceedings Chair:

Frank Eliassen (University of Oslo, Norway) R¨ udiger Kapitza (University of Erlangen, Germany) Hans P. Reiser (University of Lisbon, Portugal) Johan Fabry (Universidad de Chile, Chile) Charles Zhang (Hong Kong University of Science and Technology, China) Gianluigi Zavattaro (University of Bologna, Italy) Romain Rouvoy (University of Lille 1, France)

Steering Committee Kurt Geihs Jadwiga Indulska Lea Kutvonen Elie Najm Rui Oliveira Ren´e Meier Twittie Senivongse Sotirios Terzis

University of Kassel, Germany University of Queensland, Australia University of Helsinki, Finland ENST, France Universidade do Minho, Portugal Trinity College Dublin, Ireland Chulalongkorn University, Thailand University of Strathclyde, UK

Sponsoring Institutions IFIP WG 6.1 ACM SIGSOFT ACM SIGAPP

Program Committee M. Aoyama J. E. Armend´ ariz-´I˜ nigo D. Bakken Y. Berbers A. Beresford A. Beugnard G. Blair

Nanzan University, Japan Universidad P´ ublica de Navarra, Spain Washington State University, USA Katholieke Universiteit Leuven, Belgium University of Cambridge, UK TELECOM Bretagne, France Lancaster University, UK

X

Organization

A. Casimiro E. Cecchet I. Demeure S. Dobson J. Dowling D. Donsez N. Dulay F. Eliassen S. Elnikety P. Felber K. Geihs N. Georgantas K. G¨ oschka R. Grønmo D. Hagimont S. Hallsteinsen P. Herrmann J. Indulska R. Kapitza H. K¨ onig R. Kroeger L. Kutvonen W. Lamersdorf M. Lawley P. Linington C. Linnhoff-Popien K. Lund R. Macˆedo R. Meier A. Montresor E. Najm N. Narasimhan R. Oliveira G. Pierre P. Pietzuch A. Puder R. Rouvoy D. Schmidt T. Senivongse

University of Lisbon, Portugal University of Massachusetts, USA ENST, France University of St. Andrews, UK SICS, Sweden Universit´e Joseph Fourier - Grenoble 1, France Imperial College London, UK University of Oslo, Norway Microsoft Research, USA Universit´e de Neuchˆatel, Switzerland University of Kassel, Germany INRIA, France Vienna University of Technology, Austria SINTEF, Norway INP Toulouse, France SINTEF, Norway NTNU Trondheim, Norway University of Queensland, Australia University of Erlangen-N¨ urnberg, Germany BTU Cottbus, Germany Wiesbaden University of Applied Sciences, Germany University of Helsinki, Finland University of Hamburg, Germany Queensland University of Technology, Australia University of Kent, UK Munich University, Germany Norwegian Defence Research Establishment (FFI), Norway Federal University of Bahia, Brazil Trinity College Dublin, Ireland University of Trento, Italy ENST, France Motorola Labs, USA Universidade do Minho, Portugal Vrije Universiteit Amsterdam, The Netherlands Imperial College London, UK State University San Francisco, USA University of Lille 1, France Vanderbilt University, USA Chulalongkorn University, Thailand

Organization

K. Sere S. Terzis H. Yokota

XI

˚ Abo Akademi University, Finland University of Strathclyde, UK Tokyo Institute of Technology, Japan

Distributed Computing Techniques 2010 Organizing Committee Frank S. de Boer Susanne van Dam Immo Grabe Stephanie Kemper Alexandra Silva Gianluigi Zavattaro Marcello M. Bonsangue

Centrum Wiskunde & Informatica (CWI), The Netherlands (General Chair) Centrum Wiskunde & Informatica (CWI), The Netherlands Centrum Wiskunde & Informatica (CWI), The Netherlands Centrum Wiskunde & Informatica (CWI), The Netherlands Centrum Wiskunde & Informatica (CWI), The Netherlands University of Bologna, Italy (Publicity Chair) University of Leiden, The Netherlands (Workshops Chair)

Additional Referees L. Broto S. Chollet A. Diaconescu I. Dionysiou M. D¨ urr H. Gjermundrød K. Hamann T. H¨onig K. Jander

F.A. Kraemer L. Laibinis R. Lasowski J. Pereira L. Petre W. Rudametkin P. Sandvik S. Schober M. Segarra

L. Seinturier G. Simon A. Vilenica Y. Watanabe K. Weckemann T. Weise M. Werner

Table of Contents

Ubiquitous Services and Applications RESTful Integration of Heterogeneous Devices in Pervasive Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Daniel Romero, Gabriel Hermosillo, Amirhosein Taherkordi, Russel Nzekwa, Romain Rouvoy, and Frank Eliassen Hosting and Using Services with QoS Guarantee in Self-adaptive Service Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Shanshan Jiang, Svein Hallsteinsen, Paolo Barone, Alessandro Mamelli, Stephan Mehlhase, and Ulrich Scholz

1

15

Grid Computing Validating Evolutionary Algorithms on Volunteer Computing Grids . . . . Travis Desell, Malik Magdon-Ismail, Boleslaw Szymanski, Carlos A. Varela, Heidi Newberg, and David P. Anderson

29

A Reconfiguration Language for Virtualized Grid Infrastructures . . . . . . . R´emy Pottier, Marc L´eger, and Jean-Marc Menaud

42

Sensor Networks Distributed Object-Oriented Programming with RFID Technology . . . . . Andoni Lombide Carreton, Kevin Pinte, and Wolfgang De Meuter WISeMid: Middleware for Integrating Wireless Sensor Networks and the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jeisa P.O. Domingues, Antonio V.L. Damaso, and Nelson S. Rosa

56

70

Context Awareness Structured Context Prediction: A Generic Approach . . . . . . . . . . . . . . . . . . Matthias Meiners, Sonja Zaplata, and Winfried Lamersdorf

84

Service Orientation Experiments in Model Driven Composition of User Interfaces . . . . . . . . . . Audrey Occello, Cedric Joffroy, and Anne-Marie Dery-Pinna

98

XIV

Table of Contents

Service Discovery in Ubiquitous Feedback Control Loops . . . . . . . . . . . . . . Daniel Romero, Romain Rouvoy, Lionel Seinturier, and Pierre Carton

112

Distributed Fault Tolerant Controllers QoS Self-configuring Failure Detectors for Distributed Systems . . . . . . . . . Alirio Santos de S´ a and Raimundo Jos´e de Ara´ ujo Macˆedo

126

Distributed Fault Tolerant Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Leonardo Mostarda, Rudi Ball, and Naranker Dulay

141

Cloud and Cluster Computing Automatic Software Deployment in the Azure Cloud . . . . . . . . . . . . . . . . . Jacek Cala and Paul Watson G2CL: A Generic Group Communication Layer for Clustered Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Leandro Sales, Henrique Te´ ofilo, and Nabor C. Mendon¸ca

155

169

Adaptive and (Re)configurable Systems Dynamic Composition of Cross-Organizational Features in Distributed Software Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stefan Walraven, Bert Lagaisse, Eddy Truyen, and Wouter Joosen

183

Co-ordinated Utility-Based Adaptation of Multiple Applications on Resource-Constrained Mobile Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ulrich Scholz and Stephan Mehlhase

198

Collaborative Systems gradienTv: Market-Based P2P Live Media Streaming on the Gradient Overlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Amir H. Payberah, Jim Dowling, Fatemeh Rahimian, and Seif Haridi Collaborative Ranking and Profiling: Exploiting the Wisdom of Crowds in Tailored Web Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pascal Felber, Peter Kropf, Lorenzo Leonini, Toan Luu, Martin Rajman, and Etienne Rivi`ere Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

212

226

243

RESTful Integration of Heterogeneous Devices in Pervasive Environments Daniel Romero1, Gabriel Hermosillo1, Amirhosein Taherkordi2, Russel Nzekwa1 , Romain Rouvoy1, and Frank Eliassen2 1

INRIA Lille-Nord Europe, ADAM Project-team University of Lille 1, LIFL CNRS UMR 8022 59650 Villeneuve d’Ascq, France [email protected] 2 Department of Informatics University of Oslo 0316 Oslo, Norway [email protected], [email protected]

Abstract. More and more home devices are equipped with advanced computational capabilities to improve the user satisfaction (e.g., programmable heating system, Internet TV). Although these devices exhibit communication capabilities, their integration into a larger home monitoring system remains a challenging task, partly due to the strong heterogeneity of technologies and protocols. In this paper, we therefore propose to reconsider the architecture of home monitoring systems by focusing on data and events that are produced and triggered by home devices. In particular, our middleware platform, named D IGI H OME , applies i) the REST (REpresentational State Transfer) architectural style to leverage on the integration of multi-scale systems-of-systems (from Wireless Sensor Networks to the Internet) and ii) a CEP (Complex Event Processing) engine to collect information from heterogeneous sources and detect application-specific situations. The benefits of the D IGI H OME platform are demonstrated on smart home scenarios covering home automation, emergency detection, and energy saving situations.

1 Introduction Pervasive environments support context-aware applications that adapt their behavior by reasoning dynamically over the user and the surrounding information. This contextual information generally comes from diverse and heterogeneous sources, such as physical devices, Wireless Sensors Networks (WSNs), and smartphones. In order to exploit the information provided by these sources, an integration middleware is required to collect, process, and distribute the contextual information efficiently. However, the heterogeneity of systems in terms of technology capabilities and communication protocols, the mobility of the different interacting entities and the identification of adaptation situations makes this integration difficult. Thus, we need to provide a flexible solution in terms of communication and context processing to leverage context-aware applications on the integration of heterogeneous context providers. F. Eliassen and R. Kapitza (Eds.): DAIS 2010, LNCS 6115, pp. 1–14, 2010. c IFIP International Federation for Information Processing 2010 

2

D. Romero et al.

In particular, a solution dealing with context information and control environments must be able to connect with a wide range of device types. However, the resource scarceness in WSNs and mobile devices makes the development of such a solution very challenging. In this paper, we propose the D IGI H OME platform, a simple but efficient middleware solution to facilitate context-awareness in pervasive environments. Specifically, D IGI H OME provides support for the integration, processing and adaptation of the context-aware applications. Our solution enables the integration of heterogeneous computational entities by relying on the REST (REpresentational State Transfer) principles [8], standard discovery and communication protocols, and resource representation formats. We believe that the REST concepts of simplicity (in terms of interaction protocols) and flexibility (regarding the supported representation formats) make it a suitable architecture style for integration in pervasive environments. Furthermore, while our solution also benefits from WSNs to operate simple event reasoning on the sensor nodes, we rely on Complex Event Processing [19] for analyzing in real-time the relationships between the different collected events and trigger rule-based adaptations. The rest of this paper is organized as follows. We start by describing a smart home scenario in which we identify the key challenges in pervasive environments that motivate this work (cf. section 2). We continue by the description of D IGI H OME, our middleware platform to support the integration of systems-of-systems in pervasive environments (cf. section 3). Then, we discuss the benefits of our approach (cf. section 4) before discussing the related work (cf. section 5). Finally, we conclude by presenting some promising perspectives for this work (cf. section 6).

2 Background and Motivations This section introduces the application and architectural foundations of our work in sections 2.1 and 2.3, respectively. 2.1 Motivating Scenario A smart home generally refers to a house environment equipped with several types of computing entities, such as sensors, which collect physical information (temperature, movement detection, noise level, light, etc.), and actuators, which change the state of the environment. In this scenario, we consider a smart home equipped with occupancy, smoke detection, and temperature sensors. These tiny devices have the ability of collecting context information and communicating wirelessly with each other, in order to identify the context situation of the environment. In addition to that, we can also find actuators to physically control lights, TV, and air conditioning. Figure 1 illustrates the integration of these sensors and actuators in our scenario. As appreciated in this figure, the different entities use heterogenous protocols to interact. In the scenario, the smart phones provide information about user preferences for home configuration. Conflicts between the user preferences are resolved by giving priority to the person who arrived first to the room. The mobile devices also have an application that enables the control of the actuators present in the different rooms. This application can be adapted when

RESTful Integration of Heterogeneous Devices in Pervasive Environments

Legend

Actuator

3

Information Source

HOME User's Preferences

Activation

Smart Phone SMS, HTTP

Sprinkler Adjust Temperature

SOAP

x10

ACN

Lightning Level

Bulb

HES

Air Conditioner

Event Processing

UPnP

On/Off, Channel, Volume

TCP/IP STB

Room image

ZigBee TV

ZigBee ZigBee

Smoke Detected

Video Camera Current Temperature

ZigBee

People in the Room Smoke Sensor

Temperature Sensor

Occupancy Sensor

Fig. 1. Interactions between the smart home devices

there are changes in the actuator’s configuration. Finally, there is a Set-Top Box (STB) which is able to gather information, and interact with the other co-located devices. Situation 1: Alice arrives to the living room. The occupancy sensor detects her presence and triggers the temperature sensors to decrease the sampling rate of data. It also notifies the STB that the room is occupied by somebody, which in turn tries to identify the occupant by looking for a profile in her mobile device. When Alice’s profile is found, the STB loads it and adjusts the temperature and lightening level of the room according to Alice’s preferences. Situation 2: The sensors detect smoke and notify the STB, which using the occupancy sensor, detects that the house is empty. The STB therefore notifies Alice via an SMS, and includes a picture of the room, captured using the surveillance camera. After checking the picture, Alice decides to remotely trigger the sprinklers using her mobile device. She also tells the system to alert the fire department about the problem. If Alice does not reply to the STB within 5 minutes, the system activates automatically the sprinklers and alerts the fire department. Situation 3: Alice installs a new TV in the bedroom. The STB detects the presence of the new device, identifies it, and downloads the corresponding control software from an Internet repository. The platform tries to locate the available mobile devices and finds Alice’s mobile device. The STB propose to update the mobile device with the components for controlling the new TV.

4

D. Romero et al.

2.2 Key Challenges The above described situations allow us to identify several key challenges in terms of: 1. Integration of multi-scale entities: The mobiles devices and sensors have different hardware and software capabilities, which make some devices more powerful than others. Therefore, this heterogeneity requires a flexible and simple solution that supports multiple interaction mechanisms and considers the restricted capabilities of some devices. In particular, regarding sensor nodes, the immaturity of high-level communication protocols, as well as the inherent resource scarceness, bring two critical challenges to our work: 1) how to connect sensor nodes to mobile devices and actuators through a standard high-level communication protocol, and 2) the framework which runs over sensor nodes for supporting context-awareness and adaptation should not impose high resource demands. 2. Entities mobility: In our scenario, computational entities appear and disappear constantly. In particular, mobile devices providing user profiles are not always accessible (they can be turned off or the owner can leave the house with them). In a similar way, the actuators can be replaced or new ones can be added. Thus, we need to provide the functionality to discover new entities dynamically and to support device disconnections. 3. Information processing and adaptation: In order to support adaptation, we first need to identify the situations in which the adaptation is required. We have a lot of information that is generated by the different devices in the environment and we need to define which part of this information is useful in order to identify relevant situations and react accordingly. In our scenario, those situations include the load of Alice’s profile and the adjustment of the temperature, the sending of an alert via SMS in case of an emergency, and the adaptation of Alice’s mobile device to control the new TV in her bedroom. 2.3 REST: REpresentational State Transfer REpresentational State Transfer (REST) is a resource-oriented software architecture style identified by R. Fielding for building Internet-scale distributed applications [8]. Typically, the REST triangle defines the principles for encoding (content types), addressing (nouns), and accessing (verbs) a collection of resources using Internet standards. Resources, which are central to REST, are uniquely addressable using a universal syntax (e.g., a URL in HTTP) and share a uniform interface for the transfer of application states between client and server (e.g., GET/POST/PUT/DELETE in HTTP). REST resources may typically exhibit multiple typed representations using— for example—XML, JSON, YAML, or plain text documents. Thus, RESTful systems are loosely-coupled systems which follow these principles to exchange application states as resource representations. This kind of stateless interactions improves the resources consumption and the scalability of the system. According to R. Fielding [8], “REST’s client-server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries—proxies, gateways, and

RESTful Integration of Heterogeneous Devices in Pervasive Environments

5

firewalls—to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching. REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability.” Synthesis. REST identifies an efficient architectural style for disseminating resources, which can be encoded under various representations. Therefore, we believe that REST provides a suitable framework for mediating and processing context information in an efficient and scalable manner.

3 The D IGI H OME Platform In order to address the challenges introduced in section 2.2, we propose the D IGI H OME middleware platform for pervasive environments. The main objective of D IGI H OME is to provide a comprehensive and simple solution for dealing with context processing in this kind of environments. To do that, the platform offers services for integration of context information and the detection of adaptation situations based on this information. D IGI H OME also benefits from the WSNs capabilities to process simple events and make local decisions when possible. With D IGI H OME, we can support variants of the platform for resource-constrained devices (sensor nodes or mobile devices in our scenario) that interact with powerful variants running on more powerful devices (e.g., the STB in the smart scenario). Figure 2 depicts the general architecture of D IGI H OME. In this architecture, the Event Collector retrieves and stores the recent information produced by context collectors, such as mobile devices or sensors. The CEP Engine is responsible for event processing and uses the Decision Executor to perform actions specified by the Adaptation Rules. In D IGI H OME, the integration of the heterogenous entities is achieved via the RESTful Communication middleware framework that provides software connectors following the REST principles. In the rest of this section, we give more details about the integration of the information via REST (cf. section 3.1), the complex event processing (cf. section 3.2) and the distribution of D IGI H OME platforms in WSNs (cf. section 3.3). Finally, section 3.4 reports optimizations that are applied to the platform in order to control the reactivity and the stability of the system. 3.1 RESTful Communication Middleware The integration challenge identified in section 2.2 requires a flexible infrastructure enabling communication and discovery between all the participants (i.e., mobile devices, sensor nodes, actuators, and the set-top box). To address this issue, we classify the heterogeneity in terms of resources and different interaction mechanisms. This communication middleware that we define in D IGI H OME therefore follows the REST principles. The simplicity, lightness, reusability, extensibility, and flexibility properties that characterize REST make it a suitable option for context dissemination in pervasive environments.

6

D. Romero et al.

Lightning Level ACN

Sprinkler

Application

X10

ACN Connector

DigiHome Platform

HTTP

HTTP RESTful Communication

HTTP

X10 Connector

Legend AR

Decision Execution

Adaptation Rule Actuator

Stabilization AR AR AR AR

CEP Engine Stabilization

Information Source Optional Element

Event Collector HTTP

HTTP User's Preferences

SOAP Connector SOAP Environmental Information

HTTP ZigBee Connector ZigBee Current Temperature

Fig. 2. Description of the D IGI H OME architecture

The D IGI H OME communication middleware defines ubiquitous connectors encapsulating the distribution concerns. Software connectors [5,30] isolate interactions between components—i.e., they support the transfer of control and data. The connectors can also provide non-functional services, such as persistency, messaging, and invocation helping to keep the component functionality focused on the domain specific concerns. In this way, the connectors foster the separation of concerns [30]. In the context of D IGI H OME, software connectors do not impact the event processing and support multiple implementations of the communication mechanism. Figure 2 depicts several examples of connectors for supporting protocols such as ZigBee [37], SOAP, and ACN [6]. For purposes of our scenario, we choose HTTP as the default interaction protocol for the middleware platform and the mobile devices. The choice of HTTP is motivated by its simplicity and the possibility to have mobile devices not only as consumer but also as service providers [21,25,31]. Our RESTful communication middleware supports additional protocols, such as XMPP [27] and Twitter [20] that can be more suitable in other situations. The connectors also support spontaneous interoperability [16] to deal with the volatility of pervasive environments. As already mentioned in section 2, mobile devices, sensors, and actuators can continuously appear or disappear from the landscape. Therefore, the D IGI H OME connectors deal with this volatility by means of standard discovery protocols. By exploiting the extension capabilities of these discovery protocols, we can, for example, improve the context information advertisements with Quality of Context (QoC) [18] attributes for provider selection purposes. In particular, in our scenario we use UPnP [33] to discover mobile devices and actuators. We have selected this protocol as several available electronics devices already support UPnP. Furthermore, although UPnP is an XML-based protocol, its application in WSNs does not impact the

RESTful Integration of Heterogeneous Devices in Pervasive Environments

7

energy consumption because we do not need to process XML descriptions in sensor nodes (this is the responsibility of CEP Engine in D IGI H OME), just provide them. 3.2 Complex Event Processing Complex Event Processing (CEP) is a technology for detecting relationships, in realtime, between series of simple and independent events from different sources, using predefined rules [35]. In our scenario, we consider a lot of heterogeneous devices (sensors, mobile devices, etc.) that generate isolated events, which can be used to obtain valuable information and to make decisions accordingly. We can see some examples of this in the scenario, like activating the sprinklers in case of detecting a fire or like updating the mobile device in order to control the new TV. To manage those events, we need a decision-making engine that can process them and that can create relations to identify special situations, using predefined rules. In order to identify the desired events, the CEP Engine requires to communicate with an Event Collector, which is in charge of dealing with the subscriptions to the event sources. When an adaptation situation is detected, a corresponding action is triggered, which can go from an instruction to an actuator, to the adaptation of the system by adding or removing functionality. These actions are received by the Decision Executor, which has the responsibility of communicating with the different actuators in the environment. In D IGI H OME, for the event processing in the set-top box, we use E SPER [7], a java open source stream event processing engine, to deal with the event management and decision making process. We chose E SPER for our platform because is the most supported open source project for CEP and is very stable, efficient, and fairly easy to use. The following code excerpt shows an example of an E SPER rule: s e l e c t sum ( movement ) from M o v e m e n tSen so r E v e n t . win : t i m e ( 6 0 s e c ) This is a rule related to the scenario presented in section 2.1. Here we can see the use of a time window, which is a moving interval of time. The rule collects all the events from the movement sensor from the last 60 seconds. 3.3 Support for Wireless Sensor Networks In D IGI H OME, there are two scopes for event processing: local event processing, and global event processing. To improve the efficiency of the system, the sensor nodes in our configuration can be considered as sensor networks in order to avoid assigning local decisions to the STB, responsible for global concerns. Specifically, the event generated by a sensor node may be of interest to a node within the sensor network. Therefore, instead of going through the centralized server framework for making decisions, the WSN itself takes the responsibility of processing events in a more efficient way. The architecture of D IGI H OME in sensor nodes supports both local event processing and

8

D. Romero et al.

global event forwarding. The latter delegates the decision of global event processing to the STB. In the former case, the layered framework on the sensor node has the ability to connect directly to other sensor nodes in the environment and to deliver an event to the nodes subscribed to that type of event. Furthermore, the framework provides a lightweight mechanism for event processing in order to keep resource usage at a very low level. The execution layer also benefits from our unified communication protocol to send the configuration and adaptation instructions across the WSN. The event manager layer of our framework enables in-WSN decisions, whenever an event should be processed with other relevant events generated by other sensor nodes. As an example, when a temperature sensor senses a high degree, for deducing on fire detection, it needs to become aware of the smoke density in the room. Thus, the collaboration at network management layer becomes an essential need. 3.4 Platform Optimizations Stabilization Algorithms. When system events are gathered from different sensors, they are forwarded to the CEP Engine, which analyses them before deciding which actions should the system perform. This decision-making task is often a costly procedure for the system and thus requires optimization techniques in order to optimize this task. One of these technics can consist in stabilizing the data flow, for example between the Event Collector and the CEP Engine. The role of the stabilization mechanism is therefore to filter events, preventing useless triggering of the decision-making task. In [22], stabilization mechanisms are defined as algorithms and techniques that operate the system reconfigurations or adaptations only when relevant changes occur. In the smart home scenario (cf. section 2.1) the stabilization mechanism can be useful at several levels of our architecture. Typically, we can aggregate context information (e.g., the user’s preferences) or compute the average of some data (e.g., the temperature). We also have the possibility of introducing stabilization mechanisms between the CEP Engine and the Decision Executor in order to avoid the recurrent triggering of unnecessary adaptations (cf. Figure 2). Concerning the implementation of the stabilization mechanisms in our framework, we use the flexible approach proposed in [23]. This approach suggests a composition model, which consists of two modalities: horizontal composition and vertical composition. Horizontal composition consists in executing several stabilization algorithms concurrently, while the vertical composition refers to the sequential application of two or more algorithms on the same data sample. Web Intermediaries. REST enables Web Intermediaries (WBI) to exploit the requests exchanged by the participants in the communication process. WBI are computational entities that are positioned between interacting entities on a network to tailor, customize, personalize, or enhance data as they flow along the stream [15]. Therefore, we can benefit from this opportunity to improve the performance of D IGI H OME. When the provided context information does not change much in time, the messages containing this information can be marked as cacheable within the communication protocol. This kind of annotation enables WBI caches to quickly analyze and intercept context requests always

RESTful Integration of Heterogeneous Devices in Pervasive Environments

9

returning the same document. A similar optimization applies to security issues and the filtering of context requests. Indeed, by using proxy servers as WBI, we can control the requested context resources and decide whether the incoming (or outgoing) context requests need to be propagated to the web server publishing the context resource. Other kinds of WBI can also be integrated in the system to operate, for example, resource transcoding, enrichment, or encryption.

4 Empirical Validation Although the contribution of this paper lies in the adoption of a versatile architecture style for integrating the diversity of device appliances available in the pervasive environments, we have also made a performance evaluation of a prototype, implementing the proposed platform. This experimentation demonstrates the reasonable overhead imposed by the D IGI H OME platform. 4.1 Implementation Details We built a prototype of the D IGI H OME platform based on the F RACTAL component model and we used the J ULIA1 implementation of the F RACTAL runtime environment [2]. In order to test our system, we measured the communication and discovery overheads using our RESTful approach as well as the event processing cost when using E SPER. To obtain these results, we have implemented the scene 1 of the smart home scenario (described in section 2.1). 4.2 Discovery and Communication Overhead Table 1 reports the average latency for the context dissemination via REST. In this setup, we retrieve the user preferences from multiple providers (Nokia N800 Internet Tables and MacBook Pro) and use multiple formats for the context information (i.e., XML, JSON, and Java Object Serialization). To do that, we have installed a lightweight version of the D IGI H OME platform that includes only the RESTful Communication Middleware as well as the Event Collector. We also measured the delay for discovering the information provided by the sources. For discovery, we selected the UPnP and SLP [11] protocols. In the tests, the platform aggregates the user’s preferences to reduce the number of messages exchanged between the provider and the consumer. The measured time corresponds to exchange of REST messages as well as the marshalling/unmarshalling of the information. The cost of executing others protocols, such as ACN and ZigBee was not considered in this paper. The reader can find more information about the overhead introduced by these protocols in [1]. Furthermore, in this experimentation, the preferences retrieval from mobile devices via XML was not possible due to a limitation of the Java Virtual Machines used on the mobile device (CACAOVM & JamVM). Nevertheless, this is not a problem for our approach since several representations are available for the same preference. 1

J ULIA: http://fractal.ow2.org/julia

10

D. Romero et al. Table 1. Performance of the RESTful connectors Retrieval Latency

Client/ Provider(s) MacBook Pro (Local) MacBook Pro/ MacBook Pro MacBook Pro/ N800

Notification Latency

Discovery Latency

Object (ms)

JSON (ms)

XML (ms)

Object (ms)

JSON (ms)

XML (ms)

SLP (ms)

UPnP (ms)

74.3 146.2 339.6

85.5 158.3 375.75

92.5 165.3

78.6 154.67 359.26

90.46 167.48 397.54

97.77 174.88

44.03 63.62 128.99

59.51 120 136

N/A

N/A

4.3 Event Processing Overhead The time for context dissemination as well as for discovery confirms that D IGI H OME can integrate heterogeneous entities with a reasonable performance overhead. Furthermore, according to the documentation provided by E SPER[7], the efficiency of the engine to process the events is such that it exceeds over 500,000 events per second on a workstation and between 70,000 and 200,000 events per second running on an average laptop. The efficiency of the engine makes that the use of event processing in our system can be done at a low cost and given the modularity of our architecture, the E SPER engine can be installed in the device that provides the highest processing power. In the context of the D IGI H OME platform, we observed that E SPER took 1ms on average to process the adaptation rules.

5 Related Work 5.1 Context Dissemination In literature, it is possible to find two kinds of solutions to deal with context integration: centralized and decentralized. In the centralized category we can find middleware, such as PACE [13] and Context Distribution and Reasoning (ConDoR) [26]. PACE proposes a centralized context management system based on repositories. The contextaware clients can interact with the repositories using protocols, such as Java RMI or HTTP. For its part, ConDoR takes advantage of the object-oriented model and ontologybased models to deal with context distribution and context reasoning, respectively. In ConDoR, the integration of the information using different protocols is not considered as an important issue. The problem with this kind of approach is the introduction of a single point of failure into the architecture, which limits its applicability to ubiquitous computing environments. On the other hand, in decentralized approaches we can find solutions like CORTEX [29] and MUSIC [14,17]. CORTEX defines sentient objects as autonomous entities that have the capacity of retrieving, processing, and sharing context information using HTTP and SOAP. MUSIC middleware is another decentralized solution that proposes a peer-to-peer infrastructure dealing with context mediation. The decentralized approaches face the problem of fault tolerance by distributing the information across several machines. However, as well as some centralized solutions, the lack of flexibility in terms of the communication protocols remains a key limitation for these approaches. In addition to that, peer-to-peer approaches have performance and security problems. In D IGI H OME, we provide a decentralized solution, where the different interacting devices

RESTful Integration of Heterogeneous Devices in Pervasive Environments

11

can process the events retrieved from the environment. Furthermore, in D IGI H OME we provide flexibility in terms the interaction by supporting different kinds of communication protocols and we also allow spontaneous interoperability. 5.2 Complex Event Processing Given the increasing interest to integrate the flow of data into the existing systems, CEP has gained some attention as it can help to provide that integration transforming isolated data into valuable information. In this context we can find some works similar to ours in [3] and [36]. In [3], the authors integrate CEP into their existing project called SAPHE (Smart and Aware Pervasive Healthcare), and also use E SPER as their CEP engine. As the project name shows, the project is applied to healthcare and use sensors to monitor a patient’s activity and vital signs. They use CEP to correlate and analyze the sensor data in order to calculate critical factors of the patient locally in their set-top box, without having to send all the events to an external server. In their approach they lack a way to discover new services and they never mention how, if possible, would they interact with actuators in order to adapt to the context and respond to a specific situation. An Event-Driven Architecture (EDA) that combines the advantages of WSN with CEP is presented in [36]. They use an extension of the RFID EPCglobal architecture which allows the interaction of RFID and WSN events. Once the events are collected, they use CEP to detect specific situations. They use a smart shelf application as their scenario to show how the events from both sources can be combined. Even though both technologies seem to interact in their project, their specification is somehow limited because they do not specify how the information obtained could be used, other than generating a report that will be logged in the EPCIS server. 5.3 Wireless Sensor Networks In [32], the authors describe a WSN-specialized resource discovery protocol, called DRD. In this approach, each node sends a binary XML description to another node that has the role of Cluster Head (CH). The CH is selected among all the nodes based on their remaining energy. Therefore, it is necessary to give all the nodes the capacity of being a CH. Consequently, all nodes need an SQLlite database, libxml2 and a binary XML parser in order to implement the CH functionalities. In D IGI H OME, with our modular architecture, we consider the resource constraint of sensors nodes and provide a lightweight version of the platform that delegates complex processing to more powerful devices. Therefore, not all the nodes have to be CH. Furthermore we benefit from the advertisement capacities of sensor nodes to identify adaptation situations. In CoBIs [4], business applications are able to access functionalities provided by the sensor nodes via web services. The major aim of the CoBIs middleware is to mediate service requests between the application layer and the device layer. The focus lies thereby on deployment and discovery of required services. AGIMONE [12] is a middleware solution supporting the integration of WSNs and IP networks. It focuses on the distribution and coordination of WSN applications across WSN boundaries. AGIMONE integrates the AGILLA [10] and L IMONE [9] middleware

12

D. Romero et al.

platforms. AGIMONE is a general-purpose middleware with a uniform programming model for applications, that integrates multiple WSNs and the IP network. In our approach, we also promote the integration of sensor nodes via software connectors. Moreover, we enable spontaneous communications with some sensor nodes that execute a lightweight version of D IGI H OME. 5.4 Enterprise Service Bus Enterprise Service Bus (ESB) is an architectural style that leverages on the integration of business infrastructures. In particular, platforms conforming to the Java Business Integration (JBI) specification [34] define the concept of Binding Component to deal with the heterogeneity of communication standards by exposing the integrated services as WSDL interfaces. The D IGI H OME platform rather exploits the concept of software connector to expose the information available in the surrounding environment as REST resources. This data orientation leverages on the integration of smart home devices and contributes to the reactivity of the system by introducing a reasonable overhead compared to more traditional RPC-based protocols.

6 Conclusions and Future Work In this paper we have presented D IGI H OME, a platform to deal with the mobility, heterogeneity, and adaptation issues in smart homes. In particular, D IGI H OME enables the integration of context information by defining intermediaries that follow REST principles and identifies adaptation situations using this information. The simplicity and data orientation promoted by REST makes it an attractive alternative solution to deal with heterogeneity in terms of interactions. The software connectors of D IGI H OME also enable spontaneous communications by supporting standard protocols (e.g., UPnP and SLP) and furnishing context provider selection (based on QoC attributes). On the other hand, the modularized architecture of D IGI H OME allows the definition of variants for the platform that can be deployed on resource-constrained devices. Furthermore, the clear separation of concerns in the D IGI H OME architecture encourages the exploitation of WSNs for simple processing and local decision making. The suitability of our platform for context integration was evaluated with different discovery and context representations. Future work includes the integration of our platform with FraSCAti [28], a platform conforming to the SCA specification [24]. By integrating our approach with SCA, we foster the reuse of the different components of D IGI H OME’s architecture and support the use of different technologies for the implementation of its components. Furthermore, we can benefit from FraSCAti’s reconfiguration capabilities and the separation of concerns of SCA to integrate new communication and discovery protocols at runtime. Acknowledgement. This work is partly funded by the EGIDE Aurora and INRIA SeaS research initiatives.

RESTful Integration of Heterogeneous Devices in Pervasive Environments

13

References 1. Zigbee Alliance. ZigBee and Wireless Radio Frequency Coexistence (June 2007), http://www.zigbee.org/imwp/download.asp?ContentID=11745 ´ Coupaye, T., Leclercq, M., Qu´ema, V., Stefani, J.-B.: The F RACTAL compo2. Bruneton, E., nent model and its support in Java. Software: Practice and Experience – Special issue on Experiences with Auto-adaptive and Reconfigurable Systems 36(11-12), 1257–1284 (2006) 3. Churcher, G.E., Foley, J.: Applying and extending sensor web enablement to a telecare sensor network architecture. In: COMSWARE 2009: Proceedings of the Fourth International ICST Conference on COMmunication System softWAre and middlewaRE, pp. 1–6. ACM, New York (2009) 4. COBIS Consortium. Cobis. fp strep project ist 004270 (2009), http://www.cobis-online.de 5. Crnkovic, I.: Building Reliable Component-Based Software Systems. Artech House, Inc., Norwood (2002) 6. Entertainment Services and Technology Association (ESTA). Architecture for Control Networks (ACN), http://www.engarts.eclipse.co.uk/acn/ 7. EsperTech. Esper, http://esper.codehaus.org/ 8. Fielding, R.T.: Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine (2000) 9. Fok, C.-L., Roman, G.-C., Hackmann, G.: A lightweight coordination middleware for mobile computing. In: De Nicola, R., Ferrari, G.-L., Meredith, G. (eds.) COORDINATION 2004. LNCS, vol. 2949, pp. 135–151. Springer, Heidelberg (2006) 10. Fok, L., Roman, G.-C., Lu, C.: Mobile agent middleware for sensor networks: An application case study. In: IPSN 2005: Proceedings of the International Conference on Information Processing in Sensor Networks. IEEE, Los Alamitos (2006) 11. Guttman, E., Perkins, C., Veizades, J., Day, M.: Service Location Protocol, Version 2. RFC 2608 (Proposed Standard) (June 1999), http://tools.ietf.org/html/rfc2608 12. Hackmann, G., Fok, C.-L., Roman, G.-C., Lu, C.: Agimone: Middleware support for seamless integration of sensor and ip networks. In: Gibbons, P.B., Abdelzaher, T., Aspnes, J., Rao, R. (eds.) DCOSS 2006. LNCS, vol. 4026, Springer, Heidelberg (2006) 13. Henricksen, K., Indulska, J., Mcfadden, T.: Middleware for Distributed Context-Aware Systems. In: International Symposium on Distributed Objects and Applications (DOA 2005), pp. 846–863. Springer, Heidelberg (November 2005) 14. Hu, X., Ding, Y., Paspallis, N., Bratskas, P., Papadopoulos, G.A., Barone, P., Mamelli, A.: A Peer-to-Peer based infrastructure for Context Distribution in Mobile and Ubiquitous Environments. In: Proceedings of 3rd International Workshop on Context-Aware Mobile Systems (CAMS 2007), Vilamoura, Algarve, Portugal (November 2007) 15. IBM. Web Intermediaries (WIB), http://www.almaden.ibm.com/cs/wbi/ 16. Kindberg, T., Fox, A.: System software for ubiquitous computing. IEEE Pervasive Computing 1(1), 70–81 (2002) 17. Kirsch-Pinheiro, M., Vanrompay, Y., Victor, K., Berbers, Y., Valla, M., Fr`a, C., Mamelli, A., Barone, P., Hu, X., Devlic, A., Panagiotou, G.: Context Grouping Mechanism for Context Distribution in Ubiquitous Environments. In: Meersman, R., Tari, Z. (eds.) OTM 2008, Part I. LNCS, vol. 5331, pp. 571–588. Springer, Heidelberg (2008) 18. Krause, M., Hochstatter, I.: Challenges in Modelling and Using Quality of Context (QoC). In: Magedanz, T., Karmouch, A., Pierre, S., Venieris, I.S. (eds.) MATA 2005. LNCS, vol. 3744, pp. 324–333. Springer, Heidelberg (2005) 19. Luckham, D.C.: The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley Longman Publishing Co., Inc., Boston (2001)

14

D. Romero et al.

20. Makice, K.: Twitter API: Up and Running Learn How to Build Applications with the Twitter API. O’Reilly Media, Inc, Sebastopol (2009) 21. Nokia. Mobile Web Server (2008), http://wiki.opensource.nokia.com/projects/Mobile_Web_Server 22. Nzekwa, R., Rouvoy, R., Seinturier, L.: Towards a Stable Decision-Making Middleware for Very-Large-Scale Self-Adaptive Systems. In: BENEVOL 2009: The 8th BElgianNEtherlands software eVOLution seminar (2009) 23. Nzekwa, R., Rouvoy, R., Seinturier, L.: A Flexible Context Stabilization Approach for SelfAdaptive Application. In: Proceedings of the 7th IEEE Workshop on Context Modeling and Reasoning (CoMoRea), Mannheim, Germany, March 2010, p. 6 (2010) 24. Open SOA. Service Component Architecture Specifications (November 2007), http://www.osoa.org/display/Main/ Service+Component+Architecture+Home 25. OSGi Alliance. OSGi- The Dynamic Module System for Java, http://www.osgi.org 26. Paganelli, F., Bianchi, G., Giuli, D.: A Context Model for Context-Aware System Design Towards the Ambient Intelligence Vision: Experiences in the eTourism Domain. In: Stephanidis, C., Pieper, M. (eds.) ERCIM Ws UI4ALL 2006. LNCS, vol. 4397, pp. 173– 191. Springer, Heidelberg (2007) 27. Saint-Andre, P.: RFC 3920 - Extensible Messaging and Presence Protocol (XMPP): Core (January 2004), http://tools.ietf.org/html/rfc3920 28. Seinturier, L., Merle, P., Fournier, D., Dolet, N., Schiavoni, V., Stefani, J.-B.: Reconfigurable sca applications with the frascati platform. In: SCC 2009: Proceedings of the 2009 IEEE International Conference on Services Computing, Washington, DC, USA, pp. 268–275. IEEE Computer Society, Los Alamitos (2009) 29. Sorensen, C.-F., Wu, M., Sivaharan, T., Blair, G.S., Okanda, P., Friday, A., Duran-Limon, H.: A context-aware middleware for applications in mobile Ad Hoc environments. In: Proceedings of the 2nd Workshop on Middleware for Pervasive and Ad-hoc Computing (MPAC’04), Toronto, Ontario, Canada, October 2004, pp. 107–110. ACM, New York (2004) 30. Taylor, R.N., Medvidovic, N., Dashofy, I.E.: Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons, Chichester (2009) 31. The Apache Software Foundation. HTTP Server Project, http://httpd.apache.org 32. Tilak, S., Abu-Ghazaleh, N.B., Chiu, K., Fountain, T.: Dynamic Resource Discovery for Wireless Sensor Networks (2005) 33. UPnP Forum. UPnP Device Architecture 1.0. (April 2008), http://www.upnp.org/resources/documents.asp 34. Vinoski, S.: Java Business Integration. IEEE Internet Computing 9(4), 89–91 (2005) 35. Wang, G., Jin, G.: Research and Design of RFID Data Processing Model Based on Complex Event Processing. In: CSSE 2008: Proceedings of the 2008 International Conference on Computer Science and Software Engineering, Washington, DC, USA, pp. 1396–1399. IEEE Computer Society, Los Alamitos (2008) 36. Wang, W., Sung, J., Kim, D.: Complex event processing in epc sensor network middleware for both rfid and wsn. In: ISORC 2008: Proceedings of the 2008 11th IEEE Symposium on Object Oriented Real-Time Distributed Computing, Washington, DC, USA, pp. 165–169. IEEE Computer Society, Los Alamitos (2008) 37. Zigbee Alliance. Zigbee Protocol, http://www.zigbee.org/

Hosting and Using Services with QoS Guarantee in Self-adaptive Service Systems Shanshan Jiang1, Svein Hallsteinsen1, Paolo Barone2, Alessandro Mamelli2, Stephan Mehlhase3, and Ulrich Scholz3 1 SINTEF ICT, Postboks 4760 Sluppen, 7465 Trondheim, Norway [email protected], [email protected] 2 HP Italy, 20063 Cernusco sul Naviglio, Italy [email protected], [email protected] 3 European Media Laboratory GmbH, 69118 Heidelberg, Germany [email protected], [email protected]

Abstract. In service-oriented computing, the vision is a market of services with alternative providers offering the same services with different cost and quality of service (QoS) properties, where applications form and adapt dynamically through dynamic service discovery and binding. To ensure decent and stable QoS to end users and efficient use of resources, it is required that both client applications and service implementations are able to adapt both their internal configuration and their binding to other actors in response to changes in the environment. To this end, service level negotiation and agreements (SLA) are important to ensure coordinated end to end adaptation. In this paper we propose a solution based on the integration of an SLA mechanism into a compositional adaptation planning framework and describe a simple yet powerful implementation targeted for resource constrained mobile devices. As validation we include a case study based on a peer-to-peer distributed mobile application. Keywords: Service level agreement, service level negotiation, self-adaptation, service-oriented architecture, adaptation planning.

1 Introduction In service-oriented computing, the vision is that systems providing functionality to end users form dynamically through service discovery and binding at runtime. This is supported by a service “market”, where alternative service providers offer different service levels (SL) for the same services and where service offers appear and disappear and change dynamically. Service level agreement (SLA) serves to establish terms and conditions, especially SL guarantees, between service providers and service consumers, and thus allows systems to control the SL provided to end users. In our work on self-adaptation in mobile and ubiquitous computing environments, we have advocated a combination of component oriented and service oriented adaptation. Service consumers and providers adapt dynamically both their internal component configuration and their service bindings in order to optimize the utility to the end F. Eliassen and R. Kapitza (Eds.): DAIS 2010, LNCS 6115, pp. 15–28, 2010. © IFIP International Federation for Information Processing 2010

16

S. Jiang et al.

users as well as ensuring efficient utilization of resources. The coordination of the adaptation of part systems is facilitated by service level negotiation and agreements. In the context of the MUSIC project (http://www.ist-music.eu) we have created a development framework based on this approach, including both modeling and middleware support. The principles of this approach to self-adaptation have already been presented and discussed in several publications [1,2,3,4]. The contribution of this paper is to explain the adopted service level negotiation mechanism and how it is integrated with the component level adaptation apparatus to achieve the coordinated adaptation we are seeking. To validate our design we have used the MUSIC framework to implement a peer-to-peer media sharing application, allowing users to dynamically form communities and create and comment a common media collection. By analyzing the design and behavior of this application we can demonstrate that our solution works as intended. The paper is organized as follows: Section 2 presents the MUSIC approach to selfadaptation. Section 3 describes the design and implementation of the MUSIC Negotiation Framework as well as its integration into the adaptation framework. Section 4 presents the InstantSocial case study and demonstrates how SLAs are considered in the adaptation reasoning both at the provider side and the consumer side. Section 5 discusses related work before concluding the paper.

2 Adaptation Framework The MUSIC approach is an externalized approach to the implementation of selfadaptation where the adaptation logic is delegated to generic middleware working on the basis of models of the software and its context represented at runtime [1,2]. These models understand systems as collections of collaborating components, modeled as compositions with typed roles and connectors. A connector models collaboration between two components, where one provides a service to the other. A role models a component providing services to or requiring services from other components. A component is either atomic, or a composition itself, thus allowing hierarchic decomposition. A composition may delegate the provisioning or consumption of a service to the level above it by leaving the appropriate end of the connector unbound. To build system instances according to the above model, we need to find components which conform to the roles in the composition specification, instantiate these components, and connect the component instances according to the composition specification. Typically there will be several component variants matching a role, differing in terms of a set of varying properties. This is modeled by property predictor functions associated with components. Property predictor functions are expressions over the context, the resources and the properties of collaborating components, and in the case of composite components, also the properties of the constituting components. Varying properties typically model variation in extra functional properties (i.e., QoS properties) and resource needs, but may also represent variation in functionality. Thus, by selecting components with different varying properties we can build systems with different properties from the same system model and we can modify the properties of a running system by replacing one or more components.

Hosting and Using Services with QoS Guarantee in Self-adaptive Service Systems

17

A system has a utility function, which expresses how well suited a given configuration is in a given situation based on the predicted values for the varying properties. The utility function is an expression over the predicted properties of the system and the properties of the current context. The adaptation middleware aims to adapt the running systems so as to maximize the overall utility. In Service-Oriented Architecture (SOA) based computing environments, systems are typically distributed with part systems1 deployed on a potentially large number of computers owned and administered by different organizations. Part systems represent end user applications or service providing components, or both. The goal of the adaptation planning is to select appropriate variants that can be used in a composition to optimize the overall utility. However, optimizing utility over the entire set of computers involved is likely to be intractable both from a technical and an administrative point of view. Therefore we limit the scope of system models and the optimization of the utility to part systems, and rely on dynamic service discovery and binding to connect part systems, and on service level negotiation between them to ensure coordinated adaptation. The adaptation planning process considers components installed on its computer to populate the roles of the part system model, service providers located by dynamic service discovery to bind dependencies on external service providers, and takes into account service level agreements with consumers of provided services. Serving external clients consumes resources, and therefore whether or not to publish a service outside the part system or to accept new clients, is also decided at runtime by the adaptation middleware. System models are represented at runtime as plans. A plan contains the details and the QoS properties (in the form of property predictors) of a certain realization. The dependency on an external service is represented as a special kind of plan called service plan, with an associated set of plan variants representing the available service providers. MUSIC provides generic middleware to support running and adapting applications created using the above models. Obviously, components and services will have to be designed to be dynamically replaceable, and handle the transfer of state between variants where necessary. The MUSIC middleware is based on a pluggable architecture and implemented based on an OSGi framework [2], where it is convenient to extend the architecture by plug-ins. The initial architecture proposed has been modified and extended during the implementation process for incorporating the SLA mechanism. Figure 1 gives a simplified view of the MUSIC middleware. Plans and plan variants are stored in the Plan Repository in the Kernel. The Adaptation Manager handles the adaptation planning process for a part system, which is triggered basically by context changes detected by the Context Manager, and by plan changes in the plan repository. The Adaptation Controller coordinates the adaptation process. The Adaptation Reasoner supports different planning heuristics using metadata provided by the plans. The Reasoner builds valid application configurations by solving their dependencies and ranks the configurations by evaluating their utility based on the computation of the predicted properties. The Configuration Executor handles the reconfiguration process 1

In MUSIC a part system may actually span several nodes. However, since this is transparent to the SLA mechanism, we do not explain it further in this paper.

18

S. Jiang et al.

using the plans selected by the Reasoner. The Communication provides basic support for SOA in distributed environment. The Discovery Service publishes and discovers services based on service descriptions using different discovery protocols. Whenever a service is discovered which matches a service dependency of a part system running in a node, a corresponding service plan variant is created in the plan repository. The plan variants are removed from the plan repository whenever the provider disappears or retires the offer. The plan variants will also be updated when the QoS properties provided by the services are changed. The Remoting Service is responsible for the binding and unbinding of services. At the service provider side, it exports services hosted by the provider (i.e. enable them to accept service requests), and at the service consumer side, it provides bindings (i.e. remote access) to the discovered remote services.

Fig. 1. Simplified architecture of MUSIC middleware

In the following we will discuss the design and implementation of the MUSIC Negotiation Framework (MNF, depicted in grey), and its integration with the adaptation framework. The MNF is responsible for service level negotiation and violation handling (cf. Sect. 3.3). It interacts with the Adaptation Manager and the Communication to realize the adaptation process integrated with SLA mechanism.

3 Integrating SLA with the Adaptation Framework Current state-of-the-art work for SLA specification is WS-Agreement [5], a proposed recommendation of the Open Grid Forum. It specifies the general structures and terms for SLA definition and a simple single round negotiation protocol. We have selected WS-Agreement as a starting point for our work. However, WS-Agreement is technically too heavy for resource constrained mobile devices. Therefore, we adopt a custom, lightweight implementation. Below we present the overall approach for the integration work and then describe the main extensions in detail. 3.1 Requirements for the SLA Mechanism In order to achieve coordinated adaptation of part systems, a service provider needs to know about its consumers (e.g. who and how many) and what they need (e.g. service

Hosting and Using Services with QoS Guarantee in Self-adaptive Service Systems

19

level) and incorporate such information into the adaptation process. We have identified a set of requirements for the SLA mechanism in our context: (i) To allow providers to take into account the needs of the current consumers when adapting. The provider should consider the QoS requirements from the consumers (typically as required service levels) and the number of consumers when allocating resources. Such information should be reflected in the utility function so that it can be integrated into the utility-based adaptation reasoning. (ii) To allow providers to notify consumers if they change the service level as a result of adaptation. (iii) To allow the propagation of service level changes throughout the network of providers and consumers. (iv) To give providers the flexibility of withdrawing a service offer, while maintaining the provisioning of the service to current consumers in order to avoid being overloaded. For the server side of the mechanism we have focused on service exchange between peer nodes, typical of collaboration oriented mobile applications, and not specialized service provider nodes. This is also reflected in the case used for validation. However the client side of our solution may also exploit services offered by specialized service provider nodes not using the MUSIC technology. 3.2 Overall Description of the Approach Below we give an overview of how services, service level negotiation, agreement and monitoring are integrated into the adaptation process in MUSIC: 1. Service publication and discovery: In MUSIC, services are advertised with the service levels predicted by the current variant of the service providing application. The advertisement mechanism delivers service descriptions to all the MUSIC nodes which are interested. Such service description contains information needed to properly specify and locate the service, together with a set of properties describing the current service level offered. The service level advertised consists of the predicted property values associated to the component providing the service. When a service is discovered at the consumer side, the advertised service level is used to create a service plan variant in the plan repository, which can be later evaluated by the Adaptation Reasoner when computing the utility of the available compositions. There can be multiple service plan variants for a service plan corresponding to alternative providers that a MUSIC node in the SLA-Consumer role (cf. Sect. 3.3) can select from. 2. Service selection and negotiation: The Adaptation Reasoner selects the most appropriate service offerings among a set of different service providers and different service levels available, each considered as a variant, by deciding if the variant with its service level can contribute to the composition configuration that gives the highest overall utility. If a service variant is selected by the reasoning process, a negotiation process is initiated towards the provider with an offer created based on

20

S. Jiang et al.

the selected service level. If negotiation is successful, an SLA will be created and the service will be provisioned with the guaranteed service level. If negotiation fails2, the Reasoner selects another variant and re-negotiates. The negotiation process thus provides the adaptation planning with a mechanism to bind to the appropriate service provider with guaranteed service levels. 3. Service monitoring. In a ubiquitous service environment, the provided service levels may be dynamically changed. We use a simplified mechanism (cf. Sect. 3.3) to check the conformance of SLAs according to the predicted property values defined in the property predictors leveraging the MUSIC planning mechanism. 4. Service violation and re-negotiation. A service violation discovered by service monitoring will trigger the re-adaptation process of the Adaptation Manager. The violated SLA will be terminated and the Reasoner may select another available service variant and initiate the negotiation process. 3.3 The MUSIC Negotiation Framework The MUSIC middleware can, at the same time, play two separate roles with respect to the negotiation process: It can provide negotiable services to remote nodes (providerside negotiation) and use negotiable services provided remotely (consumer-side negotiation). Provider-side negotiation consists of evaluating an offer coming from a remote node and, possibly, creating an SLA between the parties; consumer-side negotiation consists of creating and submitting a request for reaching an SLA towards a service provider. All the SLAs reached as a result of the negotiation process must be properly monitored to verify their compliance with the agreement terms over the time. The service level negotiation and monitoring capabilities in MUSIC are provided by a custom, lightweight negotiation model, called MUSIC Negotiation Framework (MNF) and implemented by the SLA Manager. The internal components of the SLA Manager and their relationship are depicted in Fig. 2 and briefly described in the following. For a detailed description of interfaces and behavior, readers may refer to [6]. The SLARepresentation allows the creation of a MUSIC-specific, internal representation of an SLA describing the terms of the agreement, the actors involved and their roles, the associated QoS, the SLA state, etc. Once created, an SLARepresentation is stored into the SLARepository, a component which collects all the SLAs created by the MUSIC middleware (both when acting as an SLA-Provider and an SLAConsumer). In addition, it allows other MUSIC middleware components to register as listeners for repository change events happening in the repository. The SLAMonitor constantly monitors the QoS of an offered service and checks it against an SLA reached with a service consumer. In MUSIC, we adopt a simplified mechanism called provider-side SLA monitoring: The provider checks SLA conformance at the end of the adaptation planning process, which is based on the predicted QoS values calculated from the property predictors defined in the service plan variants;

2

Due to the time gap between the adaptation reasoning and the negotiation, negotiation may fail in cases like the provider disappears, changes its service level, or can not accept more consumers. However, as the reasoning time is short, the probability of such failure is small.

Hosting and Using Services with QoS Guarantee in Self-adaptive Service Systems

21

cmp Components

SLA Consumer Plugin SLA Monitor

SLA Negotiator

SLA Representation

Consumer-side Negotiation

Provider-side Negotiation SLA Repository

SLA Provider Plugin

SLA Manager

Fig. 2. Structure of the SLA Manager

the consumer relies on the provider for SLA monitoring by periodically checking the SLA state with the provider3. The SLANegotiator performs all the steps enabling consumer-side and providerside negotiation, described at the beginning of this section. The negotiation logic is supported by corresponding SLA plug-ins that implement specific service level negotiation protocols. The current MNF has available plug-ins for a MUSIC internal negotiation protocol, which is a customized version of WS-Agreement with single round negotiation. In order to integrate MNF into the MUSIC framework (cf. Fig. 1), two additional actions are performed at the end of the planning process: •

•

For all SLA-enabled service plan variants selected by the Adaptation Manager, an SLA negotiation process is triggered for each service. If the negotiation for a service fails, the corresponding service plan variant will be invalidated and a re-adaptation process is triggered. The Adaptation Manager invokes the SLA Manager to check SLA states for all active SLAs provided by the MUSIC node as a mechanism for providerside SLA monitoring.

3.4 Discussion The current MNF implementation and its integration into the MUSIC adaptation framework fulfills the first three requirements listed in Sect. 3.1. For (i): The number of consumers is the same as the number of SLAs and can be easily obtained from the MNF. The QoS requirements of the consumer are reflected in the service offer submitted by the consumer during service level negotiation. Both information can be 3

A common approach for service monitoring from the literature is to use context sensors to gather data about service level metrics and parameters of the provided service at the consumer side. We adopt the simplified mechanism for provider-side SLA monitoring so as to eliminate the needs for consumer-side monitoring. However, context sensors can be readily integrated into the MUSIC framework due to the extensible plug-in architecture. See Sect. 0 for explanation of the rationale for this approach.

22

S. Jiang et al.

included in the utility function for adaptation reasoning. For (ii): The provider updates the SLA states when there is a change in the offered service level and the consumer can detect such change by periodically checking the SLA states with the provider. For (iii): The propagation of service level changes is realized by leveraging the service discovery and the SLA monitoring mechanisms. Requirement (iv) is currently unsupported, but we have designed a mechanism based on special flags that can realize it. The integration implementation has leveraged MUSIC specific features in SLA monitoring to simplify the processing and improve the performance. Firstly, since the MUSIC adaptation framework uses predicted property values for reasoning (i.e., evaluated property values based on the property predictors at the given context), we use the predicted property values when performing provider-side monitoring. In addition, the consumer relies on the provider for SLA monitoring. This mechanism eliminates the need for additional context sensors to collect real-time QoS data both at the provider side and at the consumer side. Secondly, as any cause for service property changes will trigger an adaptation planning process, it is sufficient to check the property values at the end of the planning process. These mechanisms allow for a practical, lightweight implementation for mobile devices. Although our implementation is MUSIC specific, it is quite flexible due to the plug-in architecture. Our current MNF implementation provides plug-ins for the MUSIC internal negotiation protocol. However, by delegating the negotiation logic to plug-ins, alternative negotiation protocols and technologies can easily be incorporated into the MUSIC framework. For example, the MUSIC internal protocol assumes that a service provider will publish only the current service level. To work with nonMUSIC nodes using a negotiation protocol [7] that provides alternative service levels in the service description, plug-ins for that negotiation protocol can be implemented on MUSIC nodes. Such plug-ins must create a service plan variant for each alternative service level, such that they are considered as different variants in the adaptation reasoning, and negotiate the selected service level with the provider. Because our simplified monitoring mechanism relies on the provider for SLA monitoring, it implicitly requires the consumer to trust the provider. If such assumption does not hold in a dynamic environment, the consumer can use context sensor plug-ins to provide consumer-side SLA monitoring as adopted by other SLA frameworks.

4 InstantSocial Case Study InstantSocial (IS) [3] is a media sharing platform for transient user groups that allows members to tag, to comment, and to search for text and images. IS has three design goals: (i) Maintaining a peer-to-peer network yielding high connectivity, (ii) providing access to a large number of media despite varying availability of devices, and (iii) balancing the load upon multiple resource-limited devices. IS accomplishes these goals by building on the previously described SLA capabilities of the MUSIC middleware. The following design extends and refines the IS version described in [3]. 4.1 Design and Utility Function of InstantSocial Figure 3 shows the design of the InstantSocial application: Variant configurations, components, their properties and associated property predictors. Table 1 lists the

Hosting and Using Services with QoS Guarantee in Self-adaptive Service Systems

23

property types and their descriptions. InstantSocial is divided into two parts: The user interface (UI) and the content repository (CR). The content repository instance holds the media items and their associated data, e.g., comments and tags. This component provides and consumes two different services: The context access service (ca) and the routing service (rs). Full

Mini UI

UI

CR >ca >rs

>ca

CR

<memory c a p a c i t y=” 4000 ” /> < l e v e l number=” 3 ”> <machine hostname=” p a s t e l −2. b217 . home” i p=” dhcp” mac=” 00 : 2 1 : 7 0 : 2 5 : 5 5 : b 1 ”> ...

Example of a partial description of a physical grid architecture

As different actors handle the logical view differently, there are two languages to describe it. The first one allows an administrator to link users with a grid by specifying VOs. The second one is used by grid users to define their vjobs to be submitted to the grid.

48

R. Pottier, M. L´eger, and J.-M. Menaud



Example of a vjob description

4

A Domain Specific Language for Grid Management

Once our grid model has been defined, administrators and users manage resources by navigating and selecting elements in grid physical and logical architectures and by dynamically reconfiguring these architectures. This section describes VMScript, a domain specific language for grid management, i.e. introspection and intercession in grid elements. This language is inspired by previous work on a reconfiguration language in component-based architectures called FScript [6]. Actually, our language is divided into two parts for respectively introspection and reconfiguration. The introspection language, named VMPath, is used to express queries in grid architectures. The reconfiguration language, VMScript, allows the execution of dynamic reconfiguration operations on grids and is a super set of VMPath. 4.1

Selection and Navigation in Grid Architectures

A grid configuration (or architecture) is defined as a labeled directed multigraph. To query these architectures, the VMPath language is used as a side-effect free declarative language. It is restricted to the navigation in grid architectures, the selection of grid elements by their location or their properties. Therefore, the execution of a VMPath expression cannot lead to modifications in grids. VMPath syntax. The language has a very concise but powerful syntax based on XPath 1.0 [17], the W3C standard query language for XML documents. Several arguments are in favor of this choice: – XPath does not depend on the specific syntax of XML documents, it can be used on abstract graph models such as our grid model. Actually XPath only defines concepts of nodes, properties and relations between nodes. – The syntax is open and flexible. Although XPath specifies a fixed set of nodes and relations (XPath axes) to query XML documents, it is possible to define new types of nodes and relations. Our grid model does not use XPath base XML axes (child, attribute, etc.) but defines its own navigation axes.

A Reconfiguration Language for Virtualized Grid Infrastructures

49

– The syntax is concise and readable, an XPath allows to express one-line queries. Moreover, XPath defines a node-set data type which allows powerful set queries with set operations. Despite all these advantages, VMPath does not rely on existing XPath implementations because these implementations are too tied to XML representations. The generic syntax of a VMPath expression consists of a sequence of steps separated by slashes (cf. Figure 3). A step is composed of an axis specifier which indicates the arc to follow in the graph for navigation, and a set of optional predicates to filter the selected nodes. There is no intrinsic notion of hierarchy in navigation and so a navigation axis does not necessarily represent a hierarchical relation between elements. The beginning of the expression, $grid, refers to the initial node set used in the query. This node set is stored in a VMPath variable and denotes in this case a grid element. The navigation axis used in the expression is the site axis which basically selects all site nodes belonging to the grid. This set of sites is then filtered thanks to a predicate to select only sites which are named ‘P aris’, i.e. all sites which are localized in Paris. The ‘@’ symbol is used to query the value of the name property. Initial node set

Optional filtering predicates

$grid/site[@location == "Paris"]/...

Axis specifier

Additional steps

Fig. 3. Syntax of query expressions

VMPath is a dynamically typed language (type checking is performed at runtime). The four primitive data types defined are the same as in XPath 1.0: node-set, string, number, and boolean. As there is no notion of attribute nodes, a special type multi-set has been added to deal with multi-sets of primitive types. The VMPath language supports the classic arithmetic, boolean and comparison operators and also set operators (union, intersection and difference). Functions in VMPath are side-effect free procedures. A library of predefined functions is provided with the language. These functions are essentially: – property accessors to get values of node properties (e.g., ‘name()’ to get the name of a node). The ‘@’ notation before a property name is strictly equivalent to the accessor function on the property (e.g., ‘@name’). It should be noted that these functions can be applied to a set of elements. For instance ‘name($set)’ would return a multiset of strings corresponding to all the names of the elements contained in the set ‘$set’. – functions for string manipulation (e.g., ‘concat()’ for string concatenation, ‘match()’ to test the matching of a string and a regular expression) – aggregation functions on element collections: ‘size()’ (returns the cardinality of a set), ‘sum()’ (returns the sum of a number set), etc.

50

R. Pottier, M. L´eger, and J.-M. Menaud

VMPath examples. VMPath can be used to express a wide range of queries on grid architectures. Some examples are presented afterwards. A selection of all racks in a grid is performed thanks to the following expression: $grid / s i t e / c l u s t e r / rack

A shortcut navigation axis is usable when there is no ambiguous path in the graph to reach the wanted nodes. For instance, the previous expression using a shortcut axis could be expressed as follows: $ g r i d // r a c k

Grid elements can be selected by the value of properties. For example, we may want to find the rack which contains a machine with a specific IP address in a cluster: $ c l u s t e r // machine [ @ip == ’ 1 9 2 . 1 6 8 . 1 1 0 . 3 6 ’ ] / / r a c k

4.2

Dynamic Reconfiguration of Grids

The VMPath query language is integrated into another DSL focusing on the dynamic reconfiguration of grids, VMScript. VMPath expressions are used to select the grid elements to reconfigure. VMScript is an imperative language providing procedures and control structures so as to program reconfiguration scripts of grids. Procedures. VMScript makes the distinction between two kinds of procedures: functions and actions. Functions are side-effect free procedures only for grid introspection, whereas actions are intercession procedures to actually modify grid configurations. A primitive action in our model is a primitive graph transformation in a grid representation such as listed below: – Addition or removal of a node. For instance, to add or remove a cluster node in the graph, we could use respectively the following procedures: new−c l u s t e r ( ) ; d e l e t e −c l u s t e r ( $ c l u s t e r ) ;

– Addition or removal of a relation between nodes. For instance, these two procedures respectively add and remove a rack relation between a cluster and a rack, i.e. add and remove a rack in a cluster: add−r a c k ( $ c l u s t e r , $ r a c k ) ; remove−r a c k ( $ c l u s t e r , $ r a c k ) ;

– Modification of the value of a node property. To change the name of a grid, the following setter is applied: s e t −name ( $ g r i d , ” mygrid ” ) ;

All these primitive actions are automatically generated from the description of our grid model so that possible modifications in the model are transparently taken into account. Native procedures like primitive actions are implemented in Java, the implementation language of the VMScript interpreter. However it is possible to define procedures directly in the VMScript language. These userdefined procedures can be loaded at any time in the interpreter. A VMScript procedure is specified by means of the f unction or action keywords:

A Reconfiguration Language for Virtualized Grid Infrastructures function isEmpty ( s e t ) { return s i z e ( $ s e t ) ==0; }

action m i g r a t e −v j o b ( v j o b , f o r $vm : $ v j o b /vm { m i g r a t e ( $vm , $ d e s t ) ; } }

51

dest ) {

The first procedure is a function which returns true if a set is empty, false otherwise. The second procedure is an action which takes a virtual job and a machine in argument. It consolidates the vjob on the same destination machine by migrating all of its VMs. These two procedures are part of a standard library. This library contains utility procedures which are loaded when the interpreter is instantiated. Control structures. VMScript supports classic control structures in addition to the sequencing of instructions. New variables can be created by assigning them an initial value. Variables are mutable and their scope is defined by the block where they are declared. In the following example, ‘grid’ is a global variable since it is defined outside any block. It is initialized with a grid node built from the configuration file mygrid.xml describing a grid architecture. A declared variable is then referenced by means of the ‘$’ symbol. g r i d = adlnew−g r i d ( ‘ ‘ mygrid . xml” ) ; echo ( $grid ) ;

The conditional execution if-then-else uses the standard C syntax. The following example tests if the memory capacity of a machine is above a threshold. If the test evaluates to true, it adds a VM to the machine, otherwise it prints a message to the standard output. i f ( $machine@mem cap >= 2 0 0 0 ) { add ( $vm , $machine ) ; } else { e c h o ( ‘ ‘ Not enough memory . ” ) ; }

Iteration is restricted to finite sets with a for loop. This limitation prevents from programming infinite loops and non-terminating scripts. The execution semantics of an iteration is to sequentially iterate on every element in the set. For example, the following code iterates on every machine in the grid which do not host any VM. f o r $m : $ g r i d // machine [ s i z e ( . / vm) ==0] { shutdown ($m) ; }

Some native actions are defined to take either a single value or a set in argument. In the latter case, the primitive action is executed in parallel on each element of the set. For instance, the previous example could be executed in parallel with the same action but without explicit iteration: shutdown ( $ g r i d // machine [ s i z e ( . / vm) ==0]) ;

An explicit return statement allows the stopping of a program execution and returns to the caller with possibly sending a value.

52

R. Pottier, M. L´eger, and J.-M. Menaud

function c p u c o n s a v e r a g e ( m a c h i n e s ) { return a v e r a g e ( m a c h i n e s@ c p u c o n s ) ; }

Execution model. Primitive actions defined in VMScript are directly mapped on operations in the grid model. For instance, a migrate-vm action on a VM node corresponds to a migrate Java method on a VM object from our model API. As previously mentioned and thanks to the causal connection between the grid and its representation, the execution of an operation in the model comes to execute operations on real machines and VMs through SSH and calls to native APIs (e.g., Xen API for Xen VMs). VMscript code is executed in an interpreter programmed in Java which can be embedded in applications. Furthermore, an interactive console is provided so as to interactively execute queries on a grid and reconfiguration scripts.

5

Evaluation

We show first in this section the expressiveness of the VMScript language by comparing it to another general purpose scripting language linked to a VM API. We then present several use cases we experimented with VMScript for grid management. 5.1

Comparison with a General Purpose Language

In this section, we compare an action written in VMScript with the same action written in the scripting language Bash. The purpose of the example is to shut down machines in order to perform some maintenance tasks on hardware (for example, changing a hard disk). We want to select machines from their CPU capacity and their kernel version. If these machines do not host VMs, we shut them down. For this experimentation, all machines are stored in a same rack. These machines boot a Linux operating system with different kernel versions and different CPU and memory capacities. Each machine runs a Xen (v3.2.1) hypervisor. From a UNIX shell, we get the cpu capacity from reading the /proc/cpuinfo file and just keep the value of the metric cpu MHz. We obtain the kernel version by the command uname -r. To check that there is no VM hosted by the machine, the Xen API is invoked for listing all hosted virtual machines on a node. 1 2 3 4 5 6 7 8 9

f o r machine in $ ∗ ; do k e r n e l=$ ( s s h root@$machine uname −r ) cpu=$ ( s s h root@$machine c a t / p r o c / c p u i n f o | g r e p ’ cpu MHz ’ | head −n 1 | s e d s /[ˆ0 −9.]// g ) i f [ $cpu = ” 2000 ” −a $ k e r n e l = ” 2.6.26 −1 − xen−amd64” ] ; then i f [ −z ” $ ( s s h root@$machine xm l i | s e d ’ 1 d ’ | s e d ’ 1 d ’ ) ” ] ; then s s h root@$machine h a l t fi fi done

Action written in a bash script

A Reconfiguration Language for Virtualized Grid Infrastructures

53

From the VMScript console, we set a variable “rack” with the rack to analyze. So we select all machines of this rack with the wished “cpu cap”. For the kernel version, the usage of an optional property “os dist” is required. We query the grid representation with the function “size()” to check that no VM is running on a machine. 1

shutdown ( $ r a c k / machine [ @cpu cap = 2 0 0 0 ] [ @ o s d i s t = = ’ 2.6.26 −1 − xen−amd64 ’ ] [ s i z e (vm) = = 0 ] ;

Action written in VMScript

We can see the benefits from using the VMScript DSL because of: – its concision: the VMScript action takes a single line versus 9 lines of codes in Bash, – its homogeneity and genericity: its not necessary to invoke a specific hypervisor API in the code, – its guarantees: the shutdown action in VMScript has a precondition to check that there is actually no VM hosted on a machine before shutting it down. 5.2

Some Common Use Cases in Grid Management

Some samples of VMScript code are given afterwards to exemplify the use of the language for grid management. The action keep-min-nodes is used to ensure that a given number of machines is started so that they can easily host new VMs. action keep−min−n o d e s ( g r i d , nb ) { f o r s : $ g r i d // s i t e { no vm = $ s // machine [ s i z e (vm) = = 0 ] ; on = s i z e ( $no vm ) i f ( $on > $nb ) { shutdown ( s u b s e t ( $no vm , $on − $nb ) ) } e l s e i f ( $on < $nb ) { power−on ( s u b s e t ( $ s // machine [ @ s t a t e = = ’ o f f ’ ] , $nb − $on ) ) ; } } }

The following action gets servers running a Xen hypervisor then puts a new Xen configuration file and restarts the Xen daemon. action h y p e r v i s o r s −c o n f i g ( g r i d , h y p e r v i s o r , f i l e P a t h ) { xen = $ g r i d // machine [ @ h y p e r v i s o r = = ’ xen ’ && @ o s f a m i l y = = ’ Linux ’ ] ; put− f i l e ( $xen , f i l e P a t h ) ; e x e c u t e−command( $xen , ’ / e t c / i n i t . d/ xend r e s t a r t ’ ) ; }

In the next action, we add a new server in the physical architecture and migrate virtual machines of the most overhead servers to free a piece of memory.

54

R. Pottier, M. L´eger, and J.-M. Menaud

action new−machine ( g r i d , h y p e r v i s o r , f i l e P a t h ) { add−e l e m e n t s ( ’ new−s e r v e r . xml ’ ) ; new−s e r v e r = $ g r i d // machine [ @name = = ’ p a s t e l −90 ’ ] ; s e r v e r 1 = $ g r i d // machine [ @mem free = = min ( g r i d // machine@mem free ) ] ; m i g r a t e ( $ s e r v e r 1 /vm [ @mem need = = max ( . / machine/vm@mem need) ] , $new−s e r v e r ) ; }

6

Conclusion

Managing a virtualized grid infrastructure is a hard task and some tools are required to help administrators with this. In the same way, although a grid can aggregate a lot of heterogeneous physical and software resources, it must offer a simple interface to its users, i.e. the application (job) providers. Regarding these preoccupations, we proposed a domain specific language approach for grid management. More precisely, several DSLs are used for grid description, query and reconfiguration. All these languages rely on the definition of a particular model of a grid. A graph based representation of grids is maintained at runtime and conforms to this model. A first description language allows administrators to specify a grid physical architectures as a hierarchical assembly of physical elements like machines and clusters. A second language is used to group grid users by sets in virtual organizations. The last description language is dedicated to the specification of jobs (called virtual jobs) by users. A job, which has to be executed on the grid, is described essentially as a set of VMs. A user can specify the resources (CPU, memory, etc.) required to run the job. The VMScript language focuses on querying grid architectures and on grid reconfiguration. A subset of the language is declarative and is used to query the grid through its runtime representation. This query is done by navigating in the graph and selecting elements with some optional predicates. The imperative part adds side effects to the language with control structures and procedures called actions. These ones actually modify the grid architecture, for instance by placing and moving VMs on machines. Our grid model essentially focuses on the representation of machines as physical resources. It does not deal at the moment with network topology and properties such as latency and bandwidth. However, as this model is extensible without actually modifying the language syntax, these new preoccupations could be introduced for future work provided that a suitable monitoring system gives that information.

References 1. Albrecht, J., Oppenheimer, D., Vahdat, A., Patterson, D.A.: Design and implementation tradeoffs for wide-area resource discovery. In: Proceedings of 14th IEEE Symposium on High Performance, Research Triangle Park, pp. 113–124. IEEE Computer Society, Los Alamitos (2005) 2. Globus Alliance. Extended resource specification language (xrsl). Technical report, Globus Alliance (2009)

A Reconfiguration Language for Virtualized Grid Infrastructures

55

3. Anjomshoaa, A.: Job submission description language (jsdl) specification, version 1.0. Technical report, Global Grid Forum (2005) 4. Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer, R., Pratt, I., Warfield, A.: Xen and the art of virtualization. In: SOSP 2003: Proceedings of the nineteenth ACM symposium on Operating systems principles, pp. 164–177. ACM, New York (2003) 5. Clark, C., Fraser, K., Hand, S., Hansen, J.G., Jul, E., Limpach, C., Pratt, I., Warfield, A.: Live migration of virtual machines. In: NSDI 2005: Proceedings of the 2nd conference on Symposium on Networked Systems Design & Implementation, pp. 273–286. USENIX Association, Berkeley (2005) 6. David, P.-C., Ledoux, T., L´eger, M., Coupaye, T.: Fpath & fscript: Language support for navigation and reliable reconfiguration fractal architectures. Annals of Telecommunications - Special issue on Software Components - The Fractal Initiative 64, 45–63 (2009) 7. Figueiredo, R.J., Dinda, P.A., Fortes, J.A.B.: A case for grid computing on virtual machines. In: ICDCS 2003: Proceedings of the 23rd International Conference on Distributed Computing Systems, p. 550. IEEE Computer Society, Washington (2003) 8. Goldberg, R.P.: Architecture of virtual machines. In: Proceedings of the workshop on virtual computer systems, pp. 74–112. ACM, New York (1973) 9. Primet, P.V.-B., Koslovski, G.P., Char˜ ao, A.S.: Vxdl: Virtual resources and interconnection networks description language. In: Networks for Grid Applications (2009) 10. Hermenier, F., Lorca, X., Menaud, J.-M., Muller, G., Lawall, J.: Entropy: a consolidation manager for clusters. In: VEE 2009: Proceedings of the 2009 ACM SIGPLAN/SIGOPS international conference on Virtual execution environments, pp. 41–50. ACM, New York (2009) 11. Kivity, A., Kamay, Y., Laor, D., Lublin, U., Liguori, A.: Kvm: the linux virtual machine monitor. In: Proceedings of the Linux Symposium, June 2007, vol. 1, pp. 225–230 (2007) 12. Massie, M.L., Chun, B.N., Culler, D.E.: The Ganglia Distributed Monitoring System: Design, Implementation, and Experience. Parallel Computing 30(7), 817–840 (2004) 13. McNett, M., Gupta, D., Vahdat, A., Voelker, G.M.: Usher: an extensible framework for managing custers of virtual machines. In: LISA 2007: Proceedings of the 21st conference on Large Installation System Administration Conference, pp. 1–15. USENIX Association, Berkeley (2007) 14. Raman, R., Livny, M., Solomon, M.: Matchmaking: Distributed resource management for high throughput computing. In: Proceedings of the Seventh IEEE International Symposium on High Performance Distributed Computing, pp. 28–31 (1998) 15. Rosenblum, M., Garfinkel, T.: Virtual machine monitors: Current technology and future trends. Computer 38(5), 39–47 (2005) 16. Sotomayor, B., Keahey, K., Foster, I.: Combining batch execution and leasing using virtual machines. In: HPDC 2008: Proceedings of the 17th international symposium on High performance distributed computing, pp. 87–96. ACM, New York (2008) 17. World Wide Web Consortium. XML path language (XPath) version 1.0. W3C Recommendation (November 1999), http://www.w3.org/TR/xpath/

Distributed Object-Oriented Programming with RFID Technology Andoni Lombide Carreton , Kevin Pinte, and Wolfgang De Meuter Software Languages Lab, Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussels, Belgium {alombide,kpinte,wdmeuter}@vub.ac.be

Abstract. Our everyday environments will soon be pervaded with RFID tags integrated in physical objects. These RFID tags can store a digital representation of the physical object and transmit it wirelessly to pervasive, context-aware applications running on mobile devices. However, communicating with RFID tags is prone to many failures inherent to the technology. This hinders the development of such applications as traditional programming models require the programmer to deal with the RFID hardware characteristics manually. In this paper, we propose extending the ambient-oriented programming paradigm to program RFID applications, by considering RFID tags as intermittently connected mutable proxy objects hosted on mobile distributed computing devices. Keywords: RFID, pervasive computing, ambient-oriented programming, mobile RFID-enabled applications.

1

Introduction

RFID is generally considered as a key technology in developing pervasive, contextaware applications [1], [2]. RFID tags are becoming so cheap that it will soon be possible to tag one’s entire environment, thereby wirelessly dispersing information to nearby context-aware applications. An RFID system typically consists of one or more RFID readers and a set of tags. The RFID reader is used to communicate with the tags, for example to inventory the tags currently in range or to write data on a specific tag. RFID tags can either be passive or active. Active tags contain an integrated power source (e.g. a battery) which allows them to operate over longer ranges and to have more reliable connections. Some even have limited processing power. Passive tags are more commonly used because they are very inexpensive. Passive tags use the incoming radio frequency signal to power their integrated circuit and reflect a response signal. Most RFID tags possess non-volatile memory on which they can store a limited amount of data. The technologies on which we focus are cheap, writable passive tags and RFID readers integrated into mobile devices (such as smartphones). 

Funded by a doctoral scholarship of the “Institute for the Promotion of Innovation through Science and Technology in Flanders” (IWT Vlaanderen).

F. Eliassen and R. Kapitza (Eds.): DAIS 2010, LNCS 6115, pp. 56–69, 2010. c IFIP International Federation for Information Processing 2010 

Distributed Object-Oriented Programming with RFID Technology

57

This technology gives rise to distributed applications running on mobile devices that both disperse application-specific data to and process contextual data from tagged physical objects in their environment. They spontaneously interact with physical objects without assuming any additional infrastructure. We will refer to such applications as mobile RFID-enabled applications (see section 3.1 for an example). These applications use RFID technology in a radically different way than RFID systems deployed today, which only use RFID tags as digital barcodes and almost never exploit the writable memory on these tags. Furthermore, today’s systems assume infrastructure in the form of a centralized backend database that associates the digital barcode with additional information. In mobile RFID-enabled applications, communication with RFID tags is prone to many failures. Tags close to each other can cause interference and can move out of the range of the reader while communicating with it. These failures may be permanent, but it may be that at a later moment in time the same operation succeeds because of minimal changes in the physical environment. For example, a tag moves back in range or suddenly suffers less from interference. As a consequence, dealing with these failures and interacting with the low-level abstraction layers offered by RFID vendors from within a general purpose programming language results in complex and brittle code. In this paper, we propose a natural extension to distributed object-oriented programming by aligning physical objects tagged with writable RFID tags as true mutable software objects. We will model these objects as proxy objects acting as stand-ins for physical objects. For this model to be applicable to mobile RFIDenabled applications, it must adhere to the following requirements: R1: Addressing physical objects. RFID communication is based on broadcasting a signal. However, to be able to associate a software object with one particular physical object, it is necessary to address a single designated physical object. R2: Storing application-specific data on RFID tags. Since mobile RFIDenabled applications do not rely on a backend database, the data on the RFID tags should be self-contained and stored on the writable memory of the tags [3]. R3: Reactivity to appearing and disappearing objects. It is necessary to observe the connection, reconnection and disconnection of RFID tags to keep the proxy objects synchronized with their physical counterparts. Differentiating between connection and reconnection is important to preserve the identity of the proxy object. Furthermore, it should be possible to react upon these events from within the application. R4: Asynchronous communication. To hide latency and keep applications responsive, communication with proxy objects representing physical objects should happen asynchronously. Blocking communication will freeze the application as soon as one physical object is unreachable. R5: Fault-tolerant communication. Treating communication failures as the rule instead of the exception allows applications to deal with temporary unavailability of the physical objects and makes them resilient to failures. For example, read/write operations frequently fail due hardware phenomena.

58

A.L. Carreton, K. Pinte, and W. De Meuter

The remainder of this paper is organized as follows. Section 2 discusses related work. Section 3 starts by introducing a mobile RFID-enabled application scenario. Thereafter we use the scenario as a running example to present the language constructs that make up our model. Section 4 discusses the limitations of our system. Finally, section 5 concludes this paper.

2

Related Work and Motivation

This section discusses the current state of the art concerning RFID applications and supporting software, and how current approaches do not meet the requirements listed in the previous section. RFID Middleware. Typical application domains for RFID technology are asset management, product tracking and supply chain management. In these domains RFID technology is usually deployed using RFID middleware, such as Accada [4] and Aspire RFID [5]. RFID middleware applies filtering, formatting or logic to tag data captured by a reader such that the data can be processed by a software application. RFID middleware uses a setup where several RFID readers are embedded in the environment, controlled by a single application agent. These systems rely on a backend database which stores the information that can be indexed using the identifier stored on the tags. They use this infrastructure to associate applicationspecific information with the tags, but do not allow storing this information on the tags directly (requirement R2). Therefore, current RFID middleware is not suited to develop mobile RFID-enabled applications. RFID in Pervasive Computing. In [6], mobile robots carrying an RFID reader guide visually impaired users by reading RFID tags that are associated with a certain location. In [7] users are equipped with mobile readers and RFID tags are exploited to infer information about contextual activity in an environment based on the objects they are using or the sequence of tags read by the reader. Rememberer [8] provides visitors of a museum with an RFID tag. This tag is used as the user’s memory of the visit and stores detailed information about selected exhibitions. However, none of the above systems provide a generic software framework to develop mobile RFID-enabled applications, but instead use ad hoc implementations directly on top of the hardware. In [9] RFID tags are used to store application-specific data. The RFID tags form a distributed tuple space that is dynamically constructed by all tuples stored on the tags that are in reading range. Mobile applications can interact with the physical environment (represented by tuples spaces) by means of tuple space operations. The system not only allows reading data from RFID tags, but at any time, data in the form of tuples can be added to and removed from the tuple space. However, there is no way to control on which specific tag the inserted tuples will be stored. RFID tags cannot represent physical objects as there is no way address one specific RFID tag as dictated by requirement R1. Hence, the programmer must

Distributed Object-Oriented Programming with RFID Technology

59

constantly convert application data types (e.g. objects) to tuples and vice-versa. Therefore, this approach suffers from the object-relational impedance mismatch [10] and does not integrate automatically with object-oriented programming.

3

Distributed Object-Oriented Programming with RFID-Tagged Objects

In this section, we discuss our RFID programming model. It is conceived as a set of language constructs that satisfy all requirements listed in section 1. We do this by means of an example mobile RFID-enabled application that we use as a case study to motivate our implementation. First, we introduce the general idea of the application. 3.1

A Mobile RFID-Enabled Application Scenario

The scenario consists of a library of books that are all tagged with writable passive RFID tags. The user of the application carries a mobile computing device that is equipped with an RFID reader. On this device, there is software running that allows the user to see the list of books that are nearby (i.e. in the reading range of the RFID device) sorted on different properties of the books (e.g. author, title, ...). This list is updated with the books that enter and leave range as the user moves about in the library. Additionally, the user can select a book from the list of nearby books, on which a dialog box opens. In this dialog box, the user can write a small review about the book. This review is stored on the tagged book itself. Other users can then select that same book from their list of nearby books and browse the reviews on the book, or add their review. 3.2

Ambient-Oriented Programming with RFID Tags

In the mobile RFID-enabled application introduced in the previous section, mobile devices hosting different instances of the application move throughout an environment of tagged books. These books dynamically enter and leave the communication range of the mobile devices and interact spontaneously. These properties are very similar to the the ones exhibited by distributed applications in mobile ad hoc networks [11]. Similar to mobile devices in mobile ad hoc networks RFID tags and readers should interact spontaneously when their ranges overlap. Ambient-oriented programming [12] is a paradigm that integrates the network failures inherent to mobile ad hoc networks into the heart of its programming model. To this end, ambient-oriented programming extends traditional objectoriented programming in a number of ways. First, when objects are transferred over a network connection it is not desirable having to send the class definition along with the object. This leads to consistency problems and performance issues [13], [14]. Hence, a first characteristic of ambient-oriented programming is the usage of a classless object model. A second characteristic is the use of non-blocking communication primitives. With blocking communication a program will wait for

60

A.L. Carreton, K. Pinte, and W. De Meuter

the reply to a remote computation causing the the application to block whenever a communication partner is unavailable [15]. The last characteristic is dynamic device discovery to deal with a constant changing network topology without the need for URLs or other explicit network addressing. Since we are modeling physical objects in a pervasive computing environment as self-contained software objects, ambient-oriented programming provides a fitting framework to cope with the problems listed in the introduction. A promising model epitomizing this paradigm is a concurrency and distribution model based on communicating event loops [16]. In this model, event loops form the unit of distribution and concurrency. Every event loop has a message queue and a single thread of control that perpetually serves messages from the queue. An event loop can host multiple objects that can be published in the network. Other event loops can discover these published objects, obtaining a remote reference to the object. Client objects communicate with a remote object by sending messages over the remote reference, the messages are then placed in the mail queue of the event loop hosting the remote object. The event loop’s thread handles these messages in sequence ensuring the hosted objects are protected against race conditions. A remote reference operates asynchronously, the client object will not wait for the message to be delivered, but immediately continues with other computations. Within the same event loop, local object references are accessed using regular, synchronous message sending. Figure 1 illustrates the communicating event loops model. When mobile devices move out of each others range, the event loops that are hosted on the different devices are disconnected from each other. However, upon such a disconnection, all remote references become disconnected and buffer incoming messages, as illustrated by figure 2. When the communication is reestablished, the remote references are automatically restored and all buffered messages are automatically flushed to the message queue of the destination event loop. AmbientTalk is an ambient-oriented programming language that uses the communicating event loop model as its model for concurrency and distribution [17]. It is conceived as a scripting language that eases the composition of distributed Java components in mobile ad hoc networks. We implemented our RFID system in AmbientTalk and in the next sections we introduce the concrete language abstractions that allow us to program with RFID-tagged objects as

Event loop

Event loop

Message from A to B

Thread Message queue

B

A Object

synchronous

Local references

Remote reference remote reference

asynchronous

Fig. 1. Overview of the communicating event loops model

Distributed Object-Oriented Programming with RFID Technology

Event loop

61

Event loop

A

Buffered message from A to B

B X

Buffered message from X to Y

Y

disconnected remote reference

Fig. 2. Messages to disconnected objects are buffered until reconnection

mutable software objects. Each of the next sections corresponds to a requirement formulated in section 1 and is numerated accordingly. R1

RFID-Tagged Objects as Proxy Objects

As discussed earlier, we model RFID-tagged objects as proxy objects. An example of a book proxy object is given below. It contains slots for the ISBN, title and reviews and provides two mutator methods to update the book’s title and add reviews: 1 2 3 4 5 6 7 8 9 10 11 12 13 14

deftype Book; def aBook := object: { def ISBN := 123; def title := "My Book"; def reviews := Vector.new(); def setTitle(newTitle)@Mutator { title := newTitle; }; def addReview(review)@Mutator { reviews.add(review); }; } taggedAs: Book;

The hardware limitations of RFID tags render it impossible to deploy a full fledged virtual machine hosting objects on the tags themselves. We thus store a serialized data representation of a proxy object on its corresponding tag. Because we use a classless object model, objects are self-contained: there is no class that defines their behavior. Upon deserialization the object’s behavior (its methods) is preserved and used to reconstruct the proxy object. Since we cannot rely on classes to categorize objects, we use type tags. These are “mini-ontologies” that are attached to an object to identify its “type”. In the above example, we define a type Book on line 1 and attach that type to the aBook object in line 14. In section R3 we use the type tag to discover objects of a certain kind. Of course, the data stored on the tags has to be synchronized with the state of these proxy objects. Methods that change the state of the book objects are

62

A.L. Carreton, K. Pinte, and W. De Meuter

Event loop

a

RFID event loop RFID hardware abstraction layer

Thread Message queue

X

RFID reader

Message from X to A

Object

b RFID tags

A Y

Remote references

Buffered message from Y to B

B

connected remote reference (tag in range) disconnected remote reference (tag not in range)

Fig. 3. Overview of the RFID event loop

annotated by the programmer with the Mutator annotation1 . These annotations are used by the implementation to detect when objects change and have to be written to the corresponding tag. For example, calling the addReview mutator method on a book object first updates the reviews field by adding the new review. Subsequently, the system serializes the modified book object and stores it on the correct RFID tag. The proxy objects are managed by what we will henceforth denote as the RFID event loop. It controls an RFID reader to detect appearing and disappearing tags (a and b) and it associates proxy objects with them (A and B). These proxy objects can then be used by other event loops to interact with the tags as if they were mutable software objects. They do this by obtaining remote references to the proxy objects. Remote references (X and Y) reflect the state of the corresponding RFID tags (a and b). When a tag moves out of range of the reader the remote reference is signaled of this disconnection; conversely, when a tag moves back in range the remote reference is signaled of the reconnection. Figure 3 shows a general overview of the RFID system. R2

Storing Objects on RFID Tags

When the RFID event loop detects a blank RFID tag, the tag is represented by a generic proxy object which responds to only one message: initialize. The code below shows how a blank tag is initialized as a book object: when: tag