Context-based personalization of web services composition and ...

Context-based Personalization of Web Services Composition and Provisioning Zakaria Maamar

Ghazi AlKhatib

Soraya Kouadri Mostéfaoui

Zayed University, U.A.E

Qatar College of Technology, Qatar

Fribourg University, Switzerland

[email protected]

[email protected]

[email protected]

Mohammed B. Lahkim and Wathiq Mansoor Zayed University, U.A.E [email protected]/[email protected]

Abstract This paper presents an approach that aims at personalizing Web services composition and provisioning using context. Composition addresses the situation of a user’s request that cannot be satisfied by any available service, and thus requires the combination of several Web services. Provisioning focuses on the deployment of Web services according to users’ preferences. A Web service is an accessible application that other applications and humans can discover and trigger. Context is the information that characterizes the interactions between humans, applications, and the surrounding environment. Web services are subject to personalization if there is a need of accommodating users’ preferences during service performance and outcome delivery. To be able to track personalization in terms of what happened, what is happening, and what might happen three types of context are devised, and they are referred to as user-, Web service-, and resource-context. Keywords. Web Service, Personalization, Context.

1

Introduction

A Web service is an accessible application that other applications and humans can discover and trigger to satisfy multiple needs [15]. One of the major strengths of Web services (also called services in the rest of this paper) is their capacity to be composed into high-level business processes known as composite services. In general, composing services rather than accessing a single service is essential and caters better benefits to users. Composition addresses the situation of a user’s request that cannot be satisfied by any available service, whereas a composite service obtained by combining a set of available services might be used [3]. Because users’ expectations constantly change, it is extremely important to include their preferences in the composition and provisioning of Web services. Indeed, some users would like receiving answers to their personal requests di-

Proceedings of the 30th EUROMICRO Conference (EUROMICRO’04) 1089-6503/04 $ 20.00 IEEE

rectly submitted to their home’s email instead of office’s email. Plus, some users would like having certain services, such as traffic conditions, automatically triggered once they get into their cars. These simple scenarios shed the light on the importance of personalization and its impact on adjusting applications. Personalization is of type explicit or implicit [14]. Explicit personalization calls for a direct participation of users in the adjustment process. Users clearly indicate for example the information that needs to be treated or discarded. Implicit personalization does not call for any user involvement and can be built upon learning strategies that check and track users’ habits, interests, and behaviors. Personalization is dependent on the features of the surrounding environment in which it is expected occurring. Features can be about users (e.g., stationary user, mobile user), computing resources (e.g., fixed device, mobile device), time periods (e.g., in the afternoon, in the morning), and physical locations (e.g., room, cafeteria). Being aware of the features of an environment raises the importance of having a structure for collecting, tracking, and storing these features. Context is this structure and reflects the information that characterizes the interactions between humans, applications, and the surrounding environment [5]. Web services composition and provisioning is an active area of research and development [15]. However, very little has been accomplished to date regarding their personalization using context. Several obstacles still hinder this personalization such as: (i) current Web services act as passive components rather than active components that can be embedded with context-awareness mechanisms, (ii) existing approaches for service composition (e.g., WSFL and BPEL4WS) typically facilitate orchestration only, while neglecting information about the context of users and services, and (iii) lack of support techniques for modeling and specifying the integration of personalization into Web services. In this paper, our work on personalizing Web services composition and provisioning using context is

presented. The major features of this work are as follows: • Three types of context are devised and correspond to U-context for User context, W-context for Web service context, and R-context for Resource context. • Web services engage in conversations when they are subject to personalization. The flow of exchange in conversations is context-dependent too. • Different types of policies are developed to manage the integration of personalization into Web services composition and provisioning. The use of these policies guarantees that Web services still do what they are supposed to do despite personalization. Section 2 is about the concepts that the context-based personalization approach encompasses. Section 3 presents this approach in terms of deployment and operation. Sections 4 and 5 discuss the value-added of policies and conversations to managing personalization, respectively. Section 6 outlines our future work, which is about security. Section 7 presents some related work. Section 8 concludes the paper.

2

Preliminaries

