Mobile Web Services for Context-Aware Pervasive Environments

Transcription

1 Mobile Web Services for Context-Aware Pervasive Environments DIONISIS ATHANASOPOULOS VALERIE ISSARNY EVAGGELIA PITOURA PANOS VASSILIADIS and APOSTOLOS ZARRAS In this paper we propose CoWSAMI, a service-oriented middleware that aims at supporting context-awareness in pervasive computing environments. To this end, we rely on the standard Web services architectural style to handle the architectural heterogeneity of available context sources. CoWSAMI balances the trend between the resource limitations of available context sources and the resource requirements introduced by the aforementioned standard, by employing WSAMI, a lightweight middleware infrastructure for the development of mobile Web services. CoWSAMI provides a dynamic and highly scalable service discovery mechanism that deals with the increased behavioral mobility of available context sources. CoWSAMI further handles the behavioral heterogeneity of available context sources through a mechanism that gathers contextual information while adapting its proper behavior to the interfaces of context sources. Finally, CoWSAMI allows querying for contextual information with respect to the aforementioned organization, though a classical SQL-based interface. Categories and Subject Descriptors: []: General Terms: Additional Key Words and Phrases: context-awareness, middleware, pervasive environments, Web services 1. INTRODUCTION Literally, context is defined as the interrelated conditions in which something exists or occurs [Merriam-Webster 2005]. In most cases, conditions change and the entities that function under them must adapt so as to continue their proper functioning. However, the precondition to adaptation is awareness. The entities must somehow know about context changes. In other words, they must be capable of obtaining information that reflects the conditions under which they function. How do we achieve context-awareness in pervasive computing environments? The above question is the main issue tackled in this paper. Context in computing is defined as a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves [Dey 2001]. On the other hand, pervasive computing environments are the natural evolution of conventional distributed systems that comes along with the emergence Authors address: A. Zarras, E. Pitoura, P. Vassiliadis, D. Athanasopoulos, Computer Science Dep., University of Ioannina Campus, PO BOX 1186, GR 45110, Ioannina, Greece. Author s address: Valerie Issarny, INRIA Rocquencourt, Domaine de Voluceau, BP 78150, Le Chesnay, France ACM Transactions on Internet Technology, Vol. V, No. N, December 2005, Pages 1 0??.

2 2 D. Athanasopoulos et al. of various novel technologies such as hand-held computers, wireless networks and sensor devices. Pervasive computing is a combination of ubiquitous computing, networking and intelligent interfaces [Issarny et al. 2005]. The first two terms refer to the existence of computing devices and networking facilities everywhere. The third term relates to the capability of the system that supports the environment to adapt to the specificities of the entities that use it. Naturally, this capability should be offered by the middleware layer of the system. To be context-aware in a pervasive computing environment, one has to be knowledgable of the sources that provide contextual information. This is the first obstacle to context-awareness: in pervasive computing environments it is often the case that context sources are mobile. Context sources may be mobile in two senses: first, they may arbitrarily join and leave the environment and second, their computational resources may be limited (e.g., battery, memory, storage, etc.). Hereafter, we refer to the former aspect of mobility as behavioral mobility. Moreover, we use the term architectural mobility to refer to the second aspect of mobility. To be context-aware, one has to be further able to communicate with context sources. Hence, we arrive to the second obstacle: context sources are highly heterogeneous. As with the case of mobility, heterogeneity appears in two senses, architectural and behavioral. Architectural heterogeneity refers to the different device types, operating systems, implementation languages and communication protocols assumed by the different context sources. Behavioral heterogeneity relates to the different interfaces provided by context sources. Specifically, in a pervasive computing environment semantically compatible contextual information may be provided through different types of interfaces. Dealing with heterogeneity and mobility towards context-awareness is not straightforward. Until now, research in the field of context-aware middleware and applications focused mostly on the aspects of modeling and reasoning about context changes and adaptation actions [Baldauf et al. 2005], while skipping the first important step that comprises a realistic approach for obtaining information about these changes. Existing approaches to context-awareness assume that the behavior of context sources adheres to constraints (e.g., by providing infrastructure specific interfaces) imposed by the middleware infrastructure in charge of obtaining contextual information. In this paper, we go one step further by adding interface intelligence in the environment along with ubiquitous computing and networking. Specifically, we propose CoWSAMI : a middleware infrastructure that adapts its proper behavior to the behavior of context sources to support context-awareness. How does CoWSAMI deal with architectural heterogeneity? CoWSAMI relies on the standard Web services architecture [W3C 2004a]. Web services are software entities with well-defined interfaces identified by a URI (i.e., a Uniform Resource Identifier such as a Uniform Resource Location (URL) of a Uniform Resource Name (URN)). Their interfaces are specified using WSDL (Web Services Description Language)[W3C 2005]. Interaction with Web services is realized though messages that follow the SOAP standard [W3C 2002]. SOAP may rely on a variety of other communication protocols such as HTTP and SMTP. In CoWSAMI, we employ Web services to confront the increased architectural heterogeneity of pervasive computing environments by encapsulating context sources and

