Dynamic Self-Aggregation of Pervasive Communication Services

The Service Ecosystem: Dynamic Self-Aggregation of Pervasive Communication Services Raffaele Quitadamo Dipartimento di Ingegneria dell’Informazione Università di Modena e Reggio Emilia [email protected]

Franco Zambonelli Dipartimento di Scienze e Metodi dell’Ingegneria Università di Modena e Reggio Emilia [email protected]

Abstract The continuous growth in ubiquitous computing and network connectivity in our everyday environments calls for a deep rethinking of traditional communication service architectures. In pervasive scenarios, manually configuring communication service/protocols is becoming mostly unthinkable, due to the high heterogeneity of devices and services, and to the decentralized and embedded nature of the involved entities. The next step is towards the “componentization” of communication services, i.e. services implemented and exposed by software components, rather than static protocol/service layers. Stack layering is likewise expected to be replaced by the dynamic and flexible aggregation of such components. Canonical software engineering models for component composition and syntactic service interfaces can hardly tackle the openness and dynamicity of such envisioned pervasive communication services. Therefore, this paper proposes an innovative ecology-inspired composition model for pervasive services. The key idea is to exploit semantics as an overlay for service aggregation rather than a mere additional description of a static service.

1. Introduction The continuous growth in ubiquitous and mobile network connectivity, together with the increasing number of networked computational devices populating our everyday environments, call for a deep rethinking of traditional communication service architectures. In general terms, a communication service is a functionality that is made available within a network to access and exploit its resources. IP datagram routing, DNS, cryptographic tools, web services, socket-based point-to-point communication, and P2P data delivery services, can all be considered communication services. Such services have always been considered as implemented by static software/hardware modules, linked together and constantly maintained by a dedicated network administrator. This approach is becoming too “primitive” in a world where new devices

Giacomo Cabri Dipartimento di Ingegneria dell’Informazione Università di Modena e Reggio Emilia [email protected]

and services/protocols are released at an overwhelming speed compared to the standardization times. Moreover, as computers are getting embedded in our everyday objects [5] and are almost always wireless-enabled, the resulting network becomes highly dynamic in terms of topology and usage patterns (e.g. peers/devices continuously joining and leaving the community). Finally, the highly decentralized and embedded nature of the involved components, makes it hard (whether not impossible) to enforce some forms of direct control over their configuration and their activities. A natural evolution of the rigid stack-based approach is that of a dynamic communication infrastructure, made up of software components providing services by their own or by on-demand aggregating with other components to meet communication requests. The outcome is much more than a static service stack, whereas such aggregations are endowed with autonomicity [1] (i.e. selfmanagement), self-reconfiguration and situationawareness capabilities. Many algorithms and techniques are being actively researched to provide such features, e.g. in the autonomic computing [8] and in the swarm intelligence [3] fields. Nonetheless, from a software engineering standpoint, this innovative vision introduces issues that are challenging traditional service-oriented models [7]. In the majority of open and pervasive scenarios (i.e. the ones we are tackling in this paper), communication services are often designed by independent/unknown providers and are subject to rapid and uncontrolled evolution. Standardization efforts (through common interfaces) are mostly unfeasible and enabling interactions among components becomes increasingly harder. Starting from the previous problem statements, we describe in the remainder of this paper a new service model, specifically designed to accomplish the needs of pervasive communication applications. Explicitly departing from most current autonomic component models [12], we synthesize an “ecology-inspired”, highly decentralized model for pervasive communication services and their on-demand aggregations. The discussion throughout the paper is

supported by a simple scenario of pervasive and adaptive communication services (Section 2). The proposed model, called the Pervasive Service Ecosystem, is the main contribution of this paper and its detailed description is covered by Section 3. The key software engineering innovation of the Pervasive Service Ecosystem is its approach to semantics as the “full enabler” for service aggregation rather than a mere additional description of static services: exploiting knowledge as the “reaction substrate” for ondemand service aggregations, we achieve adaptive (i.e. self-managing), situation-aware and self-reconfiguring compound communication services. Our model is eventually compared in Section 4 with some other proposed “service composition” approaches, which are an active research area of modern software engineering. Section 5 closes the paper, summing up the outlined ideas and stressing our aim of providing a full-fledged prototypal implementation of them.

available sensor network can be exploited to implement a “localization service”: mote sensors can, for instance, form ad-hoc networks and coordinate among themselves to track people and/or objects position into the building (passing this information to a central station).

2. Autonomic Communication Services