Benatallah et al. suggest the following properties of a Web service [2]: (i) independent as much as possible from specific platforms and computing paradigms; (ii) primarily developed for inter-organizational situations; and (iii) easily composable so that developing complex adapters for the needs of composition is not required. Composed of con (with) and text, context refers to the meaning that can be inferred from an adjacent text. According to Dey, context is any information that is relevant to the interactions between a user and an environment [6]. This information is about the circumstances, objects, or conditions by which the user is surrounded. Personalization is about integrating users’ preferences into the process of delivering any information-related content or outcome of service computing. Preferences are of different types and vary from content and format to time and location. For Bonett in [4], personalization involves a process of gathering user-information during interaction with the user, which is then used to deliver appropriate content and services, tailor-made to the user’s needs. The aim is to improve the user’s experience of a service. A conversation is a sequence of messages that involves two or more participants who intend to achieve a particular purpose [16]. On the one hand, a conversation succeeds because what was expected from the conversation in term of outcome has been achieved. On the other hand, a conversation fails because the conversation has faced some technical difficulties or didn’t achieve what was expected.


3

Context-based personalization

3.1

Deployment

Fig. 1 illustrates the approach that backs context-based personalization of Web services composition and provisioning. The core concept in this approach is context from which three sub-contexts are obtained: U-context, Wcontext, and R-context. Muldoon et al. define user context as an aggregation of his/her location, previous activities, and preferences [14]. We define Web service context as an aggregation of its participations in composite services, locations of execution, times of execution, and constraints during execution. We define resource context as an aggregation of its status, periods of unavailability, and capacities of meeting the execution requirements of Web services. In Fig. 1, U-context, W-context, and R-context are interrelated. Between R-context and W-context, ”execution adjustment” relationship identifies the execution constraints on a Web service (e.g., execution time, execution location, data dependency) vs. the execution capabilities of a resource (e.g., next period of availability, scheduling policy) on which the Web service will be performed. A resource has to check its status before it accepts supporting a service execution. Between U-context and W-context, ”provisioning personalization” relationship identifies the preferences of users (e.g., when and where a Web service needs to be executed, and when and where the execution’s outcome needs to be returned) vs. the capabilities of a Web service to accommodate these preferences (e.g., can a service be executed at a certain time and in a certain location). A Web service needs to check its status before it accepts satisfying a user’s needs. To this end, the Web service relies on the agreements it might have with certain resources (i.e., ”execution adjustment” relationship). Context

U-Context(s)

W-Context(s)

Provisioning personalization

to be offered

User(s)

R-Context(s)

Executiuon adjustment

WS

to be run on top

Web service(s)

Resource(s)

Legend W-context U-context

Web service context User context

R-context to extend

Resource context to be attached

Figure 1. Context-based personalization of Web services In Fig. 1, a Web service is subject to personalization be-

Table 1. Description of U-context parameters Parameter & Description Label: corresponds to the identifier of the user. Previous locations/services: keeps track of all the locations, as indicated by the user, that have indicated the execution of services (null if there are no predecessor locations). Current location/services: indicates the current location, as indicated by the user, that should indicate the execution of services. Next locations/services: indicates all the locations, as indicated by the user, that will indicate the execution of services (null if there are no next locations). Previous periods of time/services: keeps track of all the periods of time, as indicated by the user, that have indicated the execution of services (null if there are no predecessor periods of time). Current period of time/services: indicates the current time, as indicated by the user, that should indicate the execution of services. Next periods of time/services: keeps track of all the periods of time, as indicated by the user, that will indicate the execution of services (null if there are no next periods of time). Date: identifies the last time a parameter has been updated (multi-value representation).

cause of users’ preferences and subject to adjustment because of resources’ availabilities. Users and resources are two motives that make Web services change so that they accommodate preferences and consider availabilities. A personalized Web service is, also, a third motive. It may trigger the personalization of other Web services. These services are in relationship with the personalized Web service. We call this relationship causal and identifies the dependency among certain services, besides other existing types of dependency such as data and flow. For example, if a service is being personalized to meet a time preference, it is important to ensure that the preceding services are all successfully executed before the execution of this personalized service is detected. This means that the respective execution times of the Web services have to be checked and adjusted if needed.

3.2

Types and roles of context