3 Mobile Web Services for Context-Aware Pervasive Environments 3 exporting their operations through platform-independent interfaces. The overall development of Web services for heterogeneous context sources may be automated (e.g. in [Plitsis et al. 2005] we discuss the particular case of automating the integration of GSM-enabled mobile sensors in pervasive environments). How does CoWSAMI handle architectural mobility? The current practice with Web services has showed that the middleware infrastructures that support their development are certainly not lightweight. The fact that Web service descriptions rely on an XML-based language (i.e., WSDL) makes their processing quite demanding in computational resources (e.g., memory and CPU time). Similarly, SOAP defines an XML-based message format. Therefore, processing SOAP messages is also demanding regarding computational resources. To deal with these issues, CoWSAMI extends previous work on WSAMI [Issarny et al. 2005], a lightweight middleware infrastructure that supports the development of mobile Web services. How does CoWSAMI deal with behavioral mobility? Amongst its core services WSAMI provides the Naming&Discovery service that allows discovering networked WSAMI entities with respect to a given interface that they should provide. On top of Naming&Discovery, CoWSAMI provides a service for context sources discovery, named ContextManager. Specifically, the ContextManager manages a constantly changing repository of context sources with respect to various update policies customized by context-aware entities. Each entity deploys locally its proper instance of the ContextManager service. How does CoWSAMI handle behavioral heterogeneity? CoWSAMI provides a service, named ContextCollector, whose main purpose is to resolve the behavioral heterogeneity of context sources. To achieve this, we introduce the concept of context rules. Roughly, a context rule specifies how to obtain the values of context attributes by using different types of interfaces offered by different categories of context sources. The rule is defined with respect to the operations that should be invoked on each different interface and the structure of the messages, exchanged during the invocations. Context rules are given as input to the ContextCollector service. Following, the service tailors its proper behavior with respect to the context sources included in a particular pervasive computing environment. Finally, CoWSAMI provides an easy to use front-end service, named QueryExecutionEngine, for the collection of contextual information. In a typical situation of a pervasive computing environment, the users will not be sitting comfortably in front of their workstation, having the ability to write down code that uses CoWSAMI services to gather contextual information. Moreover, the typical users will not be experienced developers, familiar with Web service programming. Hence, they should be provided with more simple means, which will allow them to efficiently collect contextual information. To this end, we rely on ideas from the field of traditional databases. Typical database query languages provide a classical declarative way for managing and exploring information stored in a database. In our case, the database is substituted by contextual information, stored everywhere in the pervasive computing environment. Hence, it is challenging to keep the same classical frontend for gathering this contextual information. The QueryExecutionEngine service

4 4 D. Athanasopoulos et al. Fig. 1. CoWSAMI Architecture incarnates this idea by accepting as input SQL-based queries and transforming them to Web service invocations (in collaboration with the ContextManager and the ContextCollector services), targeted to context sources. The remainder of this paper is structured as follows. Section 2 details the architecture of CoWSAMI and further motivates its use through a reference example. Moreover, Section 2 summarizes the foundation WSAMI services that are used in CoWSAMI. Section 3 details the behavior of the ContextManager, the ContextCollector and the QueryExecutionEngine services. Section 4 provides an experimental evaluation of CoWSAMI. Section 5 discusses related work from the fields of serviceoriented, pervasive and context-aware computing. Finally, Section 6 concludes this paper with a summary of our contribution and the future research directions of this work. 2. COWSAMI ARCHITECTURE Figure 1 gives our perception of a pervasive computing environment and an overview of the CoWSAMI architecture. The main constituents of the architecture are discussed in Section 2.1. The foundation WSAMI services upon which CoWSAMI relies are detailed in Section 2.2. Finally, Section 2.3 introduces a reference example that serves for illustrating the use of CoWSAMI.