Figure 1. The Urgent Message Delivery scenario This dynamic and heterogeneous scenario makes it quite unfeasible to have a single rigid protocol stack to make all devices communicate. Firstly, because it requires discovering and composing available services on the fly and depending on the environmental context. Secondly, the maintenance effort would be overwhelming, considering that new technologies come out everyday and new (often proprietary) protocols are released for these devices. Our approach to service provision in such contexts considers services as “units of communication functionality” (called ACEs, Autonomic Communication Elements), which can be dynamically aggregated on demand to realize new complex services. Describing the internals of ACEs is outside the scope of this paper (the interested reader can refer to [13]). Our focus is mostly on modelling the software infrastructure to enable their composition. On demand service aggregation opens up new possibilities for improving the user experience with pervasive communication services, notably when such aggregations meet some challenging requirements that we deem essential: 1. autonomicity (or self-adaptation): in our scenario, it stands for the capability of the service infrastructure to transparently handle failures or unforeseen contingencies (e.g. the person goes out of the wireless range), taking corrective actions or finding other strategies (e.g. using the cellular network if available); 2. self-reconfiguration: dynamic adaptation to changes may often entail reconfiguring an ensemble (i.e. aggregation) of communication services, changing its structure, replacing failed services with others and so forth. The “self” attribute means performing reconfiguration without human intervention and as transparently as possible to the user.

The following subsection sketches a simple pervasive communications scenario, where several network services are involved; its aim is to make evident the software engineering problem we will tackle in the rest of the paper: i.e. the need to fulfill a communication request, aggregating available pervasive services in an autonomic, self-reconfiguring and situation-aware fashion.

2.1

The urgent message delivery service

In the pervasive computing scenario of Figure 1, a number of communication devices are placed in every room of a building: these are mainly wireless-enabled devices, such as WiFi access points, laptops or sensors (e.g. motes). Users moving throughout the building are equipped with some personal device, such as a PDA or a GSM phone. A LAN is also present in every room to connect hosts among them and to the Internet. Each communication device is able to provide different kinds of services, abiding by different protocols and exposing different interfaces. Let’s now consider a user application that needs to deliver text messages (e.g. urgent communications) to persons within an organization. There can be several ways of achieving this: one can think of sending, for instance, a message to the GSM phone (using the GSM channel and the Short Message Service); but, if the user is not available through its cellular phone, the message can be delivered as an email and the user can read it through her PDA or laptop. In the worst case (no GSM phone, the person is not logged in to any device), a robust communications infrastructure should still try to fulfill the request: a possible solution consists in searching for another communication device (e.g. the fax machine in Figure 1), which has been installed into the room where the person is at the moment. The

3.

situation-awareness: in order to properly decide the right adaptation strategy, a communication service must be necessarily aware of what’s happening around. The technologies needed to capture contextual data are becoming increasingly available (e.g., sensorial data, location systems, user profiling tools) and these data must be exposed to services in the environment. In our example, localization data, coming from wireless sensors, and knowledge about the layout of the building (rooms, floors, etc.) are examples of contextual information that are of paramount importance for the self-adaptation requirement.

3. Aggregating Pervasive Services The issue of “pervasive service aggregation” through ACEs boils down to essentially two important software engineering problems: 1. properly finding and organizing communication services into the environment (i.e. hereafter the discovery problem) 2. letting them interact when aggregated into more complex services (i.e. the interoperability problem)

3.1

Background

Current service-oriented models [7] solve the discovery problem, but they do not provide enough interoperability support. A “service requestor” (i.e. a front-end application or another service) searches the “service registry” for a suitable service to be used, formats its request messages and receives response messages, according to the service contract. Nonetheless, service orientation suffers from a heavy limitation: it constrains the service client to have the knowledge of the service interface (operations, prototypes, return values and so forth) hardwired into its source code. This implies that independently evolving services can hardly be supported (e.g. if the service changes its interface, old clients may not be able to use it anymore). To this purpose, it has been claimed that semantics will help solving this overwhelming problem. In our opinion, semantics is the key but current serviceoriented approaches to it seem to have a very narrow scope: they consider semantics just as a mere additional information to a service. Even current promising efforts to enrich service descriptions (e.g. WSDL contracts) with semantic information [17], can only partially alleviate the problem of interoperability among third party (i.e. independently evolving) services. In order to interact, the two interacting parties must a priori share a common set of data types and concepts, and clients should have the knowledge of the service interface “hardwired” into their code. Otherwise, they must be capable of dynamically invoking the semantically discovered service, either by user interaction or through some kind of “reflection mechanism” (useful for

inspecting and possibly invoking the service, without any prior knowledge of its particular interface). Nonetheless, user intervention should be considered the last possible choice, while reflection produces heavyweight components, capable of outstanding intelligence and reasoning capabilities, and thus an awkward programming model for service developers.