The role of U-context is to keep track of the current status of a user and his/her preferences in terms of execution location and execution time of services. Besides the different roles that a user can fulfill, he/she is associated with different status depending on the situation in which he/she gets involved. Examples of situations are being at home, being at the gym, and even reading. Each situation has its characteristics and limitations. For instance, at home situation has mainly a social flavor, which may prevent a user to a certain extent from completing some business-related duties. The limitations could be the unavailability of the company’s confidential data from outside. Some of the parameters that might constitute U-context are (Tab. 1): label, previous locations/services, current location/services, next locations/services, previous periods of time/services, current period of time/services, next periods of time/services, and date. Previous locations and previous


periods of time parameters illustrate the Web services that were executed. Next locations and next periods of time parameters illustrate the Web services that will be executed. The role of W-context is to be aware of the current status of a Web service and its execution constraints because of users’ preferences in terms of execution time and execution location. A Web service is triggered each time it receives an invitation of participation in a composite service. Before a service accepts an invitation, it performs some checks among them (i) number of current participations vs. number of participations allowed, (ii) expected completion time of current participations, and (iii) features of the newlyreceived invitation in terms of execution time and execution location. It happens that a Web service turns down an invitation of participation because of (i) period of unavailability for some maintenance work, (ii) resource unavailability, or (iii) overloaded status. Some of the parameters that might constitute W-context are (not detailed due to lack of space): label, status per participation, previous services per participation, next services per participation, regular actions, start time per participation (requested and effective), location per participation (requested and effective), reasons of failure, corrective actions, and date. It should be noted that per participation stands for each composite service in which a Web service participates (see [11] for how a Web service can participate in several composite services). In W-context, time-requested and location-requested parameters are user-dependent, while time-effective and location-effective parameters are execution-dependent (i.e., when and where the execution has really happened). To ensure that the preferences of a user have been integrated into the deployment of a component service, the values of time-requested and location-requested param-

User

Web service

Other Web services

Resource

Identification + preferences

W-Context Assessment

no

yes/Identification

R-Context Assessment no

no

R-Context Notification/yes

Update

W-Context Update Notification (causal relationships)

W-Context Assessment no

no

W-Context Notification/yes

Update

W-Context Update Notification

U-Context

Legend

Update

Interaction

Selection

Trigger

Stop

Action

Figure 2. Interactions between participants of personalized Web services

eters should be equal to the values of time-effective and location-effective parameters. Any discrepancy between the parameters of type requested and type effective indicates that the user’s adjustment in terms of execution location or execution time of a Web service has not been correctly handled. The user needs to be informed about the discrepancy so he/she (or a third party acting on the user’s behalf) could update the relevant parameters of U-context. These parameters are previous locations/services and previous periods of time/services. In addition, the Web service needs to check the reasons of the discrepancy between what was requested and what has effectively happened. When it comes to the preference of type location, we recall that users have to explicitly announce their location1 . Some of the parameters that might constitute R-context is to keep track of the current status of a resource. Resources are needed each time a composite service is devised and thus, requires the performance of its component Web services on resources. Before a resource accepts additional requests of execution and schedules the request of a Web service, it checks (i) number of current executions vs. the number of executions allowed, (ii) approximate completion time of current executions, and (iii) execution time of the newly-received request. It happens that a resource rejects a request of executing a Web service because of (i) period of unavailability due to some upgrade work or (ii) overloaded 1 While a manual identification of the current locations of users has some limitations, this identification allows a better handling of the privacy issue since users only reveal the locations they wish to be known.


status. The parameters of R-context are (not detailed because of the lack of space): label, previous periods of time/services, current period of time/services, next periods of time/services, previous locations/services, current location/services, next locations/services, and date.

3.3

Operation

Fig. 2 illustrates the interactions occurring in the approach of context-based personalization of Web services composition and provisioning. When a user selects a Web service from a community of Web services (Boualem et al. explain in [2] what a community is), he, in fact, triggers the personalization of the service according to his/her time or location preferences. Time preference is broken down into two sub-preferences: (i) when the execution of the service should start, and (ii) when the outcome of the execution should be returned to the user. It occurs that execution time and delivery time are equal if the time that the execution lasts is negligible. The location preference is also broken down into two sub-preferences: (i) where the execution of the service should occur, and (ii) where the outcome of the execution should be returned to the user. It occurs that execution location and delivery location are the same. Once the user’s preferences are submitted to the Web service, this one performs some checks to ensure that the dates and locations, as indicated by the user, are valid and no conflicts may happen during deployment. Prior to identifying the resources on which it will be executed, the Web

