The Second International Conference on Innovations in Information Technology (IIT’05)
Context Meets Web Services Personalization Zakaria Maamar and Emad Bataineh College of Information Systems Zayed University, Dubai, U.A.E zakaria.maamar/
[email protected] ABSTRACT This paper discusses the use of context in Web services personalization. The objective of personalization is to accommodate user preferences, which are of different types varying from when the execution of a Web service should start to where the outcome of this execution should be delivered. Besides user preferences, computing resources on which the Web services operate have an impact on the personalization of Web services. To track the personalization of a Web service, three types of contexts are devised and referred to as user context, Web service context, and resource context.
Keywords: Web Service, Personalization, Context.
1. INTRODUCTION & MOTIVATION A Web service is an accessible application that other applications and humans can discover and trigger to satisfy various needs [4]. One of the strengthens 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. Composing services rather than accessing a single service is essential and offers 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 [1]. Because users' expectations and requirements constantly change, it is important to include their preferences in the composition and provisioning of Web services. Indeed some users would like receiving answers to their personal requests directly submitted to their personal email instead of office's email, while some users would like having certain services, such as traffic conditions, automatically triggered once they get into their cars. These two basic situations shed the light on personalization and its impact on making applications adjustable. Personalization is of type explicit or implicit [3]. Explicit personalization calls for a direct participation of users in the adjustment of applications. Users clearly indicate 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 track users' behaviors. Personalization is dependent on the features of the environment in which it happens. These features can be related to computing resources (e.g., fixed device, mobile device), time periods (e.g., in the afternoon, in the morning), and physical locations (e.g., meeting room, cafeteria). The gathering and refinement of an environment's features permit defining its context. Context is the information that characterizes the interaction between humans, applications, and the surrounding environment [2]. Web services composition and provisioning are a very active area of R&D [4]. However, very little has been accomplished to date regarding their context-based personalization. Several obstacles still hinder 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., BPEL) typically facilitate choreography only, while neglecting contextual information on users and services too, and (iii) lack of support techniques for modeling and specifying the integration of personalization into Web services. In this paper we overview our approach for personalizing Web services using context. The major features of this approach are as follows: (i) 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
The Second International Conference on Innovations in Information Technology (IIT’05)
context; (ii) three types of policy are developed in order to guarantee that the Web services still do what they are supposed to do despite personalization; and (iii) Web services engage in conversations with their peers during personalization. Only point (i) is discussed. Section 2 presents the approach for personalizing Web services. Section 3 concludes the paper.
2. APPROACH FOR PERSONALIZING WEB SERVICES 2.1 FOUNDATIONS Figure 1 illustrates the approach that backs the personalization of Web services. The core concept of this approach is context from which three sub-contexts are derived: U-context, W-context, and R-context. Muldoon et al. define the user context of a user as an aggregation of his location, previous activities, and preferences [3]. We define the Web-service context of a Web service as an aggregation of its simultaneous participations in composite services, locations of execution, times of execution, and constraints during execution. Finally we define the resource context of a resource as an aggregation of its current status, periods of non-availability, and capacities of meeting the execution requirements of Web services. Context Legend
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)
W-context
Web service context
R-context
Resource context
U-context
User context
to extend to be attached
Resource(s)
Figure 1 Representation of the context-based personalization approach
In Figure 1, U-context, W-context, and R-context are inter-connected. From R-context to Wcontext, "execution adjustment" relationship identifies the execution constraints on a Web service (e.g., execution time, execution location, flow 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 and assess its current commitments before it agrees on supporting the execution of another service. From U-context to W-context, "provisioning personalization" relationship identifies the preferences of a user (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 or in a certain location). A Web service needs to check its status before it agrees on satisfying a user's needs. W-context is the common element between U-context and R-context. A Web service conciliates between what a user wishes and what a resource permits. A Web service is subject to (i) personalization because of users' preferences and (ii) adjustment because of resources' availabilities. Users and resources are the triggers that make Web services change so that they can accommodate preferences and consider availabilities. In addition to both triggers, a third trigger exists which is, in fact, a personalized Web service. The personalization of a Web service can trigger the take into account of other Web services, which are in relationship with this personalized Web service. We call this type of relationship causal. This latter identifies the dependency between services. For example, if a service is personalized so it accommodates a certain time preference, it is important to ensure that the preceding services are all successfully executed before the time that features the execution of this service. This means that the respective execution times of these services have to be checked and adjusted if needed. An illustration of the
The Second International Conference on Innovations in Information Technology (IIT’05)
causal relationships between personalized Web services is given in Section 2.2.
2.2 OPERATION Figure 2 illustrates the interactions during context-based personalization of Web services. When a user selects a Web service, he continues after with its personalization according to his time and location preferences. Time preference is organized along two parts: (i) when the execution of the service should start, and (ii) when the outcome of this execution should be returned to the user. A user could request that the execution of a Web service starts at 2pm and the delivery of the execution result occurs after 4pm because of 2 to 4pm meeting. It happens that execution time and delivery time are equal if the time that the execution lasts is excluded or negligible. Location preference is also organized along two parts: (i) where the execution of the service should occur, and (ii) where the outcome of this execution should be returned to the user. User
Web service
Other Web services
Resource
Identification + preferences
Legend
W-Context
Interaction Assessment no
Trigger Action
yes/Identification
Selection
R-Context
End
Assessment no
no Notification/yes
R-Context Update
W-Context Update Notification (causal relationships)
W-Context Assessment no
no Notification/yes
W-Context Update
W-Context Update Notification
U-Context Update
Figure 2 Interactions between participants of personalized Web services
Once the user's preferences are submitted to the Web service, this one ensures that the dates and locations are valid and no conflicts might happen during deployment (e.g., the delivery time does not occur before the execution time of a service). Moreover the user has to be continuously reminded that he has to explicitly identify his current location so that execution location and delivery location are both properly handled1. Priori to identifying the resources on which it will be executed, the Web service checks its W-context with regard to (i) number of Web services currently under execution vs. maximum number of Web services under execution and (ii) next period of unavailability. After a positive check of the W-context, the identification of a resource is now launched. It is assumed that a mechanism supporting the identification of resources is available. A resource mainly needs to accommodate two things: (i) the start time of a service execution, and (ii) the time that the execution of a service lasts since the outcome of this execution depends on the delivery time as per user's indication. To this purpose a resource checks its R-context with regard to (i) next periods of time that will feature the execution of Web services 1 While a manual feeding of the current location of users present some limitations, this feeding allows a better handling of the privacy issue since users only reveal to external systems the locations they wish to be known. The manual feeding is inline with the privacy control that is considered in the design of contextaware computing platform [5].
The Second International Conference on Innovations in Information Technology (IIT’05)
and (i) next period of maintenance. After a positive check the resource notifies the service, which itself proceeds with notifying the user. Before the personalized Web service notifies the user about the handling of his 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, to the personalized Web service (Section 2.1). The description given in the previous paragraphs also applies to the extra Web services, which assess their current status through their respective W-contexts and search for the resources on which they will be executed. To keep Figure 2 clear, the interactions that the new personalized Web services undertake to search for the resources are not represented. Once all the Web services are personalized, a final notification is sent out to the user about the deployment of the Web service that he has initially requested.
CONCLUSION This paper has presented an approach that integrates context into Web services personalization. Personalization occurs when there is a need of accommodating preferences during performance and outcome delivery of these Web services. Preferences are user-related and are of different types varying from when the execution of a Web service should start to where the outcome of this execution should be delivered. Besides users' preferences, it was discussed that the computing resources on which the Web services are carried out have an impact on the personalization of Web services. Indeed resources have to undertake some scheduling work so that they can satisfy the execution requests that originate from multiple Web services. To track the personalization of a Web service in terms of what happened, what is happening, and what will happen three types of context are devised and referred to as user context, Web service context, and resource context.
ACKNOWLEDGEMENT We acknowledge the contributions of S. Kouadri Mostéfaoui (Fribourg University, Switzerland) and Q. H. Mahmoud (Guelph University, Canada) to the project described in this paper.
REFERENCES [1] D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M. Mecella. A Foundational Vision for eServices, in Proceedings of The Workshop on Web Services, e-Business, and the Semantic Web (WES'2003) held in conjunction with The 15th International Conference On Advanced Information Systems Engineering (CAiSE'2003), Klagenfurt/Velden, Austria, 2003. [2] P. Brézillon. Focusing on Context in Human-Centered Computing. IEEE Intelligent Systems, 18(3), May/June 2003. [3] 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. [4] M. Papazoglou and D. Georgakopoulos. Introduction to the Special Issue on Service-Oriented Computing. Communications of the ACM, 46(10), October 2003. [5] M. Zuidweg, J. G. Pereira Filho, and M. van Sinderen. Using P3P in a Web Services-based ContextAware Application Platform, in Proceedings of The 9th Open European Summer School and IFIP Workshop on Next Generation Networks (EUNICE'2003), Balatonfured, Hungary, 2003.