5 2.1 Architecture Mobile Web Services for Context-Aware Pervasive Environments 5 A pervasive computing environment consists of a set of networked entities, developed on top of the CoWSAMI infrastructure. The entities are connected through a typical LAN or WLAN (Wireless Local Area Network). A pervasive environment may further comprise entities located on the Internet. The latter must be registered on specific universal service repositories which may be optionally incorporated in the environment by the entities that constitute it during the configuration of the CoWSAMI infrastructure. The entities may vary in type from typical stationary workstations and PCs to hand-held and embedded devices such as PDAs, smart-phones, sensors, etc. Given that WSAMI supports both ad-hoc and infrastructure-based connectivity, this particular issue is transparent to CoWSAMI. Each CoWSAMI entity may provide a number of Web services and use services of other entities. CoWSAMI services are specified using the WSAMI language that extends WSDL with features enabling a more detailed behavioral description. Specifically, a WSAMI specification consists of an abstract and a concrete part. The abstract part specifies the interface of a service and all the possible valid conversations that can be realized through this interface. The interface is given in terms of a WSDL document, whose URI is referenced in the abstract part. The conversations are given in terms of a standard WSCDL (Web Services Choreography Description Language) [W3C 2004b] document, whose URI is also referenced in the abstract part of the service specification. More than one WSAMI specifications may have the same abstract part, as long as they describe services providing the same interface. The concrete part of the WSAMI specification contains binding information (e.g., the endpoint address of the service, the communication protocol used, etc.). The WSAMI specification may optionally include a third part that contains references to URIs of documents describing other WSAMI services used by this particular one. Every CoWSAMI entity may be considered as a context source that provides information through its services. The context that interests an entity is modeled by a set of context attributes of a specific type. The contextual information that corresponds to a context attribute is a value provided by a context source. In general, a pervasive computing environment may comprise more than one context sources that report semantically equivalent information (e.g., two different cars reporting their current velocity). Moreover, a context source may provide values for more than one semantically related context attributes (e.g., the velocity and the brand of a car). Therefore, related context attributes are organized into relations. A context relation is characterized by a name and a finite set of context attributes. The contextual information modeled by a relation is a finite set of tuples, i.e., a finite subset of the cartesian product of the domains of the attributes that constitute the relation. This database-like modeling of contextual information allows formulating queries against relation instances, which are populated at runtime through the use of CoWSAMI services. Specifically, a CoWSAMI entity comprises instances of three CoWSAMI services, named ContextManager, ContextCollector and QueryExecutionEngine. The ContextManager provides operations allowing context sources to join and leave a pervasive environment. The ContextManager is further responsible of locating

6 6 D. Athanasopoulos et al. reachable CoWSAMI entities that may serve as context sources for the information that interests the entity. To achieve this, the WSAMI Naming&Discovery service is used. The services provided by context sources are categorized with respect to the interface that they provide (i.e., with respect to the abstract part of their WSAMI specifications). Information concerning every different category is stored into a local repository maintained by the ContextManager. The repository contents are updated with respect to the following three alternative policies: Update-On-Demand: the repository contents are updated upon a request issued by the entity that comprises the ContextManager. Periodic-Update: the repository contents are updated periodically, with respect to a period given as input to the ContextManager by the entity. Always-Update: the repository contents are updated whenever a context source of interest joins or leaves the environment. The users of the entity are responsible for defining the context relations that interest them, using the ContextCollector service. Then they may issue context queries for these relations, through the QueryExecutionEngine service. Following, the service makes use of the ContextCollector to dynamically compile the context relations that concern the queries. The resulted information is further processed with respect to typical query processing operators and returned to the users. The ContextCollector compiles the context relations with respect to the contents of the repository that is maintained by the ContextManager. For every different category of context sources, it uses different context rules so as to compile the relations. As discussed in Section 1, a context rule specifies how to obtain the values of the context attributes that constitute a relation though the use of the interface of a particular category of context sources. The definition of context rules is also a responsibility of the entity s users. 2.2 WSAMI Foundation Services The main constituents of WSAMI that were used as a basis for the realization of CoWSAMI are the CSOAP broker and the Naming&Discovery service. CSOAP is a lightweight mechanism that allows to deploy, invoke and execute Web services on resource-constrained devices. Specifically, resource-constrained entities issue SOAP requests towards Web services, through standard JAXRPC [SUN 2004b] invocations. The target Web services serve these requests and reply back with SOAP response messages that are also issued through CSOAP. CSOAP was realized on top of the standard J2ME (Java 2 Micro Edition) platform [SUN 2004a] and comes along with the following tools: A compiler that generates Java stubs from WSAMI service specifications. The WSDL2WSAMI tool that generates WSAMI specifications for WSAMIenabled Web services, given their pure WSDL specifications. The InstallWSAMI tool that deploys and configures services on the WSAMI middleware. The Naming&Discovery service is a mechanism for dynamic service discovery. An instance of the service is deployed on every WSAMI entity. The service instance manages two repositories, storing information regarding Web services that