3.2

Knowledge as the reaction substrate

The fundamental idea of the Pervasive Service Ecosystem is that knowledge (i.e. semantics) should be an integral part of the environment and should actively drive interactions and aggregations among services, rather than being a simple description of registered services. Its role in the infrastructure should be that of a semantic overlay, built upon the physical world and mediating interactions among (independently evolving) ACE components. In such a vision, every pieces of information exchanged among ACEs or coming from the physical world are understood as “instances of some semantic concept”. As we will practically prove, explicitly “externalizing” knowledge out of ACEs and using it to carry out interactions, helps solving elegantly both the discovery and the interoperability problems. In more details, we propose to have, as in a chemical reaction, an a priori “semantic substrate” that we call natural knowledge, which comes from the underlying physical (e.g. localization data coming from sensors) and social (e.g. affiliations, working groups) environment. Nevertheless, this knowledge must be complemented by another kind of knowledge, coming from the components joining the infrastructure at any time. We define the latter an artificial knowledge, because it is injected into the system from the outside and “speaks about” concepts that were not previously known. Artificial knowledge comprises the semantic representation of the services provided by an ACE and the concepts it knows about the world (see Figure 2 for the example of the “Log-in manager” ACE, exposing a piece of artificial knowledge about the “getPersonLogin()” operation).

Figure 2. The Log-in manager and the concept ontology These two knowledge typologies are properly merged and maintained into a distributed structure, called knowledge network. Such innovative concept is further developed in [2] and thus it will be only shortly explained here (for space reasons). We can briefly say that a knowledge network is an ontology-based structured collection of knowledge elements, built in order to facilitate ACEs in acquiring high degrees of

situation-awareness and in interoperating to form selfmanaging service aggregations.

3.3

Triggering Aggregation with Enzymes

Provided that a knowledge network is laid down into the infrastructure, in this subsection we follow the on demand service aggregation process for the pervasive scenario of subsection 2.1. Let’s suppose that some communication services (implemented through ACEs) have been deployed into the Pervasive Service Ecosystem. Such services are depicted in Figure 3, as connected to the knowledge network ontology of the infrastructure (at this level of the design, it seems premature to dive into how such a structure can be implemented, though this is part of our ongoing research work on the model).

Figure 3. Services and their integration in the environmental knowledge In our pervasive example, user A of Figure 1 wants to send an urgent message to user B, which can be anywhere at that moment. Its software application, e.g. running on its PDA, then deposits its service request message, which certainly comprises the (semantic) name of the requested service (i.e. “deliver”) and some arguments (knowledge elements) to be used by the service (referring to the “Person” and “Message” ontology concepts). This phase is schematically shown in Figure 4, with the service request message implemented in a selfdescribing XML-based format. For the user application to interact with the Pervasive Service Ecosystem and to obtain the provision of the requested service, a common sense hypothesis is necessary: “The client (i.e. user application or another ACE) and the knowledge network must share one concept at least”. This means that, if the request message of Figure 4 refers to concepts that the service infrastructure is able to handle, a self-aggregation reaction can occur; otherwise, if the system does not hold the minimal necessary knowledge to deal with the above concepts, no reaction will occur and the service request will fail. It seems clear here that handling the service request message above calls for some reasoning-enabled entity to process the referenced semantic concepts and try suitable adaptation strategies. Such entities are called enzyme ACEs and they belong to the knowledge

network overlay. A non-negligible issue here is about what degree of reasoning capability those enzyme ACEs should have. Should they indeed be general-purpose intelligent agents? The idea of “too much rational” software components would be overly complex and heavyweight for a pervasive infrastructure like ours. We chose instead to have little very specific enzyme ACEs deployed throughout the infrastructure, with a reasoning capability limited to a few concepts of the ontology. The latter design choice is motivated by our selforganizing and best-effort approach to service composition, which fits well the constraints of mobile devices (e.g. sensors or PDAs). Rather than intelligent big enzymes, we prefer lightweight aggregators that establish simple interactions with their peers and the environment, in an effort to converge to a certain equilibrium state (i.e. the actual service aggregation). Let’s consider, for instance, enzyme 1 of Figure 5, which is the one expected to catch the request message injected by the user application.

