Enterprise Service Computing Scientific_13

0 Maamar currently under execution vs. the maximum number of Web services under execution and (b) the next period of unavailability. After a positive check of the W-context, the identification of a resource is now launched. In ConPWS, we assume the existence of a mechanism supporting the identification of resources. Aresource mainly needs to accommodate two things: (a) the beginning time of a Web-service execution, and (b) the time that the execution of a Web service lasts since the outcome of this execution depends on the delivery time as per user indication. To this purpose, a resource checks its R-context with regard to (a) the next periods of time that will feature the execution of Web services, and (b) the next period of maintenance. After a positive check, the resource notifies the Web service about its availability to sup-port this service execution. Before the personalized Web service notifies the user about the handling of his or her time and location preferences, an extra personalization process is triggered. This consists of adjusting the Web services that are linked, through the causal relationship, to the personalized Web service. 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 oper-ate. To keep Figure 7 clean, 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 or she has requested. Policies.in.ConPWS Because of user preferences and resource availabilities, a Web service is adjusted so that it accommodates these preferences and deals with these availabilities. To ensure that the adjustment of a Web service is efficient, ConPWS integrates three types of policies (owners of Web services are normally responsible for developing the policies). The first type, called consistency, checks the status of a Web service after it has been personalized. The second type, called feasibility, guarantees that a personalized Web service finds a resource on which it can operate according to the constraints of time and location. Finally, the third type, called inspection, ensures that the deployment of a personalized Web service complies with the adjusted specification. A consistency policy guarantees that a Web service still does what it is supposed to do after personalization. Personalization may alter the initial specification of a Web service when it comes, for instance, to the list of regular events that trigger the service. Indeed, time- and location-related parameters are new events that need to be added to the list of regular events. Moreover, because of the QoS (quality of service) -related parameters of a Web service (e.g., response time and throughput; Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis-sion of Idea Group Inc. is prohibited. Two Research Projects on Web Servces and Context 0 Menascé, 2002), it is important to verify that these QoS parameters did not change and are still satisfied despite the personalization. For illustration, because a user wishes to start the execution of a service at 2 p.m., which corresponds to the peak-time period of receiving requests, the response-time QoS cannot be satisfied. Afeasibility policy guarantees that an appropriate resource is always identified for the execution of a personalized Web service. Because Web services have different requirements (e.g., period of requests, period of deliveries) and resources have dif-ferent constraints (e.g., period of availabilities, maximum capacity), an agreement has to be reached between what Web services need in terms of resources and what resources offer in terms of capabilities. Furthermore, the feasibility policy checks that the new operations of the personalized Web service are properly handled by the available resources. For example, if a new operation that is the result of a personal-ization requires a wireless connection, this connection has to be made available. An inspection policy is a means by which various aspects are considered such as what to track (time, location, etc.), who asked to track (user, the service itself, or both), when to track (continuously, intermittently), when and how to update the arguments of contexts, and how to react if a discrepancy is noticed between what was requested and what has effectively happened. The inspection policy is mainly tightened to the W-context of a Web service. If there is a discrepancy between what was requested and what has effectively happened, 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 has to be executed. Summary In this part of the chapter, we reviewed ConPWS for personalizing Web services using preferences and policies. Personalization occurs when there is a need for ac-commodatingpreferencesduringtheperformanceandoutcomedeliveryoftheseWeb 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 user preferences, ConPWS deals with the computing resources on which the Web services are carried out since resource availabilities impact their personalization. As part of the implementation strategy in the ConPWS. project, the Web services policy language (WSPL) could be used for implementing the policies related to Web services. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 0 Maamar How.Context.Fits.into.Web.Services Roman and Campbell (2002) observe that a user-centric context promotes appli-cations that move with users, adapt to the changes in the available resources, and provide configuration mechanisms based on user preferences. Parallel to the user-centric context, ConCWS and ConPWS bind to a service-centric context in order to promote applications that permit service adaptability, track service execution, and support on-the-fly service composition. A user-centric context is associated with the U-context, whereas a service-centric context is associated with the W-context and C-context. Because Web services are the core components of a composition process, the W-context is organized in ConCWS and ConPWS along three perspec-tives (Figure 8): participation, execution, and location and time. • The participation perspective is about overseeing the multiple composition scenarios in which a Web service concurrently takes part. This guarantees that the Web service is properly specified and is ready for execution in each composition scenario. • The execution perspective is about looking for the computing resources on whichaWebserviceoperates,andmonitoringthecapabilitiesoftheseresources so that the Web service’s requirements are constantly satisfied. • The preference perspective is about ensuring that user preferences regarding execution time (e.g., at 2 p.m.) and execution location (e.g., user passing by meeting room) are integrated into the specification of a composite service. Figure 8 also illustrates the connections between the participation, execution, and preference perspectives. First, deployment connects the participation and execution perspectives, and highlights the Web service that is executed once it agrees to par- Figure 8. Perspective-based organization of W-context Participation Execution Preference Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis-sion of Idea Group Inc. is prohibited. Two Research Projects on Web Servces and Context 0 ticipate in a composition. Second, tracking connects the execution and preference perspectives, and highlights the significance of monitoring the execution of a Web service so that user preferences are properly handled. Finally, customization con-nects the preference and participation perspectives, and highlights the possibility of adjusting a Web service so that it can accommodate various user preferences. The integration of context into Web-services composition ensures that the require-ments of and constraints on these Web services are taken into account. While current composition approaches rely on different selection criteria (e.g., execution cost and reliability), context supports Web services in their decision-making process when it comestowhethertoacceptorrejectparticipatinginacomposition.Moreover,context is suitable for tracing the execution of Web services during exception handling. It would be possible to know at any time what happened and what is happening with a Web service. Predicting what will happen to a Web service would also be feasible in case the past contexts (i.e., what happened to a service) are stored. Web services can take advantage of the information that past contexts cater so that they can adapt their behavior for better actions and interactions with peers and users. Conclusion Inthischapter,wereviewedtworesearchprojectsdenotedbyConCWSandConPWS. Both are concerned with the integration of context into Web-services composition and personalization. We promoted the use of context because of the requirements of flexibility, autonomy, and stability that Web-services self-management situa-tions have to satisfy. Additional requirements, namely, connectivity, nonfunctional quality-of-service properties, correctness, and scalability, also exist as reported in Milanovic and Malek (2004). The research field of context-aware Web services opens up the opportunity for further investigation since several obstacles still hin-der the deployment of such Web services, including the fact that current standards for Web services do not enhance them with any context-awareness mechanisms, existing specification approaches for Web-services composition typically facilitate orchestration only while neglecting contexts and their impact on this orchestra-tion, and guidelines supporting the operations of Web-services personalization and tracking are lacking. Acknowledgments The author acknowledges the contributions of S. K. Mostéfaoui, H. Yahyaoui, Q. Mahmoud, and W. J. van den Heuvel to the projects presented in this chapter. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 0 Maamar References Ardissono, L., Goy, A., & Petrone, G. (2003). Enabling conversations with Web services. In Proceedings of the Second International Joint Conference on Autonomous Agents & Multi-Agent Systems (AAMAS 2003), Melbourne, Australia. Benatallah, B., Dumas, M., Sheng, Q. Z., & Ngu, A. (2002). Declarative composi-tion and peer-to-peer provisioning of dynamic Web services. In Proceedings of the 18th International Conference on Data Engineering (ICDE 2002), San Jose, CA. Benatallah, B., Sheng, Q. Z., & Dumas, M. (2003). The self-serve environment for Web services composition. IEEE Internet Computing, 7(1), 40-48. Bonett, M. (2001). Personalization of Web services: Opportunities and challenges. ARIADNE, 28. Retrieved from http://www.ariadne.ac.uk/ Boudriga, N., & Obaidat, M. S. (2004). Intelligent agents on the Web: A review. Computing in Science Engineering, 6(4), 35-42. Coutaz, J., Crowley, J. L., Dobson, S., & Garlan, D. (2005). Context is key. Com-munications of the ACM, 48(3), 49-53. Curbera, F., Khalaf, R., Mukhi, N., Tai, S., & Weerawarana, S. (2003). The next step in Web services. Communications of the ACM, 46(10), 29-34. Leymann, F. (2001). Web services flow language (WSFL 1.0) (Tech. Rep.). IBM Corporation. Maamar, Z. (2001). Moving code (servlet strategy) vs. inviting code (applet strat-egy): Which strategy to suggest to software agents? In Proceedings of the Third International Conference on Enterprise Information Systems (ICEIS 2001), Setúbal, Portugal. Maamar, Z., Benatallah, B., & Mansoor, W. (2003). Service chart diagrams: Descrip-tion & application. In Proceedings of the Alternate Tracks of the 12th Interna-tional World Wide Web Conference (WWW 2003), Budapest, Hungary. Maamar, Z., Kouadri Mostéfaoui, S., & Mahmoud, Q. (2005). On personalizing Web services using context. International Journal of E-Business Research, 1(3), 41-62. Maamar, Z., Kouadri Mostéfaoui, S., & Yahyaoui, H. (2005). Towards an agent-based and context-oriented approach for Web services composition. IEEE Transactions on Knowledge and Data Engineering, 17(5), 686-697. Maamar,Z.,&Mansoor,W.(2003).Designanddevelopmentofasoftwareagent-based and mobile service-oriented environment. e-Service Journal, 2(3), 42-58. Copyright © 2007, Idea Group Inc. Copying or distributing in print or electronic forms without written permis-sion of Idea Group Inc. is prohibited. ... - tailieumienphi.vn