7 Mobile Web Services for Context-Aware Pervasive Environments 7 are available in the environment. Specifically, the information stored for each available service is the URI of the service s WSAMI specification. The overall discovery process is realized using URIs instead of XML documents to economize resources on the side of resource-constrained devices. The first repository maintained by the service is named local repository and contains the URIs of the Web services provided by the WSAMI entity that hosts the repository. The second repository is called remote repository and acts as a local cache that contains URIs of Web services deployed on other reachable WSAMI entities. The remote services were once discovered by the entity that hosts the remote repository, using the Naming&Discovery service. The size of the remote repository is set during the configuration of WSAMI infrstracture. The repository s replacement strategy follows the LRU (Least Recently Used) policy. Locating Web services though the Naming&Discovery service is done according to the following steps: (1) An entity requests the URI of an abstract WSAMI specification that describes the interface of the required Web services. (2) Based on the given URI, the local and the remote repositories of the Naming&Discovery service deployed on the requesting entity are searched for matching URIs. The results obtained may be of the following kinds: (a) URIs of services provided by power-plugged WSAMI entities that reside on the WLAN of the requesting entity. (b) URIs of services provided by power-plugged WSAMI entities on the Internet. (c) Matching URIs of services provided by non power-plugged entities. (3) The entity s request is forwarded to all other reachable Naming&Discovery service instances. Each of these instances performs step 2 and returns the results back to the requesting entity. If a reachable service instance fails to locate a matching URI it does not further forward the request and responds with an exception. The identification of other reachable Naming&Discovery service instances primary relies on the standard SLP (Service Location Protocol) protocol [Guttman et al. 1999]. Specifically, we use the OpenSLP 1 implementation of this standard. Every CoWSAMI entity comprises an SLP server. The Naming&Discovery service of the entity registers to this server. The latter is responsible for periodically multicasting the address of the local Naming&Discovery service to every other reachable Naming&Discovery service. (4) Optionally, the entity s request is forwarded on a universal service repository, specified during the initialization of the Naming&Discovery service. In the previous steps we assume the existence of an infrastructure-based network. In the case of an ad-hoc one, similar steps are performed [Issarny et al. 2005; Sailhan and Issarny 2003]. Moreover, the previous steps are used in the case where an entity wants to locate all services providing a required interface. A similar discovery process is used in the case where the entity looks for only one service providing this interface. The overall discovery process may be further enhanced 1

8 8 D. Athanasopoulos et al. with additional QoS criteria (e.g., reliability, availability, reputation, performance) that are currently under investigation [Liu and Issarny 2004; Zarras et al. 2004; Papadopoulos et al. 2005]. 2.3 Reference Example To illustrate the CoWSAMI approach we extend the reference example used in [Issarny et al. 2005] for demonstrating WSAMI. Specifically, we assume a pervasive computing environment at the city of Rocquencourt, near Versailles. Our environment offers CyberCars 2 to Rocquencourt citizens and tourists (Figure 2(a)). CyberCars are unmanned cars that may be booked though the Web, towards moving across different sites of the city. Each CyberCar is equipped with its own computing facilities. Moreover, it may communicate with other entities through a wireless network. In the general case, different types of CyberCars may exist, possibly coming from different manufacturers. Their embedded computer is a CoWSAMI entity that provides information regarding the CyberCar s features (e.g., velocity, position, brand etc.). Contextual information is provided through Web services offering possibly different manufacturer-specific interfaces. Figure 3(a) and (b) give the WSAMI specifications (abstract parts) of the services of two different types of CyberCars. Specifically, CyberFrogs (Figure 3(a)) provide an homonymous Web service whose interface offers 6 different operations that can be invoked to obtain a unique identifier that characterizes each CyberFrog, the CyberFrog s brand, velocity, fuel, and coordinates. On the other hand, CyberCabs (Figure 3(b)) provide a Web service that offers a single operation, named getstate(). This operation responds with a message that encapsulates all the characteristics of a CyberCab (i.e., its identifier, brand, velocity and coordinates). The city of Rocquencourt further offers Web services that provide information regarding the city s hotels and restaurants. The interfaces of these services may also vary depending on the different hotel companies and restaurants (e.g., IBIS, Novotel, etc.). Finally, the Rocquentcourt city-hall provides a Web service that reports the location of various sites (monuments, organizations, hospitals, business centers, etc.). The contextual information that interests the CyberCar passengers may vary and the way to collect it is though CoWSAMI. To achieve this, the passengers must be equipped with CoWSAMI-enabled devices such as PDAs, laptops or smart-phones. Each passenger may define the context that interests him in its proper way. Take, for instance, the case of an English speaking tourist who is interested in the current status of the traffic and the available city hotels. Using his PDA, he may define the relations given in the upper part of Figure 2(b). The first relation is named TRAFFIC and consists of 6 attributes (named ID, BRAND, VELOCITY, FUEL, XCOORD and YCOORD) that correspond to the unique identifier of each Cyber- Car that circulates in the environment, its brand, velocity, fuel and coordinates. A typical tuple of this relation could be the following: (103, NetMobilFrog, 40, 0.75, , ). The second relation is named MAP and consists of three attributes that correspond to the name of a site and the coordinates that determine the location of this site. The third relation is called HOTELS and comprises 3 attributes that correspond to a hotel identifier, and the prices for single and double 2

9 Mobile Web Services for Context-Aware Pervasive Environments 9 (a) The CyberCar environment. (b) Context relations and queries. Fig. 2. Using CoWSAMI in the city of Rocquencourt. rooms. A French speaking Rocquencourt citizen may be interested only in the current status of the city traffic. Therefore, he may exploit the context relations given in the lower part of Figure 2(b). The first relation is analogous to the TRAFFIC relation defined by the tourist; it is named CIRCULATION and consists of 5 attributes, named ID, MARQUE, VITESSE, XPOS and YPOS. The second relation is named

10 10 D. Athanasopoulos et al. (a) The CyberFrog interface. (b) The CyberCab interface. Fig. 3. Different CyberCar interfaces in the WSAMI language.