Figure 4. Injecting a GN to trigger service aggregation Enzyme 1 has been deployed in the infrastructure with a limited piece of intrinsic knowledge (those ontology concepts included within the blue shape of Figure 5). Restricting the number of its owned concepts, we have a little ACE that is able to perform simple inference, for instance, on its “message”, “person” and “deliver to” well-known concepts (e.g. it should recognize as much as possible concept synonyms to reduce the semantic mismatch). The outcome of such inference can be initially that it can try to reach that “person” by sending (“through” concept in Figure 5) the “message” to a “device” where the “person” can be “logged in” at the moment. Now, enzyme 1 carries out a semantic discovery of available services installed in the knowledge network, with the aim of finding a service capable of telling him which device the person is logged in. Let’s suppose this service is already present in the system and it has been previously called “Log-in manager” (see Figure 2): enzyme 1 then aggregates that ACE and invokes its exposed service to retrieve the device where the person is currently logged-in. It is just as enzyme 1 becomes client with respect to another ACE (please note that how interoperability with discovered ACEs is achieved constitutes the subject of

3.4

Knowledge Synthesis for Interoperability

The previous subsection has followed one possible aggregation path that enzymes can try, in order to handle a service request in an autonomic and situationaware manner. Once a service request message is deposited into the Ecosystem, it is up to enzymes to process its self-describing content and to decide what other services to aggregate. The latter services must be invoked passing them the right knowledge elements, which may differ from the one contained into the request message. Let’s consider once again the “Log-in manager” service (of Figure 2) that receives a “Person” element as input and produces the “Device” element, telling the device where that person is currently logged in. Between the user application and the “Log-in Manager” ACE there can be two kinds of mismatches limiting their interoperability: ¾ syntactic mismatches, e.g. including incompatible/unknown data types and different field ordering; ¾ semantic mismatches, which occur because the two ACEs may have different views of the same concept (e.g. the “Log-in manager” ACE can think of a person as a couple of “personalId” and “affiliation”) or use different terms to refer to it.

reads

s ce du pro

t

tp u ou

input

t

is a

at ted

is a

loca

Figure 5. Enzyme ACEs and their limited knowledge set Let’s suppose enzyme 1 cannot reach the person through any loggable device. Being adaptive, the enzyme will try a best-effort delivery, following a more physical strategy. Referring back to Figure 5, enzyme 1 chooses to try reaching the user through another device that can be available in the environment and that it is aware of: the “fax machine”. However, enzyme 1 is not capable of aggregating the necessary services to perform the “send message to the fax machine” operation (it should be capable of reasoning on other concepts that it does not own). It then injects another service request message into the environment and another enzyme will try to handle it, thanks to its piece of owned knowledge. Enzyme 3 (whose knowledge is depicted in Figure 6) knows that both a Person and a Device can be localized (because they are considered “Locatable Entities”) by means of some tracking system installed into the organization. Let’s suppose, for instance, that RFID [20] tags are spread throughout the environment and every locatable entity has one of them attached (or embedded). This system allows to precisely know where at the moment the entity is located. In our case, enzyme 3 looks for (and discovers) a “Locator” component that is capable of finding an entity (using the tracking system and the RFID tags) and it returns the found Location. Then, it uses the same service to find out a fax machine installed (“located at”) at the Location where the Person is currently staying. Enzyme 3 finds and aggregates thus a “Fax Sender” ACE providing an operation to send a message to a fax machine and, considering that it accepts only postscript files, it selects also a “Postscript Converter”, in charge of converting a byte array message to a postscript. To sum up, in this situation/context, enzyme 3

produces the newly aggregated component “Device Communicator”, joining together the “Locator” ACE, the “Fax Sender” and the “Postscript Converter” ACEs.

in pu t

subsection 3.4). It is now the current situation that determines the adaptation strategy enzyme 1 will adopt and, for the sake of simplicity, we consider just two possible situations: (i) the “Log-in manager” tells that “person” is actually “logged in” to some “device”; (ii) the “person” is not reachable through any loggable device (e.g. PC, PDA, laptop, GSM phone, etc.). Due to space limitations, we will analyze only one of the two situations, i.e. the second, mainly because it is of more interest for pervasive computing.