service checks its W-context with regard to the number of the current participations vs. the number of participations allowed as well as the next period of unavailability. After a positive check of the W-context, the identification of a resource by the Web service can then be triggered. It is assumed that a mechanism supporting the identification of resources is available (e.g., broker-based). A resource needs mainly to accommodate two things: (i) the start time of a service execution, and (ii) the time the execution lasts in order to consider the user-indicated delivery time of this execution outcome. For this purpose, the resource checks its R-context with regard to the next periods of time that will feature the execution of Web services as well as the next period of maintenance. After a positive check, the resource notifies the service, which itself notifies the user. The result of notifying the user is the update of the following parameters: (i) next locations/services and next periods of time/services of U-context; (ii) next services per participation, start time per participation requested, and location per participation requested of W-context, and (iii) next periods of time/services and next locations/services of R-context. The update of the parameters of contexts, mainly those that correspond to the forthcoming actions to take in the future, is a good indication of the assessment that occurs. For instance, this assessment could be about (i) which Web services are involved and in which composite services, (ii) which resources are considered, and (iii) which locations or periods of time will have some Web services executed. This type of assessment allows predicting the situations that will happen and preparing the relevant corrective plans in case of exceptions. In Fig. 2, before the personalized Web service notifies the user about the possible handling of his/her time or location preferences, an additional personalization process is triggered. This process consists of adjusting the Web services that are linked through the causal relationship with the Web service that has just been personalized (Section 3.1). The aforementioned description also applies to these extra Web services that first, assess their current status through their respective W-contexts and second, search for the resources on which they will be executed. To keep Fig. 2 clean, the interactions that the new personalized Web services undertake searching for the resources are not represented. Once all the Web services are personalized, a final notification is sent to the user about the near deployment of the Web service he/she initially requested.

4

Policies for personalization management

In Section 1, we mentioned the use of policies for managing the integration of personalization into Web services composition and provisioning. Our use of policies aims at specifying what, when, and where to track, and how to carry out the tracking. The value-added of using policies


for managing systems has been reported in different works. In [12], Maamar et al. employed policies for the dynamic management of multiple UDDI registries in a wireless environment of Web services. Three types of policies were developed: provider, user, and UDDI registry. For example, a UDDI registry-related policy defines for a component whether to accept announcements on Web services and from which sources. Policies are also used in conversations when it comes to regulating the information exchange between participants and managing various aspects related to conversations such as status changes, admissible turns, conflict resolution, and time-outs. Because of users’ preferences and resources’ availabilities, a service has to be adjusted so that it can accommodate these preferences and consider these availabilities. To ensure that a Web service adjustment occurs in an efficient way, we devised three types of policies (Web services’ owners are in charge of developing the policies). Consistency policy checks the status of a Web service after being personalized. Feasibility policy checks if a personalized Web service finds a resource on which it will be executed according to the constraints of time and location. Finally, inspection policy ensures that a personalized Web service is being deployed according to the adjusted specification. Consistency policy guarantees that a Web service still does what it is supposed to do after personalization. A personalization might result in altering the specification of a service when it comes for instance to the list of regular events that trigger the service. Indeed, time- and locationrelated parameters are new events that need to be added to this list. Moreover, because of QoS-related parameters (e.g., availability, response time) that can feature a Web service [13], it is important to verify that these QoS parameters did not change and are still satisfied despite the personalization. For illustration, because a user would like starting a service execution at 2pm, which corresponds to the peaktime period of receiving requests, the response time QoS of this service may not be satisfied. Feasibility policy guarantees that an appropriate resource is always identified for the execution of a Web service. Because services have different requirements (e.g., period of demands, period of deliveries) and resources have different constraints (e.g., period of availabilities, maximum capacity), an agreement has to be reached between what services need in terms of resources and what resources have in terms of capabilities. Inspection policy is a means by which various aspects are considered such as what to track (time, location, etc.), who did ask to track (user, service itself, or both), when to track (continuously, intermittently), when and how to update the different arguments of the different contexts, and how to react if a discrepancy is noticed between what was requested and what has effectively happened. Tracking en-