11 Mobile Web Services for Context-Aware Pervasive Environments 11 Fig. 4. CoWSAMI services. PLAN and it is similar to the MAP relation, defined by the tourist. The upper part of Figure 2(b) further shows a query issued by the tourist against the TRAFFIC relation. The query returns the number of CyberCars that circulate in an area defined by the current position of the tourist s CyberCar and the position of the tourist s destination. Similarly, the lower part of Figure 2(b) shows the query that is issued by the Rocquencourt citizen to check for the current status of the traffic towards the citizen s destination. Answering any of the two queries amounts in checking the position of all the different CyberCars that can be accessed. Finding these entities and categorizing them with respect to the different interfaces that they provide (e.g., CyberFrogs and CyberCabs) is a responsibility of the ContextManager. Collecting the position of each entity is performed using the ContextCollector with respect to context rules, given for every different category of CyberCars. 3. COWSAMI SERVICES The interfaces of the core CoWSAMI services are depicted in Figure 4. Following, we discuss further details regarding the realization of these services. Section 3.1 details the ContextManager service, Section 3.2 presents the ContextCollector. Finally, Section 3.3 discusses QueryExecutionEngine service. 3.1 The ContextManager service A CoWSAMI entity joins or leaves a pervasive computing environment by invoking the homonymous operations of the ContextManager interface (Figure 4). Moreover, an entity discovers the different types of interfaces provided by the context

12 12 D. Athanasopoulos et al. sources available in the environment through the use of the FindCategories() operation. That way the entity becomes aware of the different categories of context sources. Following, it may use the UpdateOnDemand(), the PeriodicUpdate() or the AlwaysUpdate() operations to populate the repository that stores URIs of available context sources of interest and (re)configure the policy used for updating the repository s contents. Figure 5(a) gives the general structure of the repository. As discussed in Section 2, the repository consists of a number of categories. A category is characterized by the URI of the WSDL description that specifies the particular interface provided by the context sources belonging in the category. All the URIs stored in the category correspond to WSAMI specifications, whose abstract parts reference the URI that characterizes the category. The category is further characterized by the names of the context relations to which it contributes. Figure 5(b), for example, gives a possible snapshot of the repository managed by the ContextManager deployed on the English tourist s PDA. The repository comprises 2 categories for CyberCar URIs, 2 categories for hotel URIs and a single category for the Rocquencourt city hall service. The first of the CyberCar categories is characterized by the URI of the CyberFrog interface given in Figure 2(b). Similarly, the second category is characterized by the URI of the CyberCab interface given in Figure 2(c). The CyberFrog category contains 2 URIs of networked services providing this interface. On the other hand, the CyberCab category contains 3 URIs of networked CyberCab services. The hotels categories are characterized by URIs that correspond to IBIS and Novotel specific interfaces Joining a pervasive computing environment. A CoWSAMI entity that wishes to play the role of a context provider to other CoWSAMI entities must call the Join() operation. The Join() operation accepts as input the URIs of the services offered by an invoking entity. In our example, every CyberCar entity must call the Join() operation so as to become available as a context source to passengers. Similarly, every hotel and restaurant entity must join the pervasive computing environment. For every service given as input to the Join() operation, the following steps are performed: (1) The service is registered to the local Naming&Discovery service. (2) The repository managed by the ContextManager is checked for the existence of a category characterized by an interface that matches the interface of the service. To achieve this step the abstract part of the WSAMI service specification is used. If the category exists the service URI is stored in this category, otherwise the ContextManager constructs a new category in the repository and stores the given URI. (3) The ContextManager checks for the existence of other networked CoWSAMI entities, requiring that their ContextManager repositories are always up-to-date (e.g., the passengers of CyberCars that are interested in the current status of the city traffic). In other words, the ContextManager looks for entities that previously enabled the Always-Update policy as detailed in Section To achieve this, the Naming&Discovery service is used in a first step for locating reachable ContextManagers available in the environment. Following, it is

13 Mobile Web Services for Context-Aware Pervasive Environments 13 (a) Repository structure. (b) Repository instance. Fig. 5. ContextManager repository. checked whether any of them have their Always-Update policy enabled for the particular category of context sources that includes the given service. Then, the ContextManager of the joining entity calls Join() on the aforementioned ContextManagers. The input to these calls is the URI of the service of the joining entity along with a flag that notifies the invoked entities that this is an update call performed by the ContextManager of a joining entity. In response, the invoked ContextManagers perform steps 1-2 mentioned above Leaving a pervasive computing environment. The Leave() operation should be used by entities that wish to resign from playing the role of context sources to other entities. The input given to the Leave() operation is the URIs of the services that were registered to the Naming&Discovery service by these entities at the time when they joined the environment. In our reference example, the Leave() should be called, for instance, by CyberCars that no longer wish to be context sources, possibly because they are parked. Similarly, the Leave() operation may be called by hotels that are full-booked.

