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
Trang 1been 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
WKDWFDQQRWEHVDWLV¿HGE\DQ\VLQJOHDYDLODEOH
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\VWHPV6LPSO\SXWDPHWKRGFRPSULVHV¿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 UHVRXUFHLGHQWL¿HVDFRPSXWLQJPHDQVHJVRIW-ware and hardUHVRXUFHLGHQWL¿HVDFRPSXWLQJPHDQVHJVRIW-ware 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 7KHQH[WVHFWLRQGH¿QHVSROLF\DQGFRQWH[WFRQ-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³LVQRWVLPSO\WKHVWDWHRIDSUHGH¿QHG
HQYLURQPHQW ZLWK D ¿[HG VHW RI LQWHUDFWLRQ UH-sources It is part of a process of interacting
Trang 2with an ever-changing environment composed
RI UHFRQ¿JXUDEOH PLJUDWRU\ GLVWULEXWHG DQG
multiscale resources” (Coutaz, 2005) In the
¿HOGRI:HEVHUYLFHVFRQWH[WVXSSRUWVWKHGH-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
VXUURXQGLQJHQYLURQPHQWDVWKH\ZRXOGEHÀ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
3ROLFLHVDUHGH¿QHGDV³information which can
be used to modify the behavior of a system” (Lupu,
2XU GH¿QLWLRQ LQ 0DDPDU JRHV
EH\RQGEHKDYLRUPRGL¿FDWLRQDQGFRQVLGHUVSROL-FLHVDVH[WHUQDOG\QDPLFDOO\PRGL¿DEOHUXOHVDQG
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¿HOGRI:HEVHUYLFHVSROLFLHVDUHLQWHQGHGWR
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\DJUHHPHQWYHUL¿FDWLRQDQGFRPSRVLWLRQ)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 :HEVHUYLFHVGH¿QLWLRQFRQFHUQDPRQJRWKHU things how to announce Web services to po-tential users, how to deal with Web services
Trang 3non-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
IRUHFDVWVDQGWUDI¿FMDPV&ROGZHDWKHUUHVXOWV
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 BusScheduleWS, which
returns the numbers of buses that Amin will have
WRULGH3RWHQWLDOWUDI¿FMDPVLQ2VORIRUFHBusS-cheduleWS to regularly interact with 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-WLRQH[HUFLVHV,QWKLVVHFWLRQZHGHWDLOWKH¿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
8VHU1HHGV,GHQWL¿FDWLRQ$QG
6SHFL¿FDWLRQ6WHS
7KH¿UVWVWHSLQ&3:6FRQVLVWVRILGHQWLI\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¿FDWLRQWHFKQLTXHRIXVHUV¶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 IDPLOLDUZLWKXVHFDVHV LL LGHQWL¿HGXVHFDVHV could be mapped onto potential Web services, and (iii) interactions between use-cases are an excellent indicator of the composition-based collaboration EHWZHHQWKHLGHQWL¿HG:HEVHUYLFHV,WVKRXOGEH
Trang 4QRWHGWKDWWKHLGHQWL¿FDWLRQRIWKHDSSURSULDWHDF-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
XVHFDVHVDUHLGHQWL¿HGOLNHItinerary
Develop-ment, Weather Forecast EstablishDevelop-ment, and
7UDI¿F0RQLWRULQJ7KHVDPH¿JXUHVKRZVWKH
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-WLRQRIWKHWUDI¿FWKDWDUHREWDLQHGRXWRI7UDI¿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 XVHFDVH 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
8VHUQHHGVLGHQWL¿FDWLRQDQGVSHFL¿FDWLRQVWHS
• 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.
5HSUHVHQWDWLRQIRUPDOLVP QXOO QRWDVSHFL¿FRQH
:HEVHUYLFHVEHKDYLRUVSHFL¿FDWLRQVWHS
• 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.
Trang 5The 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
RID:HEVHUYLFHDUHZUDSSHGLQWR¿YHSHUVSHFWLYHV
The state perspective corresponds to a regular UML
VWDWHFKDUWGLDJUDPRIWKH:HEVHUYLFH7KHÀRZ
perspective corresponds to the chronology of the
composite Web service in which the Web service
SDUWLFLSDWHV7KHEXVLQHVVSHUVSHFWLYHLGHQWL¿HVWKH
different organizations that make the Web service
DYDLODEOH7KHLQIRUPDWLRQSHUVSHFWLYHLGHQWL¿HVWKH
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 RIWKLVFRPSRVLWH:HEVHUYLFHLVVSHFL¿HGDVDQ 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
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
B
State j
E
out
Trang 6Bus Schedule (BS DQG 7UDI¿& TC) In this
¿JXUH>FRQ¿UPHG EDGZHDWKHU @LVDQH[DPSOH
of a constraint over a transition We recall that
ITinerayWS is associated with Itinerary
Develop-PHQWXVHFDVHDVGH¿QHGLQSUHYLRXVO\
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
SDUWLFLSDQWVFRXOGEHDGGHGDVSHUWKHVSHFL¿FUH-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
DIIHFWVWKHSURFHVVRIORDGLQJDQG¿ULQJSROLFLHV
7KHIROORZLQJEULHÀ\GLVFXVVHVWKHH[SHFWHGUROH
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 VWDWXVDQGUHÀHFWVKHUSHUVRQDOSUHIHUHQFHV 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
Data for next Web services
Previous Web services
Next Web services Business
out in
State i State 1
Trang 7of 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 comcom-ponent 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/compotime/compo-nent 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¿FDWLRQ6WHS
:KHQXVHUQHHGVLGHQWL¿FDWLRQDQGVSHFL¿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¿HGDQGDVVHPEOHGWRJHWKHULQWKHVHFRQG VWHS$EHKDYLRULVH[SRVHGDQGVSHFL¿HGZLWKD 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 WRGH¿QHWKHEHKDYLRURID:HEVHUYLFHEDVHGRQ 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¿FDWLRQODQJXDJHVH[LVW 'DPLDQRX Horrocks, 2004; Moses, 2003; Schlimmer, 2004) and could easily be integrated into CP4WS Several criteria drive the selection of a policy VSHFL¿FDWLRQODQJXDJHDVUHSRUWHGLQ 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,
Trang 8enforceabil-Table 1 Internal structure of W-context
Argument & Description
• Label FRUUHVSRQGVWRWKHLGHQWL¿HURIWKH:HEVHUYLFH
• 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 FRUUHVSRQGVWRWKHLGHQWL¿HURIWKHVHOHFWHGUHVRXUFH 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¿HVWKHWLPHRIXSGDWLQJWKHDUJXPHQWVDERYH
Application to Amin scenario
• (Previous Web services per active participation: Weather_WS) - Weather Web service is
H[HFXWHGDIWHU,WLQHUDU\:HEVHUYLFHDFFRUGLQJWRWKHVSHFL¿FDWLRQLQ)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
Trang 9concrete policies for various platforms, scalability to
guarantee adequate performance, and analyzability
to allow reasoning about and over policies
,QWKHIROORZLQJZHGHVFULEH¿UVWKRZWKH
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: < A p p l y F u n c t i o n I d = ” i n t e g e r - l e s s - t h a n ” 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:HEVHUYLFHVWKDWKDYHD³JRRG´4R6UHFRUG 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
Trang 10a 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: <A pply Func tionId=”integer- great-than -
or-equal”>
09: <SubjectAttributeDesignator AttributeId=”QoSAs
sessment” DataType=”integer”/>
10: <SubjectAttributeDesignator AttributeId=”QoSThr
eshold” DataType=”integer”/>
11: </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
)RULOOXVWUDWLRQUHDVRQVZHRQO\GHVFULEHWKH¿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: < S u b j e c t A t t r i b u t e D e s i g n a t o r 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
... the preferences ofusers and the requirements of resources Policies
are also intended to frame interactions between
Web services and users, and between Web services
themselves... 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... 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