Re-formulation

/Message not validated or not understood

C-context

C-context C-context

S: Preparation Service do/ devise message

R: Reception Resource

: Transmission do/ transmit message (S,R)

/Message devised

Resource needed

/Message submitted

Resource needed

W-context

do/ parse message check message analyze content R-context

Service C-context

C-context C-context

R: Reception Service do/ parse message check message analyze content

Resource

S: Preparation Resource

: Transmission do/ /Message submitted transmit message (S,R) Resource

info.

/Message not validated or not understood

/Message devised do/ devise message

Resource info.

Re-formulation

Figure 3. State chart diagram of the conversation policies of personalized service/resource conversation session

ables detecting contract violations between Web services and resources, measuring performance, and predicting exceptions. The inspection policy is related to the parameters of type ”requested” and ”effectively” of the W-context of a Web service. This policy ensures that the preferences of users are properly handled. If not, the reasons have to be determined, assessed, and reported. One of the reasons could be the lack of appropriate resources on which the personalized service needs to be executed.

5

Conversations during personalization

In this section, we aim at discussing the rationale of integrating conversations into the personalization of Web services and the value-added that conversations bring to Web services composition and provisioning. Fig. 2 has shown multiple interactions, which involve users, Web services subject to personalization, and resources. In the following, an outline is presented on how certain of these interactions are leveraged to the level of conversations. Two things need to be highlighted at this stage of the paper: (i) in addition to the respective contexts of users, Web services, and resources, an additional type of context is deemed appropriate at the conversation level, and (ii) in addition to the consistency, feasibility, and inspection policies that regulate the personalization, a fourth type of policy is also deemed appropriate at the conversation level. We decompose a conversation into two parts: static and dynamic. The static part is about the format of a conversation in terms of parameters and their valid values. Examples of parameters are from, to, in-response-to, content, and context. In conversations, context is used first as a reference to the progress of conversations, and second as a tracking


mechanism of this progress. The progress of a conversation is assessed according to the active state that the conversation takes. We note that a series of states, which work towards reaching the same objective, are aggregated into a common session. Multiple types of conversation sessions exist such as those between users and Web services, and those between Web services and resources. While this is beyond this paper’s scope, we assume that an ontology for content representation and exchange exists during conversations. The dynamic part of a conversation is about the evolution happening in a conversation session and is specified with conversation policies. A conversation shifts from one state/session to another state/session because some events have occurred, some messages are received, or some actions are performed. Conversation policies specify various aspects such as admissible turns, state/session changes, timeout cases, message-format validity, and corrective actions in case of unsuccessful conversations. In this paper, conversation policies are specified using state chart diagrams [7], that are first upgraded with the following details: • Name of states is annotated either with label S for sender or label R for receiver. If there is no annotation next to a state’s name, this means that the state identifies a third party that is neither a sender nor a receiver. The third party is the communication middleware. • Name of transitions is annotated with activation condition and content of conversation. This content is referred to as Conversation Object (CO). • Actions of states implement the information that a conversation object conveys.

• A complete state chart diagram corresponds to the conversation policies that specify a conversation session. Currently three types of conversation session are identified: (user/service), (personalized service/resource), and (personalized service/service). For illustration purposes, we only describe the second type of conversation session. In this session, the objective is to identify the resource on which a personalized Web service will be performed (Fig. 3). Depending on the current commitments of a resource towards other personalized services, the personalized service may need to carry out some adjustment so that it can consider the resource’s commitments. Once a Web service has been personalized, the appropriate parameters of its respective W-context are updated (start time per participation requested and location per participation requested). Next, the Web service recently personalized initiates a conversation with one of the available resources (it is assumed that the resources with whom a Web service converses are known). This is illustrated with the state (S:preparation service) in Fig. 3. Once the message is devised, it is sent to the resource as the state (R:reception - resource) shows. Before that, the conversation takes the state (:transmission), which consists of transferring the message from the service to the resource. Once the message is received, the resource parses it and analyzes its content. The message is sent back to the sender in case it is not valid, otherwise it makes the resource takes appropriate actions. The resource checks its status based on its respective R-context and particularly current period of time/services and next period of time/services parameters. Finally, the resource returns information to the service about the resource availability. This feedback is also conducted through conversation as the following three states show (S:preparation - resource), (:transmission), and (R:reception - service).

