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