14 14 D. Athanasopoulos et al. For every given URI, the following steps are performed by the ContextManager of the leaving entity: (1) The service is unregistered from the local Naming&Discovery service. (2) The repository managed by the ContextManager is searched for the category that contains the given URI. This step is realized with respect to the abstract part of the WSAMI service specification that is referenced by the given URI. Following, the URI is removed from the category (actually for efficiency reasons the URI is marked unavailable for a certain time period before it is removed). (3) The ContextManager of the leaving entity checks for the existence of other networked CoWSAMI entities that previously enabled the Always-Update policy for the particular category of context sources. Then, the ContextManager calls the Leave() operations on the ContextManagers of these entities. The input to these calls is the URI of the service of the leaving entity and a flag that notifies the invoked entities that this is an update call performed by the ContextManager of a leaving entity. Given this input, the invoked ContextManagers proceed with performing steps 1-2 mentioned above Discovering available categories of context sources. To find out about the available categories of context sources in a pervasive computing environment, an entity calls the FindCategories() operation. In our reference example, for instance, tourists and Rocquencourt citizens must call this operation to find out about the different types of context sources available in the city. The operation may be called more than once by the entities as the availability of different types of context sources may change along with the availability of the context sources themselves. The realization of the operation proceeds as follows: (1) First, a list of reachable ContextManager services is located, using the Naming&Discovery service. (2) Then, FindCategories() operation is called on each one of these services with a flag that notifies the invoked services that this is a call made by a remote ContextManager. In response, the invoked ContextManager services sent the URIs of the WSDL interface specifications supported by the different services offered by the entity where they are deployed. (3) Finally, the overall set of WSDL interface specifications that results from the aforementioned invocations is returned to the calling entity Populating the repository. The UpdateOnDemand() operation accepts as input a category of context sources (particularly the input is the URI of the WSDL interface specification that characterizes the category). The contents of this category are immediately updated upon a call on the operation. In our reference example the UpdateOnDemand() operation could be called by Rocquencourt tourists for the hotels category. The availability of hotel services are not expected to change fast. Therefore, it is reasonable to use the Update-On-Demand policy towards discovering the URIs of these services Specifically, upon a call to the UpdateOnDemand() operation, the ContextManager performs the following steps:

15 Mobile Web Services for Context-Aware Pervasive Environments 15 (1) If the given category does not exist in the repository maintained by the ContextManager, it is created. (2) The local Naming&Discovery service is invoked towards locating reachable entities that provide services offering the interface that characterizes the given category. The result of this call is the set of the URIs of the services (e.g., the hotel services URIs of Figure 5(b)). Before storing the retrieved URIs in the given category there are two further issues resolved by the ContextManager: (a) If the ContextManager is deployed on a resource-constrained device, it checks whether the retrieved URIs correspond to services that actually exist in the environment. In particular, a URI may be discovered in the remote repository of a networked Naming&Discovery service. As discussed in Section 2.2, the remote repositories act as LRU caches. Hence, it is probable that the cashed URI is no longer valid. To perform this check, an operation is randomly picked based on the WSDL interface that characterizes the category of the service whose URI is checked. Following, this operation is called by the ContextManager. If an exception is raised, the URI is considered invalid, otherwise the URI is normally stored in the category. The validity check of the URIs discovered through the Naming&Discovery service could be avoided for the shake of efficiency. However, this would imply that certain context sources are going to be used by the ContextCollector service (possibly more than once) without actually being available. This may eventually result into a significant energy lick. Even though the validity of URIs is checked, it is important to note that they may become invalid until the time they are used for collecting contextual information. Therefore, the URIs validity check is actually a best-effort approach for reducing energy consumption. (b) The ContextManager further checks if the entities that provide the retrieved URIs are CoWSAMI-enabled. Specifically, it is checked whether the entities provide a ContextManager service. This particular constrain is necessary for the realization of the Always-Update-Policy that may be potentially activated by the invoking entity. Naturally, the PeriodicUpdate() operation accepts as input a category of context sources and a time period T. Invoking the operation results on the creation of a new thread which resumes its execution every T time units. At this point, it invokes the UpdateOnDemand() operation so as to update the repository contents of the given category. The AlwaysUpdate() operation also takes as input parameter a category. The entities that belong in this category are discovered by calling the UpdateOnDemand() operation. Following, the invoked ContextManager notifies all the ContextManagers of the entities that provide services of the given category about the fact that the invoking entity enabled the Always-Update policy for this particular category. Based on this setup, the invoked entities are able to notify the invoking one about their leaving through the use of the Leave() operation (Section 3.1.1). In our reference example, it is reasonable to assume that tourists and Rocquencourt citizens use either the PeriodicUpdate() or the AlwaysUpdate() operation to discover available CyberCar services. The availability of CyberCar services typically