6

Future work - security context

In the introduction of this paper, the rationale and valueadded of U-, W-, and R-contexts to Web services personalization are discussed. As part of our future work, the role of Security context (S-context) and the security-related concerns are discussed. According to [9], context-based security is about adapting the security strategy depending on a set of relevant information that is collected from the dynamic environment. While there is no disagreement on this definition, it would be more appropriate to expand. The aim is to consider a context-based security as a means for tracking all the concerns and threats that affect the security in a certain context, which permits the deployment of appropriate security mechanisms while relying on previous security contexts. In previous works [10], Maamar et al. argued that because Web services require resources on which they are executed, it is important to ensure that neither the services


misuse the resources nor the resources alter the integrity of the services. To deal with the first case, a security strategy was developed and consists of (i) control access mechanisms associated with services, and (ii) a database for storing the malicious patterns that threat resources. In the Web services personalization project that is presented in this paper, the same security strategy will be adopted. S-context is an implementation of ”execution adjustment” relationship between Web services and resources as Fig. 1 depicts. Some of the elements that could be identified through the use of the security context are: (i) regular security actions such as identification and encryption/decryption; (ii) types of violation to the security that have happened, and (iii) corrective security actions in case of any attempt to misuse a resource.

7

Related Work

Web services are a very active area of research and development [15]. However, to our knowledge none of the research projects have aimed at personalizing services using context. To cope with this lack of related work, we present in the following some of the works that have inspired us in shaping the context-based personalization approach discussed in this paper. In [8], Hegering et al. present a strategy that homogenizes the notion of context by building categories. Three categories of context are suggested: device, environment, and user. The three categories have a major overlapping with the types of context that Fig. 1 encompasses. Independently of the user context, the device context category corresponds to the resource context, and the environment context corresponds to the Web service context. In [17], Zuidweg et. al. use the W3C’s Platform for Privacy Preferences (P3P) standard in a Web service-based context-aware application. The intention of P3P is to automatically negotiate on a Web site’s privacy practice. Initially, a user must define his/her privacy preferences and store them in a machine-readable format such as APPEL. When a user wants to browse a Web site, a user-agent, which is embedded into the user’s browser, first retrieves the Web site’s P3P policy. The user-agent compares the policy with the user’s preferences. If the policy complies with the preferences, then the Web site is made available. Otherwise, the user may be prompted for further evaluation or his/her request may be cancelled. While we have shown in this paper that preferences are related to execution time and execution location of Web services, preferences can also be associated with privacy when it comes to disclosing some sensitive information on users. Barkhuus and Dey have identified three levels of interactivity for context-aware applications [1]: personalization, active context-awareness, and passive context-awareness. According to the authors, personalization is motivated by

the diversity and dynamics featuring nowadays applications. For active context-awareness, it concerns applications that, on the basis of sensor data, change their content autonomously. In passive context-awareness, applications merely present the updated context to the user and let the user specify how the application should change. In this paper, a passive context-awareness style was adopted with the manual identification of the user’s current location. While we mentioned that this type of identification presents some limitations vs. an automatic identification, it enables however an efficient handling of the privacy concern of users.

8

Conclusion

In this paper, we presented our approach of contextbased personalization for Web services composition and provisioning. Three types of context, namely user, service, and resource, are the cornerstone of the approach. Indeed, they store details related to personalization such as preferred execution-time and preferred execution-location of Web services. The effect of changes of a Web service because of users’ preferences and resources’ availabilities has required the development of three types of policies referred to as consistency, feasibility, and inspection. Consistency policy ensures that a Web service still does what it is supposed to do despite personalization. Feasibility policy checks if a personalized Web service can find a resource on which it can be executed. Finally, inspection policy ensures that a personalized Web service is being deployed according to the adjusted specification. As future work, an extension to the context structure related to security and privacy issues. Future work also includes developing a prototype for validation purposes and linking the context-based structure to transaction management and coordination of Web services composition.