Figure 6. Enzyme 3 and its owned knowledge Reconciling the first mismatches would mean forcing independent developers to abide by standardized syntax rules and programming using a shared set of data types. This is obviously impossible in an open and dynamic scenario like the one we are coping with. Semantic reconciliation is instead feasible in most cases and, in our Ecosystem model, this task has been appointed to the knowledge network and to enzymes in particular. As already shown in the previous subsection, enzymes are designed to reason about the semantics of services, because we think knowledge is the only possible aggregating factor of a group of independently evolving services.

Therefore, in order to enable maximum interoperability among (independently evolving) services living in the Ecosystem, we chose to firmly separate the syntactic facet of a service description from the semantic one. Everything about a service description that cannot be considered semantic (e.g. field ordering of data types, method signatures, calling conventions, etc.) is confined within the ACE, while the semantic meaning of parameters, operation names and return values is exported by every ACE and integrated in the knowledge network. On the one hand, such knowledge drives the discovery and aggregation of available services, as shown in the previous subsection. On the other hand, it is exploited by enzyme ACEs to actually invoke those services, to make them interoperate exchanging knowledge elements instead of “syntactically constrained” object instances. Such knowledge elements are pieces of information whose meaning is described only by the ontology concepts they refer to. They can be implemented, for instance, as XML elements, to achieve maximum platformindependence.

2.

If the receiving ACE does not recognize the meaning of the passed parameter, it rejects it and returns its internal representation of the referenced concept. Then, enzyme 1 decides to instantiate (if available) a suitable synthesis enzyme to produce a knowledge element suitable for that ACE. 3. If the synthesis process is successful, the synthesis enzyme is aggregated into enzyme 1 and the synthesized knowledge element passed to the ACE. In Figure 7, the above protocol has been applied to the “Log-in manager” component interoperating with enzyme 1 (to get the Device where the Person is logged in). The key advantage of this approach is that two different ACEs are allowed to model their entities/data types as they want (e.g. the “Person” concept). Enzyme ACEs will try to bridge the semantic gap, manipulating the exchanged knowledge elements and adapting them (as much as possible) as required by the involved ACEs. It is up to the programmer of enzymes to enrich them with increasing levels of intelligence, so as to handle as much semantic mismatches as possible.

4. Related Work

Figure 7. The synthesis of knowledge elements Now, exchanging arguments, service names and outputs as knowledge elements, two or more independent services can seamlessly interact by means of the knowledge infrastructure underneath and its enzymes. Such enzymes, after having discovered and aggregated suitable ACEs, have to establish an interaction channel and invoke their exposed operations. Such interaction process can be explained using the presented example of Figure 4: the user application is able to transparently interact with the “Log-in manager service” of Figure 2, thanks to their shared “person” concept and to the intermediation of enzyme 1. In order to be invoked through the knowledge infrastructure, ACEs are designed with the capability of handling a simple contractual protocol: 1. when enzyme 1 wants to invoke an operation of an ACE, it firstly tries a direct invocation, passing the current knowledge element for the input parameters to that ACE and waiting for an answer.

The idea of dynamically composing a protocol stack for communication purposes has given impulse to a growing number of research activities in the last few years ([11], [15], [19]). All these projects are still tightly bound to the traditional stack-based view of communication. Nonetheless, future scenarios are demanding a deeper integration of pure communication services (e.g. IP routing, DNS resolution, etc.) and other kinds of pervasive heterogeneous services. Therefore, services are better seen as provided by adaptive and dynamically aggregating software components, rather than protocols layers to be stacked. As already stressed throughout this paper, one big issue here is how to enable full and transparent interoperability among different deployed services. One possible approach has been that of Recombinant Computing [4]: i.e. having components implement a minimal set of domainindependent interfaces, to allow the transfer of mobile code and data among components. Mobile code extends the behaviour of entities (e.g. a specific “protocol handler” is installed into the service client before communication begins) and shifts part of the agreement between components from development time (as in traditional component models) to run-time. Handling the semantics of components is delegated to the user. Though certainly fascinating from the conceptual point of view, mobile code has still severe security problems. Other researchers have followed a more software engineering approach to component composition. They (e.g. [9] and [18]) propose a solution based on the reification of connections between components by means of “connectors”. Connectors handle the implementation gap between the service expected by the client and the one expected by the