16 16 D. Athanasopoulos et al. changes much faster than hotel services. Therefore, it is natural to use the Periodic- Update or the Always-Update policies for updating the corresponding repository categories. 3.2 The ContextCollector service A CoWSAMI entity defines the context relations that interest it by invoking the DefineContext() operation of the ContextCollector interface (Figure 4). Similarly, it uses the RulesPerRelation() operation to define context rules for these relations. The CollectContext() operation serves for populating the defined relations with contextual information Defining context. Figure 6(a) shows the general structure of a context definition provided as input to the DefineContext() operation. As discussed in Section 2.1, a context definition comprises a set of context relations characterized by a name and a number of context attributes. An attribute is characterized by a name and a type. Figure 6(b) gives the actual XML schema used for context definitions. According to this schema, relations are specified using the ContextRelation tag. Within this tag we can define one or more context attributes using the ContextAttribute tag. Figure 6(c) gives the context relation definitions defined in our reference example in the case of the English tourist. Given a context definition, the following steps are performed by the ContextCollector service. (1) The definition is parsed towards identifying its constituent relations. (2) Every relation is parsed towards locating its constituent attributes. (3) For every relation, a corresponding table is created and stored persistently (e.g., in a typical file in the case of CoWSAMI entities deployed on stationary workstations, in the persistent storage memory part, in case of CoWSAMI entities deployed on mobile devices such as PDAs, mobile phones, etc.) Defining context rules. The WSDL interface of a particular category of context sources is specified in terms of a number of PortType definitions (Figure 4(a), (b)). A PortType, in turn, consists of the definitions of a number of operations that can be called on the context sources interface. Each operation specifies an input and an output message. The former element refers to the SOAP request message sent upon the operation invocation, while the latter element refers to the SOAP message returned in response to the invocation. The specification of a message consists of one or more parts. Each part is characterized by a name and the particular type of datum exchanged between a service that provides the interface and an entity that uses this service. Therefore, a context rule that describes how to populate a context relation, using the interface of a particular category of context sources is specified according to the schema given in Figure 7. In particular, a context rule is characterized by the name of the context relation (described using the ContextRelation tag) and the URI of the WSDL interface specification (described using ContextSourceCategory tag). The rule further comprises one or more ContextAttributeMapping elements. Each of these elements refers to a context attribute of the specified relation (specified using the ContextAttribute tag) and an operation (specified using the ContextSourceOp-

17 Mobile Web Services for Context-Aware Pervasive Environments 17 (a) Context structure. (b) Context schema. (c) Context example. Fig. 6. Context definition. eration tag) offered by the specified interface ; it specifies how to obtain a value for the attribute by invoking this operation. Specifically, a ContextAttributeMapping element comprises two constituent parts. The ContextInputMessage part is characterized by the type of the request message that should be sent upon the operation invocation. The ContextInputMessage part further specifies a sequence of values that should be the contents of the message sent upon the operation invocation. The ContextOutputMessage part is characterized by the type of the response message received after the operation invocation (specified using the ContextSourceMessage tag). Moreover, the ContextOutputMessage part specifies the name of the actual part of the response message that contains the value of the specified context attribute (specified using the ContextSourceMessagePart tag).

18 18 D. Athanasopoulos et al. (a) Context rules structure. (b) Context rules schema. Fig. 7. Context rules definition.

19 Mobile Web Services for Context-Aware Pervasive Environments 19 Context rules are given as input to the ContextCollector service by invoking the RulesPerRelation() operation, offered by this service. Following, every rule is parsed and its embedded ContextAttributeMapping elements are grouped with respect to the operation that has to be called to fill up the value of a context attribute. This grouping is necessary for optimizing the collection of contextual information in cases where the values of more than one attributes are obtained by calling a single operation for all of them (e.g., Figure 8(b)). Finally, every context rule is stored persistently in the device where the ContextCollector service is deployed. Getting to our reference example, Figure 8(a) gives the rule that describes how to populate the TRAFFIC relation defined by the English tourist (Figure 6(c)), using the interface of CyberFrog entities (Figure 4(a)). The rule specifies a context attribute mapping for each one of the ID, BRAND, VELOCITY, FUEL, XCO- ORD, YCOORD attributes. To obtain a value for the VELOCITY attribute, for instance, the getvelocity() operation must be invoked. No input message is needed for this invocation since the operation accepts no input parameters. The actual value of VELOCITY is stored in the getvelocityreturn part of the getvelocityresponse message (see Figure 4(a) for the definitions of these WSDL elements) that is returned upon the invocation on the aforementioned operation. Similarly, to obtain a value for the ID attribute, the getid() operation must be invoked. Again, there is no need for an input message for this invocation. The value of ID is stored in the getidreturn part of the getidresponse message. On the other hand, Figure 8(b) gives the rule that describes how to populate the same relation, using the interface of CyberCab entities (Figure 4(b)). To obtain a value for the VELOCITY attribute, in this case, the getstate() operation must be invoked. The value of VELOCITY is now stored in the Velocity part of the getstateresponse message. Similarly, to obtain a value for the ID attribute, the same operation must be called. The value of the attribute is stored in the ID part of the aforementioned message Collecting contextual information. Collecting contextual information amounts in calling the CollectContext() operation on the ContextCollector service. This operation accepts as input a context relation. Then, it performs the following steps: (1) The different categories of context sources that contribute in the collection of tuples for the given relation are located in the repository. (2) The context rules for every category obtained from the previous step are loaded. (3) The operations prescribed in every rule are executed for every different context source URI stored in the corresponding category. (4) The response message from every invocation is parsed towards obtaining the values of one or more context attributes of a tuple. (5) Finally, the resulting tuples are returned to the invoking entity, which is further provided with the option of storing these tuples persistently. Taking our reference example, suppose that CollectContext() is invoked to dynamically assemble the tuples of the TRAFFIC relation. The two categories of context sources that contribute to this relation are those providing the CyberFrog

