ical computing devices and sensors belonging to the envi- ronment each ... file in order to allow the services to request context informa- tion in a way that is ... The service provisioning layer .... How to connect to the context data base. Context ...
Context Aware Service Provisioning Soraya Kouadri MostCfaoui University of Fribourg Pervasive and Artificial Intelligence Group Chemin du MusCe 03, Ptrolles 1700 Fribourg, Switzerland kouadris @ acrn.org
Beat Hirsbrunner University of Fribourg Pervasive and Artificial Intelligence Group Chemin du MusCe 03, PCrolles 1700 Fribourg, Switzerland beat.hirsbrunner @unifr.ch
Abstract
pervasive and users’ expectations are constantly changing, it is extremely important to include user’s context in the provisioning of services. Indeed, students would like having a personal library reminder triggered once they are approaching the library and their restaurant menu displayed on their palm pilots once they are approaching the restaurant at lunch time. Some users would like having certain services, such as traffic conditions, automaticallytriggered once they get into their cars, others would like having weather conditions sent to their mobile phones once they go out form the office. These illustrative scenarios shed the light on the importance of including context and its impact on adjusting the applications and the services offered. In this paper we present a generic approach that combines service-oriented and context-aware computing in order to provide users with more tailored composite services in pervasive computing environments. The general architecture of our system called CB-Sec ‘is shown in Fig. l . The physical entities layer represents a federation of physical computing devices and sensors belonging to the environment each time given. The application layer embodies the application interface that supports users to implement context-aware services. The context management and service provisioning layers are the core part of the system. The context management layer is responsible for acquiring contextual information for hardware and software sensors, classifying this information using a specialized XML schema file in order to allow the services to request context information in a way that is decoupled from the mechanisms used to acquire this information. And finally to store this information in a dedicated database. The service provisioning layer is responsible for the discovery, composition, execution and caching of the requested services [12]. In section 2 we present how context is defined in our system. Section 3 presents the operation of the contextaware approach. Section 4 describes the different stages for
I n this papec we present our initiative on a new direction of researchfor bringing into the commonfold context-aware computing and Web services-oriented computing, Our long term research objective is to allow users to satisfy their needs regardless of their location and the resources that are considered in the pelformance of the services. Our contribution is the enhancement of the service discovery and composition by taking into account the available contextual iitfoniiation. As a j r s t step towards this goal we are in the process of designing a new service description based on context.
1. Introduction and Overview Web services are nowadays emerging as a major technology for deploying automated interactions between distributed and heterogeneous applications. One of the major strengthens of Web services is their capacity to be composed with other services into high level process referred to as composite services. Composite services are particularly useful when a client’s request cannot be solved by any available basic services, whereas combining more than one basic service would solve the query. Discovering the component services, inserting the services into a composite service, triggering the composite service for execution, and monitoring this execution are among the operations that users will have to be responsible. Existing approaches for service discovery and composition, such as, the dynamic service composition called software hotswapping [ 151 at the Carleton [ 191 University, the eFlow [4] from HP laboratories, and the Ninja [3] service composition at the University of California Berkeley, typically facilitate orchestration only, while neglecting information about the context of users and services as well. However while computing today is becoming increasingly
0-7803-8577-2/04/$20.0002004 BEE
’Context-Baser Service Composition
71
P
tion), and the other one is very generic [I. In our opinion a definition of context; has not to be bound to a particular scenario or domain, has not to be just an enumeration of some context parameters, and finally has not to be too generic. It should combine both aspects. In this paper we will introduce an instantiation and a combination of Dey’s and Schilit’s definitions as the definition of context for developing the CB-Sec architecture. This definition aims to describe the following five context parameters in a serviceoriented environments:
Applications
ada tiw a licadn behavior
-
’1
T
2
SeFeFioning dicoben. corn sition and execution
I
Physical Entities
1. Who are the people in the environment?
devices and s e ~ o r s
2. Where are these people?
Figure 1. System Overview.
3. When are these people in the environment? 4. What devices, sensors and services are in the environ-
service provisioning. An application scenario is presented in section 5. Finally,. Section 6 draws the conclusions and presents our future works.
ment? 5. When these information is recorded across a time span, we obtain a context history, which is also useful when discovering and composing services.
2. Context Definition in CB-Sec
Our Definition of Context: context is any information that can be used to dejine the situation cflan entity in a service-oriented environment. An entity can be a person, a sensol; a computing device a service or any other object that can be considered relevant to the interaction between a user and a service. From this definition we based our context along the following axes:
Where a general definition of context from a dictionary is ”the part of a text or statement that surrounds a particular word or passage and determines its meaning”. Many authors argue that this definition cannot be used as it is in the computing world; and must be refined and precised. This leads to a large number of definitions but none so far has been adopted as a formal definition to be used in all contextaware systems. In this section we will present the two famous definitions of context and introduce our own definition. Definition 1: Bill Schilit and Marvin Theimer [20] define context in mobile distributed computing systems as ”the location of the usel; the identity ofpeople and physical objects that are nearby the usel; and the states of devices that the user interact with ”. While this definition is useful for the applications developed by Schilit et al. in the mobile computing world, it defines context by example, and thus is difficult to generalize in order to cover other types of contexts that are useful in other application domains. Anind Dey argue that a definition of context cannot be based just of the enumeration of some information depending on the application domain. In [7] [8] Anind Dey provides a different definition of context: Definition 2: ”context is any infomiation that can be used to characterize the situation of an entity. An entity can be a person, or an object that is considered relevant to the interaction between a user and an application, including the user and the application themselves”. From the presented definitions we notice that the first one lacks generality (i.e. just enumerations of context informa-
1. The identity of people including their roles, preferences, permissions, social situations, etc.
2. The location of people, devices and services. 3. Time of a day, week, month, etc. 4. Device’s and service’s capabilities, devices’ and ser-
vices’ requirements, constraints, etc. 5. Context history.
It is worth emphasizing that the context parameters we considered represent only a slice of all possible elements that make up a full definition of context, but nonetheless potentially useful for our system.
3. Operating of the Context-Aware Approach The operating of the context-awareness approach in CBS e c consists of three main steps: context acquisition, classification and representation. This is similar to what Chen et al. denote in [6] by sensing the contextual information, refining them into a context knowledge, and finally reasoning about this knowledge [18].
72
4. Stages of Service Provisioning in CB-Sec
3.1. Context Acquisition and Classification: The Context Gatherer
In this section we present the different stages for service provisioning. Before introducing the different modules responsible for service provisioning, we first present a brief definition of what are Web services and services composition, and introduce how are services described in CB-Sec in order to take into account context-information.
The Context Gatherer is responsible for gathering contextual information from software and hardware sensors, checking the persistence of the gathered information, and finally making it uniformly available to the rest of the system. The Context Gatherer must also be able to provide the system with context informationby gathering and aggregating more than one sensor data if necessary. All hardware and software sensors are attached to the Context Gatherer. The context information consists of all data that each specialized sensor may acquire according to the actual configuration of the environment. In order to be used, this information need to be structured and classified according to a specific conceptual model that should reflect the application model of the context (e.g. both the GPS, the network-based locator and a digital camera provide location information). The Context Gatherer has a further function which is the possibility to create other sensors which rely on the aggregation of two or more existing sensor data. The aggregate functions are a clearly defined set of methods such as SUM, AVG, etc. The Context Gatherer simply executes these functions, it does not have real information about the meaning of the aggregations. We propose to use an XML schema to classify and aggregate (if necessary) the contextual information. The XML schema, in fact, specifies the class type of every context data, and the relations between contexts. Fig. 2 illustrates a possible example, the proposed XML schema answers the following question: 0
Where to listen to get the data from the sensors.
0
Which data to aggregate.
0
How to aggregate data.
0
How to connect to the context data base.
4.1. Services and Services Composition Regardless of its type (i.e., Web or mobile), a service consists of operations to perform according to a certain input and a certain chronology. Potential users have to know how to request a service for execution, but neither how to operate the service nor how the service operates or is operated. In this section we define the two types of services Web and mobile services, and service composition respectively. Web services W3C has defined a Web service as a sojjware system identiJied by a URI, whose public interfaces and bindings are defined and described using XML. Its def inition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its dejnition, using X M L based messages conveyed by internet protocols [2] [9]. Mobile Services Maamar et al. introduce the concept of M-services (M for Mobile) as a specific type of Web services [16]. Two definitions are suggested. The weak definition is to remotely trigger a Web service from a mobile device for execution. The strong definition is to transfer a Web service from its hosting site to a mobile device where its execution takes place. In this case, the Web service is an Mservice that is: (i) transportable through wireless networks; (ii) composable with other M-services; (iii) adaptable according to the computing features of mobile devices; and finally (iv) runnable on mobile devices. Service CompositionA composition approach connects services together in order to devise composite services. The connection of services implements a logic that depends on the application domain and on the control flow, of the case for which the composite service is being developed. A simple example of a composite service can be the travel planning composite service that is composed of hotel booking, flight search, ticketing service, attraction search ...etc.
3.2. Context Representation: The Context Data Base It is responsible for storing contextual information over time. The context data base is the component that provides the context history. It works also as a knowledge base in the sense that it can answer queries making complex automated reasoning on the concepts it knows. In the current implementation, the context database is represented as a collection of assertions. That allows the application to describe context-awarenessin a generic way according with its specific model of the context [18] [17].
4.2. CB-Sec Service Description There are three main parts in a service description: 1) the Attributes, 2 ) the Capsule, and 3) the Constraints and Requirements. Another optional part called the Context Function is shipped with the service description and is used in order to select the best service offers when more than one service is returned by the discovery process.
73
................................................................................................................................................... ?Cll~:~r~*3~:*lan
1 j
i j
j i '
1
i
-.................................................................................... - -. - _ - - - __
i
:
I
I
I
: IU1.lUar
:>.
...........
........................................................................................................................................
.:
Gf~m~Ud*rM,XML%ySchnrrEdmr
Figure 2. Illustration of the XML schema used to classify context information.
of such a function may be the load attribute that can determine which printer is less loaded, i.e. which printer service is better in the current context. The same principle was introduced in by C. Lee and A. Hela1 in [141 in the context of the JINI [ 1J framework.
Attributes* : include the characteristics of a service: i.e. information regarding the operations that can be invoked in a service and their respective input and output parameters. Although one service can have multiple operations, in our example we consider one operation for clarity reasons.
A description of an accommodation booking Web service is shown in Fig. 3. In this example the service accepts three input parameters and returns the accommodation details as an XML document. The service charges 5 electronic coins each time for the execution. To execute this service, a resource must have more than 20 Kbytes of free disk space and at least 128 Kbytes of free memory. Furthermore, the service can be executed under Palm OS or Linux environments. Finally the Context Function (COIF)identifies the sensitivity of the service to context-parameters, in our example and for simplicity reasons we take a simple IP check function that permits to check weather the provider of a given service is on-line or off-line, in the time the request is generated, Fig. 4.
Capsule" : gives information on where the service is located, how it can be accessed, the invocation protocol(s), the types(s) and the port(s). Constraints and Requirements* : this part wraps all the conditions of use of the service. It is necessary when different providers offer the same service, with different constraints regarding the input and/or output parameters. The Requirements include execution needs of the service towards the available resources. For example, a service requires at least 16 megabytes of free memory to be executed. Context Function : this function represents the sensitivity of the service to the context. Unlike the previous three parts, this part is optional and its value is not known in advance, it is calculated in run time if the interface matching process returns back more than one service, in order to help with better service selection. Example
4.3. Precomposition Stage: Service Discovery Module The approach adopted in this paper, involves mobile devices that not only consume web services, but also publish
74
Attributes*
service-identifier nun instances type isMobile description provider-identifier input-parameters output-parameters price
"pai-accl21"; ; number of allowed instances "W-service";//Web or M-service " N O " ;//whether the service can move to other places "accommodation booking service";
3
=
I'
P A 1 I' ;
{Int Num of Persons, Int Num of Days, String Contact Name}; {XML Doc accommodation Details); 5; //e-coins per invocation
Capsule*
location protocol port Constraints
"pai-acc.diuf.com.ch"; https; 80; &
Requirements*
diskfree memoryfree OPSYS
,
Context Function
//represents the sensitivity of the service to context
COF
20; //Kbytes 128; //Kbytes "Palm OS, Linux"
>=
ping iiufps3l.unifr.ch
Figure 3. Example of a CB-Sec service description.
4.4. CompositionStage: Service CompositionModule
their data through web services. Thus an important component is the Brokering Agent, whose function is to match and recommend appropriate services among a possibly large set of service instances available in the environment, taking benefits from context-information. Clients request services in a context describing characteristics, and time of the requested service [ 101. Furthermore context contains information about the client and its preferences. The Brokering Agent first job is to extract the contextual information form the Context-Data Base, then using these information it tries to discover the basic services against the ones registered on its vicinity (using the location attribute). It first matches the user's query as well as the user's device capabilities into the nearby service registry and progressively increases its search radius [5] to discover all the different services necessary for the composition. The Brokering Agent has to figure out other-end requirement, i.e. device capabilities anticipated by service implementations. It can get such information from the constraints field shipped with the service' description. The previous step produces a set of candidate services, the Brokering Agent is then responsible for iterating through this set, and for picking the best offers according to the current context and the constraints set by the service providers. In other words services are incrementally filtered and ranked [14] according to the evaluation of the context functions, to ensure that clients are given the best service instances [13].
This module is responsible for carrying out the process of managing the discovery of services to yield a composite service. Indeed when a client requests a service, it may be necessary to compose a complex service out of the registered basic services. The current implementation of our architecture uses UCM's social laws (UCM stands from Ubiquitous Coordination Model) to decompose complex service requests into basic services, and to determine the process model of execution. The UCM model is an OWL-based instantiation of the unified coordination model XCM presented in [21] [22]. UCM is viewed as an organizational domain composed by autonomous entities. An entity is defined by its structure obtained by a recursive composition of entities. Inside this domain, entities interact with each other through communication endpoints called ports, that define a set of actions. Social-laws are defined to restrict the composition of basic communication actions. Web services are modelled as atomic entities, whose structure cannot be decomposed, Inputs and and Outputs of a service correspond to ports that are coupled with the entities. The composition of two basic services corresponds to the port matching operation. Port matching operation, assembling and disassembling logic of ports are driven by the social-laws. The social laws are tightly coupled with the environment. In the OWL-based UCM the HusLaw object property ex-
75
4.5. Postcomposition Stage: Module
presses the fact that an environment e has social law L attached to its organisation; the LuwOf object property defined as inversed HusLaw object property expressing that law L is related to environment e, which means that in order to interact together, the components of the environment e must exchange messages that are on conformity with the law L. Therefore, L Message is defined as an object property, which relates the M messages that are on conformity with L law, Fig 5 describes a partial UCM code of this concern [22].
Service Execution
This module is responsible for carrying out the execution of the composite service. Prior to this the Service Composition module provides a feasible order in which these services can be executed. Mainly two types of execution exist according to the nature of the service, which can be either a Web service (W-service) or a mobile service (M-service). For M-services2 execution is always local to the device of execution since the service itself has been transported to the device [16]. However for W-services the execution can be remote or local. In the remote invocation the client sends remotely a request to a provider asking the execution of a service. The execution takes place in the provider platform. In local invocation the client asks remotely to transfer a copy of the service to its device. After being transferred, the execution takes place in the client site [ 161. Inside the Service Execution Module a Cache is used whose function is to store expensive (time-consuming) information to create, so it can be automatically reused. For example if a composite service requires complex calculations, caching may save processing time, speed up the response rate for the client and lessening the burden on the service server's CPU. In other words the Cache Engine stores the resulting process model of a query as well as its context, and reuses it for other clients that supply the same query with the same parameters. Caching is also useful when the same client supplies the same query in other contexts; first the cache is checked if the same composite service would satisfy the new query needs (according to the new context), if not the composite service is decomposed, services that do not meet the new requirements are composed-out, and a new discoverylcomposition process is triggered for the composed-out services. The new discovered services are composed-in with the cached ones. Finally the resulting composite-service is recommended to the user, and a copy of the process model is kept in cache as well as. its context. Another advantage of the Cache is to provide the system with a fault tolerance mechanism. Maintaining stable communication channels during the whole discovery/composition and execution process may not be possible in a highly dynamic and pervasive environment. For this means breakpoints are introduced in the execution process, and the broker for a particular request sends back the results after a sub-task is completed, these results are cached. When a failure occurs instead of making the BA initiating a new discoverykomposition request, it reconstructs only the query that is still unsolved [ 111.
Figure 4. Selection of the best service after evaluation of the context function.
The composite service is modelled as a CompoundEntiry. Fig 6 shows the OWL portion of code that represents an UCM compound entity corresponding to a composite service. After the discovery step, the Service Composition Module, further refines the set of discovered basic services using the remaining context parameters that are relevant for the composition rather than for the discovery. Example of such a parameter can be the user preferences that are applicable to the overall composite service e.g. a person planning for her summer vacation wont spend more than 3000USD for the whole vacation composite service i.e. (hotel service, car rental service, attractions, plane tickets ...etc), another example may be the permission profile set by the user (e.g. when in class between 8h am and 12h am 1 do not want to receive SMS messages). The composite service that satisfies all the user preferences is chosen and the corresponding capsules (i.e. information about the services, addresses, ports, and invocation protocols) are sent to the Service Execution Module. In the mean time a copy of the process model together with its context is kept in cache. The logic of composition is provided by the UCM coordination model, indeed UCM is based on the OWL description language.
*In our framework the strong definition of M-services is used.
76
cow1:equivalentClass rcf:resource="#Con?poiindEncity"/> c/owl:Class> cowl :Class rdf : ID="Message'
Figure 5. An UCM social-law example.
5. Proof of Concept Implementation: The
quest services from their local LWSR or trigger a service discovery process from the nearby LWSR hosted in other devices. Users may also trigger a service composition process to compose services out of the registered ones. Various multimedia means are used to keep users as much comfortable as possible, for example a non-visual interfaces is offered to blind persons to facilitate the interaction with the system. Tow mechanisms for service provisioning are implemented: the automatic and request-based provisioning. In the automatic provisioning services are automatically triggered and the result is sent to the user without request, for example the library reminder service is triggered when the deadline is approaching, or the restaurant menu is sent to the user when it's lunch time and the user is not in class. Request-based services correspond to the answer of the user query, for example the user explicitly request the room occupancy service to check if she can plan a meeting there.
Context-Based Smart Reminder A proof-of-concept implementation of our approach for the service discovery and composition is underway in our lab. This section gives an overview of the smart reminder project, it is worth emphasizing that the project is still under development.
5.1. General Description The aim of this project is to assist students, and university staff with a portable interface that provides them with information of interest inside a university campus. Examples of such information can be: directions, exam' results, library reminders, restaurants menu, room occupancy, and other suggestions upon their context. The context information that are used are: location, time, role (student, professor, assistant) and preferences (langauge, ...etc). The system is capable to detect user's location and communicate through a wireless infrastructure with services providers around the area so as to gather data and information requested by the user. For this purpose portable devices Palm Pilots, and Mobile Phones are running a lightweight service registries (LWSR) to offer services. Users may re-
The prototype uses Sun's Java Web Services Developer Pack 1.2 (Java WSDP 1.2), which is an integrated toolkit for building, testing, and deploying Web Services (http://java.sun.codjwsdp). Java WSDP comes with an implementation of an UDDI registry, which we used in our implementation.
77
cow1:Class rdf:ID="CompoundEntity"> cowl:Restriction> cow1:OnProperty rdf:resource="#HasComponents"/> l c/owl:Class>
Figure 6. Example of an OWL-based UCM compound entity.
5.2. Implementation Details
In the current implementation the context database in stored in a central data base server.
As a firs step, a number of Web services are developed and registered with different registries, for the first implementation mainly a number of services are used:
2. The user's location: the 'Ystem is designed to in both indoors and outdoors environments. We have experimented with RF-based systems that infer the location of a user or a device based on the signal strength of received RF signals of IEEE 802.1l b wireless LAN frames.
1. Babelfish translator service: this service was used to
translate messages into the user's language. 2 . Globalweather Service: Gives detailed, strong-typed and time-stamped weather information and conditions around the world. http://www.capescience.com/webservices/globalweather/.
3. Theaters Service: this service returns the list of movies that will be played in Fribourg, http://fribourg.cinemas.ch/. 4. DotNetSMS:
messages
used to
to send mobile
SMS phones.
http://smsserver.dotnetisp.com/servicesms.asmx.
3. The time was directly taken form the clock of the client device.
4. The services context was evaluated from: the context functions of each service. For the moment and as a first example we are using two context functions: the PING function in order to select the best service in terms of response time. And the Queuefunction in order to select the least loaded restaurant, theater...etc. Fig. 9 shows an example of composition of two services the babelfish translation service and the room occupancy service. Fig. 8 shows the result of the composition from the client side. This project represents a small set of the CB-Sec framework nevertheless demonstrates its benefits with respect to the contextualization of services discovery and composition.
5 . Room occupancy Service: it gives the list of the planned meetings in a room.
6. Text-To-Speech service: it synthesizes a text message as voice, and plays the message over the vocal (non visual) interface. 7. Text-To-Display: it displays messages on a text format.
6. Conclusion and Future Work
The user's and service's context is gathered from different supports:
Recently there have been several research initiatives in the field of Web services description, discovery and composition. However, none of these initiatives have attempted including the notion of context in the composition of Web services. Besides the traditional selection criteria that are used in a similar process (e.g., execution cost and time), we have shown that context has a major effect on the Web services in general and their composition in particular. In this paper we have presented a generic approach that overcomes
1. The user's personal information such as (name, age, personal profile, preferences, permissions ...etc), is stored in a specialized card tke Campus Card. A dedicated card reader is installed in Campus, the reader retrieves the user's personal information and adds a new entry in the Context Data Base. We have also implemented a web interface that can be used to modify user' profiles or add new users to the system 7
78
Figure 9. Illustration of the composition of the room occupancy and the babelfish translation services from the server side.
Figure 7. The interface to handel user’ profile.
Schedule ofTuesday May4.2004
this shortcoming,by including context in the different steps of service provisioning. Our ongoing and future work covers three research thrusts. The first one concerns the extension of the system with a formal definition of context for services. We also intend to exploit context-awarenessin order to improve existing Web services standards, such as WSDL and UDDI. The second research thrust consists of composite service adaptability by allowing the broker agent to do some runtime modifications to these services by for instance adding new component services, removing certain component services, or replacing certain component services according to new contexts. Finally in order to have additional validations of the model two projects based on CB-Sec are under the way, emphasizing the use of the framework. One is a diploma project that explores the use of CB-Sec in a library reminder system. The other is a smart market cart.
I
7 Acknowledgment The authors would like to thank the referees for their valuable comments and suggestions of improvements. This work was in part supported by Swiss National Science Foundation Project N. 2000-065301 .
Figure 8. Result of the composition from the client side.
References [ I ] The
Community
Resource
for
Jini
Technology.
http://www.jini.org/, accessed, May 2004. 121 The World Wide Web Consortium. hrtp:/~,M:M!M..~.org/,accessed May 2004.
79
Conference on Autonomous Agents and Multi-Agent Systems (AAMAS’OZ),Bologna, Itlay, July 2002. 1171 S . Maffioletti, S. Kouadri. A Holistic Approach for Pervasive Computing Environments. In the proceedings of the 2004 Communication Networks and Distributed Systems Modeling and Simulation Conference, (CNDS2004),San Diego, Califomia, USA, January 2004. [I81 S. Maffioletti, S . Kouadri. Automatic Resource and Service Management for Ubiquitous Computing Environments. Proceedings of The 2004 Workshop on Middleware Support for Pervasive Computing, (Peware ’04) held in conjunction with The Second IEEE Annual Conference on Pervasive Computing and Communications, Orlando, Florida, USA, March 2004. [I91 D. Mennie, B. Pagurek. An Architecture to Support Dynamic Composition of Service Components. Systems and Computing Engineering, Carleton UniversiQ, Canada, 2002. [20] B. Schilit, N. Adams, and R. Want. Context-Aware Computing Applications. In Proceedings of The IEEE Workshopoil Mobile Computing Systems and Applications, Santa Cruz, California, USA, 1994. [21] A. Tafat, B. M. Courant and B. Hirsbrunner. A Coordination Model for Ubiquitous Computing. I n Proceedings of The 2003 International Conference on Parallel and Distributed Pimessing Techniques and Applications PDPTA’2003, Las Vegs,Nevada, USA, June 2003. 1221 A. Tafat, B. M. Courant and B. Hirsbrunner. A Generic Coordination Model for Pervasive Computing Based on Semantic Web Languages . In Proceedings of The Ninth International Conference on Applications of Natural Language to Ii@-nlation Systems NLDB’2004, Manchesteq UK, June 2004.
[3] UC Berkeley Computer Science Division. The Ninja Project Overview. http:/hiinja.cs.berkeleyedu/pubs/pubs.html, accessed, May 2004. [4] E Casati, S . Lnicki and M. Shan. Adaptive and Dynamic Service Composition in eFlow. Technical Report, HPL200039, Software Technology Laboratory, Palo Alto, USA, 2000. [5] D. Chakraborty, F. Perich. A Reactive Service Composition Architecture for Pervasive Computing Environments. In proceedings of the seventh Personal Wireless Conimunications Conference P WC’2002, Singapore, October 2002. [6] G. Chen, D. Kotz. A Survey of Context-Aware Mobile Computing Research. Technical Report, Dartniouth Computer Science, TR 2000-381, 2000,2000. [ 71 A. K. Dey and G . D. Abowd. Towards a Better Understanding of Context and Context-Awareness. In Proceedings of The Workshop on the What, Who, Where, When, and How of Context-Awareness held in conjuction with CHI’2000, The Hague, The Netherlands, 2000. 181 A. K. Dey, G . D. Abowd, and D. Salber. A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications. Human-Computer Interaction Journal, Special Issue on Context-Aware Computing, 16(1), 2001. [SI T. Jin and S . Goschnick. Utilizing Web Services in an Agent Based Transaction Model (abt). The Ist International Workshop on Web Services and Agent-based Engineering (WSABE’2003) held in conjunction with The 2nd International Joint Conference on Autonontous Agents and Multi-Agent Systems, Melbourne, Australia, July 2003. [IO] M. Khedr, A. Karmouch. Agent-Based Context-Aware Ad hoc Communication. In Proceedings of The 2002 EEWIFIP MATA’O2, LCNS 2521, Barcelona, October 2002. [ 1 I] S. Kouadri, B. Hirsbrunner. A Context-Based Services Discovery and Composition Framework for Wireless Environments. In the proceedings of the IASTED International Corlferenceon wireless arid Optical Networks, (WOC2003), ACTA Press, Alberta, Canada, July 2003. [ 121 S . Kouadri, B. Hirsbrunner. Towards a Context-Based Service Composition Framework. Intenintional Corlference on Web Services (ICWS’2003), CSREA Press, L a s Vegas, Nevada, USA, June 2003. 1131 S. Kouadri, B. Hirsbrunner. Using Context Information for Service Discovery and Composition. In proceedings of the jijth Internatiorml Co?lference on hlfonnatiori Integration and Web-based Applications and Services IIWAS’2003, Jakarta, Indonesia, September 2003. [ 141 C. Lee and A. Helal. Context Attributes An Approach to Enable Context-awareness for Service Discovery. In proceedings of third IEEWIPSJ Symposium on Applications and the Intrnet, Orlando, Forida, USA, January 2003. [ 151 B. Limthanmaphon, Y. Zhang. Web Service Composition with Case-Based Reasoning. Klaus-Dieter Eds: Schewe and Xiaofang Zhou Database Technologies, January 2003. 1161 Z. Maamar, W. Mansoor and Q. H. Mahmoud. Towards a Composition Framework for E/M Services. Proceedings of UbiquitousAgents on Embedded, Wearable,and Mobile Devices, held in conjunction with the First hteniational Joint
80