References [1] L. Barkhuus and A. Dey. Is Context-Aware Computing taking Control away from the User? Three levels of Interactivity Examined. In Proceedings of The Fifth International Conference on Ubiquitous Computing (UbiComp’2003), Seattle, Washington, USA, 2003. [2] B. Benatallah, Q. Z. Sheng, and M. Dumas. The Self-Serv Environment for Web Services Composition. IEEE Internet Computing, 7(1), January/February 2003. [3] D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Mecella. A Foundational Vision for e-Services. In Proceedings of The Workshop on Web Services, e-Business, and the Semantic Web (WES’2003) held in conjunction with The 15th Conference On Advanced Information Systems Engineering (CAiSE’2003), Klagenfurt/Velden, Austria, 2003. [4] M. Bonett. Personalization of Web Services: Opportunities and Challenges. ARIADNE, 28, June 2001. http://www.ariadne.ac.uk/, ISSN: 1361-3200.


[5] P. Brézillon. Focusing on Context in Human-Centered Computing. IEEE Intelligent Systems, 18(3), May/June 2003. [6] 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. [7] D. Harel and A. Naamad. The STATEMATE Semantics of Statecharts. ACM Transactions on Software Engineering and Methodology, 5(4), October 1996. [8] H. G. Hegering, A. Küpper, C. Linnhoff-Popien, and H. Reiser. Management Challenges of Context-Aware Services in Ubiquitous Environments. In Proceedings of The 14th IFIP/IEEE International Workshop on Distributed Systems: Operations and Management (DSOM’2003), Heidelberg, Germany, 2003. [9] G. Kouadri Mostéfaoui and P. Brézillon. Modeling ContextBased Security Policies with Contextual Graphs. In Proceedings of The Workshop on Context Modeling and Reasoning (CoMoRea’2004) held in conjunction with The 2nd IEEE International Conference on Pervasive Computing and Communication (PerCom’2004), Orlando, Florida, USA, 2004. [10] Z. Maamar, S. Kouadri Mostéfaoui, and H. Yahyaoui. A Web Services Composition Approach based on Software Agents and Context. In Proceedings of The 19th Annual ACM Symposium on Applied Computing (SAC’2004), Nicosia, Cyprus, 2004. [11] Z. Maamar, S. Kouadri Mostéfaoui, H. Yahyaoui, and W. J. van den Heuvel. Towards an Agent-based and Contextoriented Approach to Compose Web Services. In Proceedings of The 6th International Conference on Enterprise Information Systems (ICEIS’2004), Porto, Portugal, 2004. [12] Z. Maamar, H. Yahyaoui, Q. H. Mahmoud, and F. Akhter. Dynamic Management of UDDI Registries in a Wireless Environment of Web Services. In Proceedings of The Second International Conference on Wired/Wireless Internet Communications (WWIC’2004), Frankfurt (Oder), Germany, 2004. [13] D. A. Menascé. QoS Issues in Web Services. IEEE Internet Computing, 6(6), November/December 2002. [14] C. Muldoon, G. O’Hare, D. Phelan, R. Strahan, and R. Collier. ACCESS: An Agent Architecture for Ubiquitous Service Delivery. In Proceedings of The Seventh International Workshop on Cooperative Information Agents (CIA’2003), Helsinki, Finland, 2003. [15] M. Papazoglou and D. Georgakopoulos. Introduction to the Special Issue on Service-Oriented Computing. Communications of the ACM, 46(10), October 2003. [16] I. A. Smith, P. R. Cohen, J. M. Bradshaw, M. Greaves, and H. Holmback. Designing Conversation Policies using Joint Intention Theory. In Proceedings of The Third International Conference on Multi-Agent Systems (ICMAS’1998), Paris, France, 1998. [17] M. Zuidweg, J. G. Pereira Filho, and M. van Sinderen. Using P3P in a Web Services-based Context-Aware Application Platform. In Proceedings of The 9th Open European Summer School and IFIP Workshop on Next Generation Networks (EUNICE’2003), Balatonfured, Hungary, 2003.