20 20 D. Athanasopoulos et al. (a) Context rules for the CyberFrog interface. (b) Context rules for the CyberCab interface. Fig. 8. Context rules examples. and the CyberCab interfaces (Figure 4(a), (b)). The rules obtained for these categories are the ones given in Figure 8(a), (b). For every CyberCab URI stored in the cabs category (Figure 5(b)), the getstate() operation is called. The response message of each invocation results in a different tuple of the TRAFFIC relation. On the other hand, for every CyberFrog URI stored in the frogs category, more than one operations are called to compile a tuple. Each operation contributes to a different attribute of the given context relation. 3.3 The QueryExecutionEngine service Currently, the QueryExecutionEngine service simply assembles the functionality provided by the rest of the CoWSAMI services to allow executing SQL queries on contextual information collected by reachable context sources.

21 Mobile Web Services for Context-Aware Pervasive Environments 21 The fundamental steps of the QueryExecutionEngine are as follows: (1) For every context relation specified in the FROM clause of a query, the CollectContext() operation is called on the ContextCollector service. (2) The compiled tuples returned by each invocation are processed with respect to the given query and results are returned back to the issuing entity. (3) The processing of the tuples can be built differently, depending on whether the issuing entity is resource-constrained or not. Specifically: For the case of resource-constrained entities, the QueryExecutionEngine comprises a simple set of main memory relational operators that directly process the incoming tuples. This lightweight configuration is suggested for a limited subset of any query language and can manage only a small size of incoming tuples. A possible alternative that we further investigate is the integration of the QueryExecutionEngine with existing DBMS support for such kind of devices (e.g. Oracle Lite [ORACLE 2004], IBM DB2 Everyplace [Karlsson et al. 2001]). For non-resource-constrained entities, the QueryExecutionEngine is integrated with a full blown relational engine. Up to now, we particularly focus on the integration of the QueryExecutionEngine service with MySQL, due to our previous experience with this specific relational engine. However, several other similar technologies may be used. 4. EXPERIMENTAL EVALUATION To assess CoWSAMI we implemented a first prototype of the services discussed in Section 3. The services were implemented on top of WSAMI. Therefore, their resource requirements and performance depend on the corresponding resource requirements and performance of the basic WSAMI constituents that were discussed in Section CoWSAMI resource requirements In this section we specifically detail the memory requirements of the ContextManager and the ContextCollector services. The issue of energy consumption is also discussed for these services. As mentioned in Section 3.3, the realization of the QueryExecutionEngine may rely on various configurations possibly built on top of existing commercial solutions. Its resource requirements depend, thus, on these configurations, whose experimental evaluation is not detailed in this paper. Currently, resource-constrained devices come with various technical characteristics (CPU, OS, memory, autonomy, etc.) 3. The available memory in the most recent models of PDAs ranges from 8MB to 256MB. However, there still exist few PDA models that come with less than 4MB of RAM. Similarly, the memory provided by the most recent smart-phones ranges from 8MB to 32MB, while there still exist few models that come with less than 4MB of RAM. The overall memory footprint of the WSAMI platform is 3.9MB [Issarny et al. 2005]. Therefore, it is suitable for CoWSAMI entities that execute on top of devices providing at least 8MB of memory. 3

22 22 D. Athanasopoulos et al. (a) ContextManager service. (b) ContextCollector service. Fig. 9. Memory requirements of CoWSAMI services before optimization. The additional memory requirements of the ContextManager and the ContextCollector services vary depending on the operations performed by these services. Specifically, joining or leaving an environment using the ContextManager service requires less than 750KB of memory. The realization of the Update-On-Demand and the Always-Update policies also requires less than 750KB. The realization of the Periodic-Update policy is slightly more expensive, requiring less than 850KB. The extra overhead of this policy is due to the use of the additional thread that periodically executes the UpdateOnDemand() operation (Section 3.1.4). Regarding the ContextCollector service, the DefineContext() and the RulesPerRelation() operations are quite cheap since they do not involve any additional invocations on middleware services or on services provided by available context sources. On the other hand, the CollectContext() operation involves contacting available context sources towards collecting contextual information provided by these sources. Hence, its memory requirements are higher. However, the overall execution of the operation requires less than 600KB of memory. At this point, it is worth mentioning that the aforementioned values were obtained after optimizations performed in the early versions of the ContextManager and the ContextCollector services. In particular, in the first version of the ContextManager we observed that the amount of memory required for updating the contents of a