Electronic Business: Concepts, Methodologies, Tools, and Applications (4-Volumes) P45 pps

374 A Context-Based and Policy-Driven Method to Design and Develop Composite Web Services been developed like WSDL, SOAP, and UDDI (Curbera, 2002). On the other hand, several projects related to Web services composition, personalization, etc., have been initiated (Sprick, 2005; Pernici, 2005; Nepal, 2005; Mrissa, 2005; Tolk, 2005). These projects’ efforts are mainly put into the development of solutions that address Web services automatic-composition issues. Com- position handles the situation of a user’s request WKDWFDQQRWEHVDWLV¿HGE\DQ\VLQJOHDYDLODEOH Web service, whereas a composite Web service obtained by combining available Web services may be used. In addition to composition, other research initiatives on Web services are concerned with the issues of Web services description, discovery, semantic mediation, just to cite a few (Pernici, 2005). In this chapter, we shed the light on another issue that has so far received a little attention from the research community. This issue is the lack of design and development methods. The main objective of such methods is to assist those who are in charge of delivering Web services-based information systems as per end-users’ needs and requirements. Nowadays, designers and develop- ers are put on the front line of satisfying the prom- ise of Web services’ providers to deliver a new generation of Business-to-Business information V\VWHPV6LPSO\SXWDPHWKRGFRPSULVHV¿UVW a set of steps to perform according to a certain chronology and second, a notation to comply with during graphical modeling. A graphical notation is very important since it facilitates discussions and validation exercises among the members of the design team and with end-users, respectively. In this chapter we propose our design and develop- ment method CP4WS, which stands for Context and Policy for Web Services. CP4WS is built upon our previous research on Web services (Maamar, 2006a; Maamar, 2005a; Maamar, 2005b; Maamar, 2006e; Mrissa 2005), and puts forward two major concepts on top of the Web services concept: policy and context. Policies are here to manage various aspects related to Web services like participation in composition, semantic mediation, and adjustment due to changes in the environment, while context is here to provide the necessary information that enables for instance to trigger the appropriate policies and to regulate the interactions between Web services according to the current state of the environment. In CP4WS, an extra element namely resource is part of the design and development exercise of Web services-based information systems. A UHVRXUFHLGHQWL¿HVDFRPSXWLQJPHDQVHJVRIW- ware and hardware platform, upon which a Web service operates. Because resources schedule the execution requests of Web services, these latter have to be constantly aware of the capabilities and limitations of these resources. It is stressed that locking resources for long periods of time is by far not acceptable as the number of available Web services continues to grow, so the use of resources will become intensive (Limthanmaphon, 2004). The rest of this chapter proceeds as follows. 7KHQH[WVHFWLRQGH¿QHVSROLF\DQGFRQWH[WFRQ- cepts, discusses the rationale of adopting both concepts in CP4WS, and continues afterwards with introducing a running scenario that is used for illustration purposes throughout the chapter. Next, a new section is devoted to the different steps that constitute CP4WS. Some steps come along with a graphical notation, which is illustrated using the running scenario as part of the modeling exercise of a composite Web service. This is followed by a presentation of the prototype that implements the design of the running scenario. Related work and concluding remarks are presented and drawn in the last two sections, respectively. PRELIMINARIES 'H¿QLWLRQV &RQWH[W³LVQRWVLPSO\WKHVWDWHRIDSUHGH¿QHG HQYLURQPHQW ZLWKD ¿[HG VHWRILQWHUDFWLRQ UH- sources. It is part of a process of interacting 375 A Context-Based and Policy-Driven Method to Design and Develop Composite Web Services with an ever-changing environment composed RI UHFRQ¿JXUDEOH PLJUDWRU\ GLVWULEXWHG DQG multiscale resources”. (Coutaz, 2005). In the ¿HOGRI:HEVHUYLFHVFRQWH[WVXSSRUWVWKHGH- velopment of adaptable Web services (Keidl, 2004; Maamar, 2006). These Web services would be able to take into account the aspects of the environment in which they operate. These aspects are multiple and can be related to users (e.g., stationary, mobile), time of day (e.g., in the afternoon, in the morning), physical locations (e.g., meeting room, cafeteria), etc. As a result, Web services would be more responsive to their VXUURXQGLQJHQYLURQPHQWDVWKH\ZRXOGEHÀH[- ible, stable, and autonomous (Maamar, 2006). Flexible refers to a Web service that selects the appropriate operations so that it can accommodate the situation wherein it participates. Stable refers to a Web service that resists unforeseen changes so that it can maintain operation and recover to normal levels of operation after disturbances. Finally, autonomous refers to a Web service that accepts demands of participation in composition scenarios, rejects these demands in case of unap- pealing rewards, or possibly recommends other peers for participation in these scenarios. 3ROLFLHVDUHGH¿QHGDV³information which can be used to modif y the behavior of a system” (Lupu, 2XUGH¿QLWLRQLQ0DDPDUJRHV EH\RQGEHKDYLRUPRGL¿FDWLRQDQGFRQVLGHUVSROL- FLHVDVH[WHUQDOG\QDPLFDOO\PRGL¿DEOHUXOHVDQG parameters that are used as input to a system. This permits to the system to adjust to administrative de- cisions and changes in the execution environment. Policies have been applied in multiple domains like telecommunication-devices control features (Rei- ffMarganiec, 2003), and conversation regulation between intelligent components (Kagal, 2005). In WKH¿HOGRI:HEVHUYLFHVSROLFLHVDUHLQWHQGHGWR specify the behavior of a Web service so that this latter can align its capabilities to the preferences of users and the requirements of resources. Policies are also intended to frame interactions between Web services and users, and between Web services themselves. These interactions could concern many issues like security, quality of service, exception handling, etc. In (Maamar, 2006), we discuss six different scenarios that concern the potential uses of policies in Web services. These scenarios are denoted by announcement, selection, compatibil- LW\DJUHHPHQWYHUL¿FDWLRQDQGFRPSRVLWLRQ)RU example, the announcement scenario shows how offered and required policies can be part of the WSDL description of a Web service. Moreover we discuss in (Maamar, 2006) how the lack of a standard framework for enhancing Web services through policies, is currently balanced with two general approaches referred to as semantic Web and Boolean combinations of policy predicates. Rationale of Context and Policies We argue the use of context and policies in CP4WS with the following two points: • Context collects and contains various in - formation on the environment wherein the composition of Web services takes place. These information help track the composi- tion progress, which permits to identify for instance the policies to trigger and the interactions to initiate. Composition prog- ress needs to happen in accordance with the current state of the environment and the current constraints on Web services such as performance and reliability. • Policies separate guidelines for conducting FRPSRVLWLRQ IURP JXLGHOLQHV IRU GH¿QLQJ Web services. Guidelines for Web services composition concern among other things how to integrate user preferences into Web services, how to guarantee the satisfaction of these preferences subject to resource availability, and how to track the execution progress of Web services? Guidelines for :HEVHUYLFHVGH¿QLWLRQFRQFHUQDPRQJRWKHU things how to announce Web services to po- tential users, how to deal with Web services 376 A Context-Based and Policy-Driven Method to Design and Develop Composite Web Services non-reliability, and how to suspend Web services execution due to risks of behavior alteration or information interception? Running Scenario Our running scenario concerns Amin who is visit- ing Melissa in Oslo. Amin and Melissa agree on a certain day to meet in a coffee shop. Amin has two options to reach the meeting place: by taxi or by bus. For illustration purposes we identify some potential Web services that could take over the implementation of this scenario. One of the expected outcomes of CP4WS is to identify Web services according to the studied case-study. At his hotel, Amin browses some Web sites about transport in Oslo. A site has ItineraryWS that proposes routes for example between Amin’s hotel and the coffee shop. The proposed routes are subject to some conditions including weather IRUHFDVWVDQGWUDI¿FMDPV&ROGZHDWKHUUHVXOWV in recommending taxis, otherwise public trans- port like tramways and buses are recommended. Parallel to consulting WeatherWS for weather forecasts, ItineraryWS requests details on the origin and destination places using LocationWS. In case WeatherWS returns bad weather, a taxi booking is made using TaxiWS upon Amin’s ap- proval. Otherwise, Amin uses public transport. The location of both Amin’s hotel and coffee shop are submitted to BusScheduleW S , which returns the numbers of buses that Amin will have WRULGH3RWHQWLDOWUDI¿FMDPVLQ2VORIRUFHBusS- cheduleW S to regu larly interact w ith 7UDI¿F:6 that monitors the transportation network. This monitoring outcome is fed into BusScheduleWS so that changes in the suggested bus numbers are made. Amin scenario, although simple, yields insight into the multiple challenges that designers and developers of composite Web services face. Some challenges include: how to identify the relevant Web services, how to orchestrate the Web services, how to make the Web services context-aware, how to use policies to regulate the behavior of Web services, and how to run the Web services subject to resource availability? DESIGN AND DEVELOPMENT STEPS IN CP4WS Like other design and development methods in WKH ¿HOG RI LQIRUPDWLRQ V\VWHPV UHODWHG ZRUN Section), CP4WS has almost the same concerns. Firstly, methods focus on identifying users’ re- quirements to ensure the usability of the developed system. Secondly, methods suggest guidelines during design and development work. Last but not least, methods adopt graphical notations to support abstract modeling and to facilitate valida- WLRQH[HUFLVHV,QWKLVVHFWLRQZHGHWDLOWKH¿YH steps that make up CP4WS and the rationale and expected outcome of each step. Some illustrations per step are also given based on Amin scenario. Figure 1 summarizes the steps in CPWS including the major actions and representation formalisms (i.e., graphical notation) per step. 8VHU1HHGV,GHQWL¿FDWLRQ$QG 6SHFL¿FDWLRQ6WHS 7KH ¿UVW VWHSLQ &3:6FRQVLVWV RILGHQWLI\LQJ and specifying users’ needs. Traditional software- engineering techniques that permit identifying users’ needs and requirements are adopted in CP4WS such as interviewing users, studying current practices, reviewing forms, and collecting information on similar applications. Regarding the VSHFL¿FDWLRQWHFKQLTXHRIXVHUV¶QHHGV&3:6 adopts the well-known use-cases of UML (Booch, 1998). This adoption has several advantages: (i) most information system designers/developers are IDPLOLDUZLWKXVHFDVHVLLLGHQWL¿HGXVHFDVHV could be mapped onto potential Web services, and (iii) interactions between use-cases are an excellent indicator of the composition-based collaboration EHWZHHQWKHLGHQWL¿HG:HEVHUYLFHV,WVKRXOGEH 377 A Context-Based and Policy-Driven Method to Design and Develop Composite Web Services QRWHGWKDWWKHLGHQWL¿FDWLRQRIWKHDSSURSULDWHDF- tors and use-cases during this step in CP4WS takes advantage of designers’ experience and familiarity with the application domain. Figure 2 presents a part of the use-case model we developed for Amin scenario. Several actors are shown like Amin, Weather Forecast agency, and Transportation agency. In addition, several XVHFDVHVDUHLGHQWL¿HGOLNHItinerary Develop- ment, Weather Forecast Establishment, and 7UDI¿F0RQLWRULQJ7KHVDPH¿JXUHVKRZVWKH way some use-cases (i.e., dashed lines in Figure 2) interact with one other. For instance, Itinerary Development use-case needs details on the situa- WLRQRIWKHWUDI¿FWKDWDUHREWDLQHGRXWRI7UDI¿F Monitoring use-case. Web Services Orchestration Step The second step in CP4WS consists of specifying the orchestration of the Web services that will constitute the future composite Web service. The types (in term of functionality) of the required :HEVHUYLFHVDUHDOUHDG\LGHQWL¿HGEDVHGRQ WKH RXWFRPH RI XVHU QHHGV LGHQWL¿FDWLRQ DQG VSHFL¿FDWLRQ VWHS :HUHFDOO WKDW D XVHFDVH LV a potential candidate to be mapped onto a Web service although the mapping is not always one- to-one. Several use-cases could be gathered into one Web service, one use-case could be associ- ated with several Web services, etc. This is the designer’s responsibility to identify and verify the right number of Web services. Figure 1. Design and development steps in CP4WS 8VHUQHHGVLGHQWL¿FDWLRQDQGVSHFL¿FDWLRQVWHS • Major actions: identify user needs, validate user needs, collect information on similar applica- tions • Representation formalism: UML use-case. Web services orchestration step • Major actions: identify types of Web services, identify interaction between Web services, com - pose Web services. • Representation formalism: service chart diagram and UML state chart diagram. Web services contextualization step • Major actions: identify parameters of context, specify update operations between contexts.  5HSUHVHQWDWLRQIRUPDOLVPQXOOQRWDVSHFL¿FRQH :HEVHUYLFHVEHKDYLRUVSHFL¿FDWLRQVWHS • Major actions: identify behavior types of Web service, specify behaviors using policies. • Representation formalism: WSPL. Web services deployment step  0DMRU DFWLRQVGH¿QH EHKDYLRUV RI:HEVHUYLFH WRZDUGV UHVRXUFHV VSHFLI\ EHKDYLRUV XVLQJ policies. • Representation formalism: WSPL. 378 A Context-Based and Policy-Driven Method to Design and Develop Composite Web Services The Web services orchestration step relies on the concept of service chart diagram (Maamar, 2003). A service chart diagram enhances an UML state chart diagram (Booch, 1998), putting this time emphasis on the elements affecting the execution of a Web service rather than only on the states that a Web service takes (Figure 3). As a result, the states RID:HEVHUYLFHDUHZUDSSHGLQWR¿YHSHUVSHFWLYHV The state perspective corresponds to a regular UML VWDWHFKDUWGLDJUDP RIWKH:HEVHUYLFH7KH ÀRZ perspective corresponds to the chronology of the composite Web service in which the Web service SDUWLFLSDWHV7KHEXVLQHVVSHUVSHFWLYHLGHQWL¿HVWKH different organizations that make the Web service DYDLODEOH7KHL QIRU PDWLRQSHUVSHFWLYHLGHQWL¿HVWKH data that are exchanged between the Web service and its peers in the same composite Web service. Finally, the performance perspective illustrates how the Web service can be triggered (either locally or remotely (Maamar, 2003)) for execution. Because a composite Web service consists of several component Web services, the business process-model that underpins the orchestration RIWKLVFRPSRVLWH:HEVHUYLFHLVVSHFL¿HGDVDQ UML state chart diagram. In this diagram, states are associated with service chart diagrams, and transitions are labeled with events, conditions, and variable assignment operations. Figure 4 illustrates the orchestration of the composite Web service we developed for Amin scenario. Six component Web services are listed: ITineray (IT), WEather (WE), Location (LO), Taxi (TA), Figure 2. Part of Amin scenario’s UML use-cases Itinerary development W. forecast establishment Traffic monitoring Weather Forecast agency Amin Transporation agency uses uses Use-case Legend Human actor Organizational actor Figure 3. Service chart diagram of a component Web service Data from previous Web services Data to next Web services Performance type Previous Web services (M/O) Next Web services (M/O) Business Web service in State 1 State 2 B State j E out 379 A Context-Based and Policy-Driven Method to Design and Develop Composite Web Services Bus Schedule (BSDQG7UDI¿&TC). In this ¿JXUH>FRQ¿UPHGEDGZHDWKHU@LVDQH[DPSOH of a constraint over a transition. We recall that ITinerayWS is associated with Itinerary Develop- PHQWXVHFDVHDVGH¿QHGLQSUHYLRXVO\ Web Services Contextualization Step The third step in CP4WS consists of specifying the contexts of the participants that could take part in Web services composition. In addition to Web services as default participant, CP4WS suggests the following list of participants: composite Web service, resource, and user. Additional types of SDU WLFLSD QWVFRX OGEHDGGHGDVSHUWKHVSHFL ¿FUH - quirements of the studied application domain and business case. CP4WS associates each participant type with a dedicated context to be labeled using this participant’s name for example W-context for context of Web service, C-context for context of Composite Web service, R-context for context of Resource, and U-context for context of User. It will be shown in the next step in CP4WS how context DIIHFWVWKHSURFHVVRIORDGLQJDQG¿ULQJSROLFLHV 7KHIROORZLQJEULHÀ\GLVFXVVHVWKHH[SHFWHGUROH of each type of context: • W-context of a Web service returns details on the participations of this Web service in different compositions. These participations occur in accordance with the Web services instantiation principle (Maamar, 2005). • C-context of a composite Web service is built upon the W-contexts of its component Web services and permits overseeing the progress of a composition. • U-context of an user monitors her current VWDWXVDQGUHÀHFWVKHUSHUVRQDOSUHIHUHQFHV like Web services execution time. • R-context of a resource oversees the execu - tion of the Web services that operate on top of this resource prior this latter accepts additional Web services for execution. A resource has computation capabilities that continuously change depending on the number of Web services that are now under execution and the execution duration of each Web service. It should be noted that num- ber of Web services is used for illustration purposes. Another criterion could be the execution load of Web services. When the different types of context are known and their expected role set, CP4WS proceeds next ZLWKWKHVSHFL¿FDWLRQRIWKHLQWHUQDOVWUXFWXUH Figure 4. Composite Web service for Amin scenario SCD-BS (Bus Schedule) SCD-LO (LOcation) SCD-IT (ITinerary) SCD-WE (WEather) SCD-TA (TAxi) SCD-TC (TraffiC) yes no [confirmed (bad weather)] (SCD: Service Chart Diagram) Data from previous Web services Performance Data for next Web services Previous Web services Next Web services Business out in State i State 1 380 A Context-Based and Policy-Driven Method to Design and Develop Composite Web Services of each context type. This means working out the relevant arguments that will populate this structure. It is expected that these arguments will be of different types like execution order of Web services, forthcoming execution of Web services, current location of users, next period of unavailability of resources, just to cite a few. In the following some arguments are suggested for the aforementioned types of context namely W/C/R/U-context. It should be noted that these arguments are not randomly selected, but based on our previous research on context-aware Web services (Maamar, 2006a; Maamar, 2005a; Maamar, 2005b; Maamar, 2006e). In addition to keep the article self-contained, only the internal structure of W-context is discussed. We recall that the studied case-study affects the number and type of context arguments. W-context encompasses the following argu- ments (Table 1): label, maximum number of active participations, number of active participations, next possibility of participation, resource&state per active participation, previous Web services per active participation, current Web services per active participation, next Web services per active participation, regular actions, reasons of failure per active participation, corrective actions per failure type and per active participation, and date. Table 1 also shows how some arguments get instantiated according to Amin scenario. C-context is built upon the W-contexts of its respective component Web services and consists of the following arguments: label, previous com- ponent Web services, current component Web services, next component Web services, status per component Web service, time, and date. It should be noted that status per component Web service argument is service-dependent since this argument’s value is collected from status argu- ment of W-context (Table 1). U-context consists of the following arguments: previous locations/component services, current location/component services, next locations/com- ponent services, previous periods of time/compo- nent services, current period of time/component services, next periods of time/component services, and date. R-context consists of the following argu- ments: label, maximum number of component Web services, number of active component Web services, next acceptance of component Web services, previous component Web services per active composition, current component Web services per active composition, consumption&state per component Web service and per active composition, next component Web services per active composi- tion, and date Web Services Behavior 6SHFL¿FDWLRQ6WHS :KHQXVHUQHHGVLGHQWL¿FDWLRQDQGVSHFL¿FDWLRQ Web services orchestration, and Web services contextualization steps are completed, the fourth step in CP4WS consists now of specifying the behavior of the component Web services that were LGHQWL¿HGDQGDVVHPEOHGWRJHWKHULQWKHVHFRQG VWHS$EHKDYLRULVH[SRVHGDQGVSHFL¿HGZLWKD set of attributes and policies, respectively. The role of policies is to make a Web service bind to a certain behavior as it will be shown in this section. CP4WS suggests the following attributes WRGH¿QHWKHEHKDYLRURID:HEVHUYLFHEDVHGRQ our previous research on policies for Web services (Maamar, 2006c): permission, restriction, and dispensation. Moreover CP4WS suggests adopting the Web Services Policy Language (WSPL) to specify policies (Anderson, 2004), although other policy VSHFL¿FDWLRQODQJXDJHVH[LVW'DPLDQRX Horrocks, 2004; Moses, 2003; Schlimmer, 2004) and could easily be integrated into CP4WS. Several criteria drive the selection of a policy VSHFL¿FDWLRQODQJXDJHDVUHSRUWHGLQ7RQWL expressiveness to support the wide range of policy requirements arising in the system being managed, VLPSOLFLW\WRHDVHWKHSROLF\GH¿QLWLRQWDVNVIRU people with various levels of expertise, enforceabil- 381 A Context-Based and Policy-Driven Method to Design and Develop Composite Web Services Table 1. Internal structure of W-context Argument & Description • LabelFRUUHVSRQGVWRWKHLGHQWL¿HURIWKH:HEVHUYLFH • Maximum number of active participations : corresponds to the maximum number of composi- tions in which the Web service can participate at a time. • Number of active participations : corresponds to the number of active compositions in which the Web service is now participating. • Next possibility of participation : indicates when the Web service can participate in a new composition. This is subject to the successful termination of the current active participations. • Resource&State per active participation FRUUHVSRQGVWRWKHLGHQWL¿HURIWKHVHOHFWHGUHVRXUFH and the state of the Web service in each active composition. State can be of types namely in- progress, suspended, aborted, or completed, and will be obtained out of the state argument of R-context of this resource. • Previous Web services per active participation : indicates the Web services that were success- fully completed before the Web service per active composition (null if there are no predeces- sors). • Current Web services per active participation : indicates the Web services that are concurrent- ly being performed with the Web service per active composition (null if there is no concurrent processing). • Next Web services per active participation : indicates the Web services that will be executed after the Web service successfully completes its execution per active composition (null if there are no successors). • Regular actions : illustrates the actions that the Web service normally performs. • Reasons of failure per active participation : informs about the reasons that are behind the failure of the execution of the Web service per active composition. • Corrective actions per failure type and per active participation : illustrates the actions that the Web service has performed due to execution failure per active composition. •Date LGHQWL¿HVWKHWLPHRIXSGDWLQJWKHDUJXPHQWVDERYH Application to Amin scenario •(Previous Web services per active participation: Weather_WS) - Weather Web service is H[HFXWHGDIWHU,WLQHUDU\:HEVHUYLFHDFFRUGLQJWRWKHVSHFL¿FDWLRQLQ)LJXUH •( Number of active participations: Weather_WS(4)) - Weather Web service is currently in- volved in four active composite Web services. This number of participation is constrained by the maximum number of active participations. 382 A Context-Based and Policy-Driven Method to Design and Develop Composite Web Services LW\WRHQVXUHDPDSSLQJRISROLF\VSHFL¿FDWLRQLQWR concrete policies for various platforms, scalability to guarantee adequate performance, and analyzability to allow reasoning about and over policies. ,Q WKHIROORZLQJZHGHVFULEH¿UVWKRZWKH DWWULEXWHV WKDW GH¿QH D :HEVHUYLFH¶V EHKDYLRU are interpreted and second, how a Web service ELQGVWRDVSHFL¿FEHKDYLRUIROORZLQJSROLF\ triggering. Details on the use of policies in Amin scenario are reported with some snapshots from the prototype. • Permission: a Web service accepts the invita - tion to participate in a composite Web service upon validation of its current engagements in other concurrent composite Web services. The validation process relies on the content of W-context (Table 1). • Restriction: a Web service cannot be or - chestrated with some peers in the same composite Web service because these peers do not satisfy this Web service's require- ments. These requirements could be related to non-functional details. • Dispensation: a Web service breaks some policies related to either permission or re- striction. In case of permission, this Web service will not participate in a composition despite the positive permission of participa- tion. In case of restriction, this Web service will be involved in an orchestration with some peers despite the existence of restric- tions. Permission Policy Permission authorizes a Web service to be part of a composite Web service. The following is a permis- sion policy in WSPL. It states that a Web service participates in a composition subject to evaluating <Condition> (line 04) to true. This condition refers to some arguments like number of current active participations of the Web service in compositions (line 07) and next possibility of participation of the Web service in additional compositions (line 12). Both arguments are part of the context of a Web service (Table 1). In the policy given below, <TrueConclusion> (line 16) shows the permission of participation, whereas <FalseConclusion> (line 17) shows the contrary. 01: Policy (Aspect=”Permission”) 02: <Rule xmlns=”urn:oasis:names:tc:xacml:3.0:gen- eralization:policy:schema:wd:01” 03: RuleId=”PermissionWS”> 04: <Condition> 05: <Apply FunctionId=”and”> 06: <Apply FunctionId=”integer-less-than” DataType=”boolean”> 07: <SubjectAttributeDesignator AttributeId=”Current NumberOfParticipations” 08: DataType=”integer”/> 09: <SubjectAttributeDesignator Attributeid=”Maximu mNumberOfParticipations” 10: DataType=”integer”/> 11: </Apply> 12: <SubjectAttributeDesignator AttributeId=”Availabi lity” DataType=”boolean”/> 13: </Apply> 14: </Condition> 15: <Conclusions> 16: <TrueConclusion Permission = “Permit”/> 17: <FalseConclusion Permission = “Deny”/> 18: </Conclusions> 19: </Rule> Restriction Policy Restrictions prevent a Web service to participate in composite Web services. They could be about the QoS (e.g., time of response, throughput) (Me- nasce, 2002) of the component Web services with whom a Web service will be interacting. It occurs that a Web service’s provider is only interested in WKH:HEVHUYLFHVWKDWKDYHD³JRRG´4R6UHFRUG The following illustrates a restriction policy in WSPL. It states that a Web service can be re- stricted from participation subject to evaluating <Condition> to true. This condition checks that 383 A Context-Based and Policy-Driven Method to Design and Develop Composite Web Services a positive permission of participation exists (line 06), a no-dispensation from participation exists too, and last but not least the assessment level of the QoS of the Web services is low (line 08). In this policy, QoSAssessment (line 09) is an integer value that is the result of evaluating the QoS of a Web service, and QoSThreshold (line 10) is the minimum QoS assessment value that is acceptable for a composition to happen. 01: Policy (Aspect=”Restriction”) 02: <Rule xmlns=”urn:oasis:names:tc:xacml:3.0:gen- eralization:policy:schema:wd:01” 03: RuleId=”RestrictionWS” 04: <Condition> 05: <Apply FunctionId=”and”> 06: <SubjectAttributeDesignator AttributeId=”YesPer mission” DataType=”boolean”/> 07: <SubjectAttributeDesignator AttributeId=”NoDisp ensationP” DataType=”boolean”/> 08: <Apply FunctionId=”integer-great-than-or- equal”> 09: <SubjectAttributeDesignator AttributeId=”QoSAs sessment” DataType=”integer”/> 10: <SubjectAttributeDesignator AttributeId=”QoSThr eshold” DataType=”integer”/> 11: </Apply> 12: </Apply> 13: </Condition> 14: <Conclusions> 15: <TrueConclusion Restriction = “No”/> 16: <FalseConclusion Restriction = “Yes”/> 17: </Conclusions> 18: </Rule> Dispensation Policy Dispensation allows a Web service to break poli- cies related to permission or restriction. Thus, dis- pensation is decomposed into permission-driven dispensation and restriction-driven dispensation. )RULOOXVWUDWLRQUHDVRQVZHRQO\GHVFULEHWKH¿UVW type. Although a Web service has been granted a permission to join in a composite Web service, a dispensation from participation can override this permission. One of the criteria that backs the dispensation is the composite Web service’s invocation period to the Web service. If this period was within the Web service’s peak-time period of receiving invocation requests, the Web service could cancel the permission of participation. This could affect the QoS this Web service guarantees to composite Web services. The following illus- trates a permission-driven dispensation policy in WSPL. It states that a Web service cancels a permission of participation subject to evaluating <Condition> to true. This latter checks that such a permission exists (line 06) and the invocation- request time does not fall in the peak time-period of the Web service (lines 07, 08, 09). 01 : Policy (Aspect=”DispensationPermission”) 02 : <Rule xmlns=”urn:oasis:names:tc:xacml:3.0:gen- eralization:policy:schema:wd:01” 03: RuleId=”DispensationPermissionWS”> 04: <Condition> 05: <Apply FunctionId=”and”> 06: <SubjectAttributeDesignator AttributeId=”YesPer mission” DataType=”boolean”/> 07: <Apply FunctionId=”equal”> 08: <SubjectAttributeDesignator AttributeId=”PeakTime” DataType=”integer”/> 09: <SubjectAttributeDesignator AttributeId=”Reques tTime” DataType=”integer”/> 10: </Apply> 11: </Apply> 12: </Condition> 13: <Conclusions> 14: <TrueConclusion Permission = “Deny”/> 15: <FalseConclusion Permission = “Permit”/> 16: </Conclusions> 17 </Rule> Web Services Deployment Step 7KH ¿IWK DQG ODVW VWHS LQ &3:6 FRQVLVWV RI managing the performance of Web services on top of computing resources. The rationale of this . 374 A Context-Based and Policy-Driven Method to Design and Develop Composite Web Services been developed like WSDL, SOAP, and UDDI (Curbera, 2002). On the other hand, several projects related. the members of the design team and with end-users, respectively. In this chapter we propose our design and develop- ment method CP4WS, which stands for Context and Policy for Web Services. CP4WS. Web and Boolean combinations of policy predicates. Rationale of Context and Policies We argue the use of context and policies in CP4WS with the following two points: • Context collects and