provider. However, a well-known criticism to connectors is that “they simply move the problem from one place to another”. The programmer has to implement as much connector types as possible to enable maximum interoperability. Moreover, they always involve the user in the selection of discovered services and this produces an awkward and uncomfortable application. Semantics for service composition is increasingly being explored in the field of Web Services [10]. Fuji et Suda [6] implemented a semantics-based dynamic service composition architecture that, given a user request in natural language, discovers the necessary components, creates a workflow with them and executes the workflow. Their use of semantics to describe service operations and data types has strongly influenced our model. Nonetheless, one important step forward was the choice of a distributed and adaptive service aggregation strategy (through enzymes) instead of a centralized and static workflow composer. Our choice has been motivated by the overwhelming dynamicity and unpredictability of pervasive communication scenarios [16]. A similar effort has been proposed also in [14].

5. Conclusion Throughout this paper, the Pervasive Service Ecosystem has been introduced as a possible component composition model for future pervasive communication services. The starting idea of the model is to implement communication services with software components and aggregate them to build a sort of dynamic and adaptive service stack. The most important feature of our ecological approach to service aggregation is a clear focus on the environment/infrastructure rather than on the single service. Pervasive services are joined together by special enzyme components distributed among nodes. Using knowledge as the substrate for aggregation reactions, enzymes are able to enable discovery and interoperability of independently evolving communication services. Implementing a fullfledged prototype of the presented ideas is part of our future research work on this project. This will let us choose the right technology/strategies that can effectively realize the proposed ideas.

Acknowledgements.

Work supported by the European Commission within the Integrated Project CASCADAS (FET Proactive Initiative).

6. References [1] [2]

“Autonomic Computing: IBM’s Perspective on the State of Information Technology”, 2003. M. Baumgarten, N. Bicocchi et al., "Towards SelfOrganizing Knowledge Networks for Smart World Infrastructures", International Transactions on Systems

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17] [18]

[19]

[20]

Science and Applications, 1(3), 2006. E. Bonabeau, M. Dorigo, G. Theraulaz, ”Swarm Intelligence: From Natural to Artificial Systems”, Oxford University Press, 1999. W. K. Edwards, M. W. Newman et al., “Challenge: Recombinant Computing and the Speakeasy Approach”, 8th ACM International Conference on Mobile Computing and Networking, 2002. D. Estrin, D. Culler et al., “Connecting the Physical World with Pervasive Networks”, IEEE Pervasive Computing, 1(1):59-69, 2002. K. Fujii and T. Suda, "Semantics-based dynamic service composition", IEEE Journal on Selected Areas in Communication, 23 (12), 2005. M. Huhns and M. P. Singh, “Service-Oriented Computing: Key Concepts and Principles”, IEEE Internet Computing, January-February 2005. J. Kephart, D. M. Chess, “The Vision of Autonomic Computing”, IEEE Computer, 36(1):41-50, January 2003. A. Ketfi, N. Belkhatir, "Dynamic Interface Adaptability in Service Oriented Software", 8th International Workshop on Component-Oriented Programming, 2003. Y. Lee, S. A. Chun, J. Geller, “Web-Based Semantic Pervasive Computing Services”, IEEE Intelligent Informatics Bulletin, 4: 4-15, 2004. A. LiMing, P. Hung-ICeng and L. Zhou, "Design and implementation of a dynamic protocol framework", 12th IEEE International Conference on Networks, 2004. H. Liu, M. Parashar, "A Component-based Programming Model for Autonomic Applications", 1st International Conference on Autonomic Computing, 2004. A. Manzalini, F. Zambonelli, “Towards Autonomic and Situation-Aware Communication Services: the CASCADAS Vision”, 1st IEEE Workshop on Distributed Intelligent Systems, 2006. J.M. Paluska, H. Pham et al., ”Reducing configuration overhead with goal-oriented programming”, 4th Pervasive Computing and Communications Workshops (at PerCom06), 2006. G. Parr and K. Curran, “A Paradigm Shift in the Distribution of Multimedia”, Communications of the ACM, 43(6), pp. 103-109, June 2000. R. Quitadamo and F. Zambonelli, “Autonomic Communication Services: a New Challenge for Software Agents”, to appear in the Journal of Autonomous Agents and Multi-Agent Systems, Springer, 2007. The Semantic Annotations for WSDL Working Group, http://www.w3.org/2002/ws/sawsdl/ Shankar R. P. and A. Fox, “Application-Service Interoperation without Standardized Service Interfaces”, IEEE International Conference on Pervasive Computing and Communication, 2003. I. Sora et al., “Policies for dynamic stack composition”, Tech. Rep., Dep. of Computer Science, Leuven, Belgium, 2001. R. Want, “An Introduction to RFID Technology”, IEEE Pervasive Computing, 5(1):25-33, Jan.-March 2006.