Zakaria Maamar
, Djamal Benslimane
and Chirine Ghedira
Zayed University, Dubai, United Arab Emirates
Claude Bernard Lyon 1 University, Lyon, France
Design, Development, Method, Web Service.
This paper presents C P 4W S (standing for C ontext and P olicy for W eb S ervices), which is a context-based
and policy-driven method for the design and development of Web services-based systems. Although Web
services constitute an active area of research, very little has been achieved for the benefit of those who are re-
sponsible for modeling and developing such systems. To address this lack of support, we developed C P 4W S
that consists of several steps ranging from user needs identification to Web services behavior specification. A
running scenario that illustrates the use of C P 4W S is also discussed in the paper.
Overview. For the W3C, a Web service is a soft-
ware application identified by a URI, whose inter-
faces and binding are capable of being defined, de-
scribed, and discovered by XML artifacts and sup-
ports direct interactions with other software applica-
tions using XML-based messages via Internet-based
applications. Web services R&D have to a certain ex-
tent revolved around the following aspects: descrip-
tion, discovery, and composition. Several standards
related to Web services definition, discovery, etc.,
have been developed, and several projects related to
Web services composition, personalization, etc., have
been kicked-off.
In this paper, we shed the light on another as-
pect that concerns design and development meth-
ods. The objective, here, is to assist people in de-
signing and developing Web services-based systems.
Nowadays, designers and developers are put on the
front line of satisfying the promise of Web services’
providers to deliver a new generation of B2B sys-
tems. Simply put, a method comprises a set of
steps to carry out and comply with according to a
certain chronology. Each step has usually a repre-
sentation formalism that facilitates discussions and
validation exercises among the design team’s mem-
bers and with end-users, respectively. Our proposed
C P 4W S for C ontext and P olicy for W eb
S ervices, is built upon our previous research on Web
services (Maamar et al., 2006a; Maamar et al., 2005).
C P 4W S uses two major concepts: policy and con-
text. First, policies handle various aspects related to
Web services including participation in composition,
semantic mediation, and adjustment due to changes in
the environment. Second, context provides the nec-
essary information that enables for instance to trig-
ger the appropriate policies and to regulate the inter-
actions between Web services according to the cur-
rent state of the environment. In
C P 4W S , an ex-
tra element namely resource is part of the design and
development exercise. A resource is a computing
means upon which a Web service operates. Because
resources need to schedule the execution requests of
Web services, these latter have to be constantly aware
of the capabilities and limitations of the resources
they require.
Definitions and motivation. Policies are defined
as information which can be used to modify the behav-
ior of a system (Lupu and Sloman, 1999). Our defi-
nition goes beyond behavior modification and consid-
ers policies as external, dynamically modifiable rules
and parameters that are used as input to a system.
This permits to the system to adjust to administra-
tive decisions and changes in the execution environ-
ment (Maamar et al., 2006b). In the field of Web ser-
vices, policies specify different aspects of the behav-
ior of a Web service so, this one can align its capabili-
Maamar Z., Benslimane D. and Ghedira C. (2007).
In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 453-458
DOI: 10.5220/0002349804530458
ties to users’ requirements and resources’ constraints.
Context ... is not simply the state of a prede-
fined environment with a fixed set of interaction re-
sources. It is part of a process of interacting with
an ever-changing environment composed of recon-
figurable, migratory, distributed, and multiscale re-
sources (Coutaz et al., 2005). In the field of Web
services, context supports the development of adapt-
able Web services so, these latter become aware of
the environment in which they operate. Several Web
services’ standards are now enriched with contextual
details (Keidl and Kemper, 2004).
We argue the value-added of context and policies
C P 4W S for supporting Web services composition
with the following points:
1. Context provides useful information concerning
the environment wherein the composition of Web
services occurs. This information tracks the com-
position process by enabling for instance to trig-
ger the appropriate policies and to regulate the in-
teractions between Web services according to the
current state of the environment and the current
constraints such as performance, security, etc.
2. Policies separate guidelines for conducting com-
position from guidelines for defining Web ser-
vices. Guidelines for 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 Web services concern
among other things how to exchange comprehen-
sible information between Web services, how to
deal with a Web service non-reliability, and how
to suspend a Web service execution due to risks of
behavior alteration or information interception?
It is made clear at this stage of the paper that our
motivation do not aim at suggesting any new compo-
sition approach of Web services. Our aim is to suggest
a set of steps that designers follow while designing
and developing Web services-based systems. It will
also be shown later that the various available stan-
dards like WSDL and BPEL can easily be integrated
into these steps.
Paper organization. Section 1 motivates the role
of design and development methods in Web services
and defines some basic concepts. Section 2 presents
the different steps that constitute
C P 4W S . For illus-
tration purposes, a motivating scenario is suggested in
this section. Section 3 reviews the prototype that im-
plements the motivating scenario. Related work and
concluding remarks are presented and drawn in Sec-
tion 4 and Section 5, respectively.
2.1 Motivating Scenario
Our motivating scenario concerns Amin who is vis-
iting Melissa in Oslo. Amin and Melissa agree on
a certain day to meet in a coffee shop, not far from
Melissa’s office since she finishes work late on this
day. Amin has two options to reach the meeting place:
by taxi or by bus. For illustration purposes we iden-
tify some potential Web services that will take over
the implementation of this scenario.
At his hotel, Amin browses some Web sites about
transport in Oslo. A site has
Itinerary WS
that pro-
poses routes between for example Amin’s hotel and
the coffee shop. The proposed routes are subject to
weather forecasts and traffic jams. Cold weather re-
sults in recommending taxis, otherwise public trans-
port like tramways and buses are recommended. Par-
allel to consulting
Weather WS
about weather fore-
Itinerary WS
requests details about the origin
and destination places using
Location WS
. In case
Weather WS
returns bad weather, a taxi booking is
made using
Taxi WS
upon Amin’s approval. Other-
wise, Amin uses public transport. The location of
both Amin’s hotel and coffee shop are submitted to
Bus Schedule WS
, which returns the buses’ numbers
Amin has to ride. Potential traffic jams in Oslo force
Bus Schedule WS
to regularly interact with
that monitors the state of the traffic network. This
state is submitted to
Bus Schedule WS
so, changes
in buses’ numbers are made.
Amin scenario yields insight into the multiple
challenges that designers of Web services-based sys-
tems face. Some challenges include: how to identify
the relevant Web services, how to orchestrate the Web
services as part of their composition, how to make the
Web services context-aware, how to use policies to
define the behavior of the Web services, and how to
run the Web services subject to resource availability?
2.2 C P 4W S Steps
This section details the steps that make up
C P 4W S
and illustrates them based on Amin scenario.
Step 1 - User needs identification and specifica-
tion. It consists of identifying and specifying user
needs. Traditional techniques that permit identify-
ing user needs and requirements are used in
C P 4W S
such as interviews with end-users, information col-
lection on similar applications, and literature review.
Regarding the specification technique of user needs,
C P 4W S adopts UML use-cases. This has several ad-
vantages: most designers are familiar with use-cases,
ICEIS 2007 - International Conference on Enterprise Information Systems
identified use-cases could be mapped onto potential
Web services, and interactions between use-cases are
an excellent indicator of the composition-based col-
laboration between future Web services.
Fig. 1 presents a part of the use-case model we de-
veloped for Amin scenario. Several actors are shown
like Amin, Melissa, weather forecast agency, and
transport agency. In addition, several use-cases are
identified like itinerary development, weather fore-
cast establishment, and traffic monitoring. The same
figure shows how some use-cases interact with each
other, e.g., itinerary development use-case ”uses”
traffic monitoring use-case.
W. forecast
Weather Forecast
Figure 1: Part of Amin scenario’s UML use-cases.
Step 2 - Web services orchestration. It consists
of specifying the orchestration of the Web services
that will constitute a composite Web service. The
types (in term of functionality) of the required Web
services are already identified based on the outcome
of user needs identification and specification step. We
recall that a use-case is a potential candidate to be
mapped onto a Web service, although the mapping is
not always one-to-one.
C P 4W S , the Web services orchestration step
relies on the concept of service chart diagram.
This diagram enhances an UML state chart dia-
gram (Booch, G. and Rumbaugh, J. and Jacobson, I.,
1998) with emphasis on the elements that surround
the execution of a Web service rather than only on the
states that a Web service takes. To this purpose, the
states of a Web service are wrapped into ve perspec-
tives: state, flow, business, information, and perfor-
mance. Additional details on service chart diagrams
are given in (Maamar et al., 2005).
(SCD: Service Chart Diagram)
Figure 2: Orchestration of Web services in Amin scenario.
Because a composite Web service is made up of
several component Web services, the process model
that underlies the composite Web service orchestra-
tion is specified as an UML state chart diagram. In
this diagram, states are associated with service chart
diagrams, and transitions are labeled with events, con-
ditions, and variable assignment operations. Fig. 2
shows the specification of the composite Web ser-
vice, i.e., Web services orchestration, we developed
for Amin scenario. Three component Web services
are listed: ITineray (IT), WEather (WE), and LOca-
tion (LO). It should be noted that service chart dia-
grams and state chart diagrams are used at the design
level. At the implementation level, both diagrams
could for example be mapped onto a BPEL specifi-
Step 3 - Web services contextualization. It con-
sists of structuring and specifying the contexts of the
multiple participants that take part in Web services
composition. In addition to Web services as default
C P 4W S considers the following addi-
tional participants (Maamar et al., 2005): compos-
ite Web service, resource, and user. Each participant
has a context that is labeled as follows:
W -context
for context of
W eb service, C -context for context
C omposite Web service, R -context for context of
R esource, and U -context for context of U ser. The
specification of each type of context means defining
the arguments that will populate the context structure.
C P 4W S context returns details of various lev-
els of granularity. These details are for example on
Web services like execution order, on composite Web
services like forthcoming executions of Web services,
on users like current locations, and on resources like
next periods of unavailability. It will be shown in the
next step in
C P 4W S how all these contextual details
affect the process of loading and firing policies. To
keep the paper self-contained, we only list the argu-
ments per type of context. These arguments will be
later instantiated according to the application domain.
W -context encompasses the following argu-
ments: label, maximum number of active participa-
tions, number of active participations, next possibility
of participation, resource&state per active participa-
tion, 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.
C -context is built upon the W -contexts of the
component Web services and consists of the follow-
ing arguments: label, previous component Web ser-
vices, current component Web services, next compo-
nent Web services, status per component Web service,
time, and date. It should be noted that status per com-
ponent Web service argument is service-dependent
since this argument’s value is collected from status
argument of
W -context.
R -context consists of the following arguments:
label, maximum number of component Web services,
number of active component Web services, next ac-
ceptance of component Web services, previous com-
ponent Web services per active composition, current
component Web services per active composition, con-
sumption&state per component Web service and per
active composition, next component Web services per
active composition, and date
U -context consists of the following arguments:
previous locations/component services, current loca-
tion/component services, next locations/component
services, previous periods of time/component ser-
vices, current period of time/component services,
next periods of time/component services, and date.
Step 4 - Web services behaviors specification.
It consists of specifying the behavior of the Web ser-
vices that were identified in Step 2. A behavior is
first, exposed with a set of attributes and second, spec-
ified with a set of policies.
C P 4W S uses the fol-
lowing attributes to define the behavior of a Web ser-
vice: permission, restriction, dispensation, and obli-
C P 4W S suggests, also, the use of the Web
Services Policy Language (WSPL) for policy speci-
fication (Anderson, 2004). The syntax of WSPL is
strictly based on the OASIS eXtensible Access Con-
trol Markup Language (XACML) standard. Other
policy specification languages like Ponder and WS-
Policy could also be used.
In the following, we describe first, how the at-
tributes that define a Web service’s behavior are inter-
preted and second, how a Web service binds a certain
behavior as a result of policy triggering.
- Permission: a Web service accepts the invitation
of participation in a composite Web service upon
validation of its current engagements in other con-
current composite Web services. This acceptance
is backed by executing the appropriate policies.
- Restriction: a Web service is not allowed to con-
nect some peers of a composite Web service due
to non-compliance of these peers with this Web
service’s requirements.
- Dispensation: a Web service breaks some policies
related to either permission or restriction. In case
of permission, the Web service will not participate
in a composition despite the positive permission
of participation. In case of restriction, the Web
service will be connected to some peers despite
the existence of restrictions.
- Obligation: this is a strong permission for a Web
service to participate in a composite Web service
despite the negative permission of participation
or the existence of restrictions from participation.
Obligations override dispensations of types per-
mission and restriction.
To keep again the paper self-contained, we show
how permission policy is defined in
C P 4W S us-
ing WSPL. Permission authorizes a Web service to
be part of a composite Web service. It states that
a Web service participates in a composition sub-
ject to evaluating <Condition> to true. This condi-
tion refers to some
W -context’s arguments like num-
ber of current active participations of the Web ser-
vice in compositions and next possibility of partic-
ipation of the Web service in additional composi-
tions. <True/FalseConclusion> shows the permis-
sion/rejection of participation, ”CrtNbrPar” stands for
current number of participation, and ”MaxNbrPar”
stands for maximum number of participation.
) {
<Rule xmlns="..." RuleId="PermissionWS">
<Apply FunctionId="and">
<Apply FunctionId="integer-less-than" DataType="boolean">
<SubjectAttributeDesignator AttributeId="CrtNbrPar".../>
<SubjectAttributeDesignator Attributeid="MaxNbrPar".../>
<SubjectAttributeDesignator AttributeId="Availability".../>
<TrueConclusion Permission = "Permit"/>
<FalseConclusion Permission = "Deny"/>
</Conclusions> </Rule>
Step 5 - Web services deployment. It consists
of managing the performance of Web services on top
of computing resources. The rationale of this step is
to satisfy the needs of providers who have interests
and/or obligations in strengthening or restricting the
execution of Web services on their resources. For
instance, a Web service is not accepted for execu-
tion on a resource because of this Web service’s no-
compliance with the resource’s requirements such as
agreed execution-time.
C P 4W S suggests managing the deployment of
Web services on resources with policies. For stan-
dardization purposes with the policies of Web ser-
vices’ behaviors, WSPL is also adopted to specify
these policies. A deployment policy for permission
is about a Web service that receives the necessary
authorizations from a resource to be executed over
this resource. The authorizations are based on the
state of the resource, which is reflected using its re-
R -context. The following illustrates a de-
ployment policy for permission in WSPL. It states
ICEIS 2007 - International Conference on Enterprise Information Systems
that a resource accepts the execution request of a
Web service subject to evaluating <Condition> to
true. This condition refers to some arguments like
number of active component Web services that the
resource supports their execution and next accep-
tance of the resource for additional component Web
services. In the policy, <True/FalseConclusion>
shows the positive/negative permission of execution,
”NbrActWS” stands for number of active Web ser-
vices, ”MaxWS” stands for maximum number of Web
services, and ”NxtAcc” stands for next acceptance of
Web services. In case of positive permission of exe-
cution, yes-permission-deployment procedure is exe-
cuted, which results in updating the following argu-
ments: resource&state per active participation of
W -
context of the Web service and number of active com-
ponent Web services of R -context of the resource.
) {
<Rule xmlns=" ... RuleId="PermissionDeploymentWS">
<Apply FunctionId="and">
<Apply FunctionId="integer-less-than" DataType="boolean">
<SubjectAttributeDesignator AttributeId="NbrActWS" ...
<SubjectAttributeDesignator AttributeId="MaxWS"...
<SubjectAttributeDesignator AttributeId="NxtAcc" ...
<proc:do> yes-permission-deployment </proc:do>
<proc:do> no-permission-deployment </proc:do>
We discuss the work we carried out as part of the im-
plementation of Amin scenario using C P 4W S . For
compatibility purposes, we used Sun Microsystems’s
tools namely J2EE 1.4 to develop Web services and
XACML Open Source to develop policies.
The prototype architecture comprises 4 types of
managers. The
specification manager
designers during the specification of composite Web
services. This requires identifying the appropriate
component Web services. The specification work is
carried out through a
composition environment
which is a set of integrated tools that assist design-
ers in creating and editing new and existing specifi-
cations of composite Web services, respectively. We
use a composition environment that was developed in
a previous project (Maamar et al., 2005). This en-
vironment, also, supports translating composite Web
service specifications, like the one shown in Fig. 2,
into BPEL specification. The
selection manager
is responsible for identifying the component Web ser-
vices that satisfy user needs. This manager is trigged
upon user’s request, who identifies the appropriate
composite Web service specification. In the current
system, the selection is not only driven by the result-
ing functionality of the composition the user needs
(e.g., to reach a meeting place by taxi or by bus ac-
cording to weather conditions). It also considers Web
services’ QoS parameters that affect the selection pro-
cess like response time, performance, and through-
put. These constraints are expressed with WSPL poli-
cies. The
policy manager
makes Web services
bind appropriate behaviors according to a composi-
tion progress.
Finally, the
context manager
keeps track of the
contexts of users, Web services, and resources. Con-
texts’ arguments are of different types and their val-
ues change over time. Therefore the context man-
ager is supported with a real-time triggering mech-
anism that feeds context parameters with fresh val-
ues. Details of contexts are structured as XML files.
Before sending the selected Web services’ addresses
to the user for invocation, the
policy manager
sures that these Web services comply with the differ-
ent policies. Upon approval of the
policy manager
selection manager
initiates the search of the re-
sources on which the Web services will operate.
Web services are a very active area of R&D. How-
ever, to our knowledge, few projects have aimed at
suggesting design and development methods for Web
services based on context and driven by policies. We
present in the following some projects that helped
C P 4W S . These projects are related to either
context or policies for Web services.
C P 4W S , context is part of the modeling ex-
ercise of a system based on Web services. Other
projects such as (Breener and Schiffers, 2003) use
Web services for managing context provisioning.
Breener and Schiffers envision that context informa-
tion will typically be provided by autonomous orga-
nizations (or context providers), which means hetero-
geneity and distribution challenges to deal with. Ad-
ditional challenges are cited in (Breener and Schif-
fers, 2003) including what is the optimal sequence for
gathering and combining the required context infor-
mation, how to secure the whole context provision-
ing process, and how is the cooperation between the
providers of context achieved, and even enforced?
Barkhuus and Dey identified three levels of in-
teractivity for context-aware applications (Barkhuus
and Dey, 2003): personalization, active context-
awareness, and passive context-awareness. For both
authors, personalization is motivated by the diver-
sity and dynamics featuring nowadays applications.
For active context-awareness, it concerns applications
that, on the basis of sensor data, change their content
autonomously. In passive context-awareness applica-
tions present the updated context to the user and let
the user specify how the application should change.
In (Baresi et al., 2005), Baresi et al. proposed a
policy-based approach to monitor Web services’ func-
tional (e.g., constraints on exchanged data) and non-
functional (e.g., security, reliability) requirements. In
this approach the authors report on the different types
of policies that can be defined along the life cycle of
a Web service (Mukhi et al., 2004). These policy
types are service policies, server policies, supported
policies, and requested policies. The combination of
requested and supported policies results in effective
In this paper, we presented
C P 4W S method, which
is one step towards offering the appropriate support
to those who are responsible for the design and devel-
opment of Web services-based systems. Composition
of Web services addresses the situation of a user’s re-
quest that cannot be satisfied by any single, available
Web service, whereas a composite Web service ob-
tained by combining a set of available Web services
might be used. The core concepts of
C P 4W S are
context, policy, service chart diagram, state chart di-
agram, and resource. By developing context-based,
policy-driven Web services, it would be possible to
handle the aspects of the environment in which these
Web services will operate. These aspects are multi-
ple and can be related to users (e.g., stationary, mo-
bile), time of day (e.g., in the afternoon, in the morn-
ing), etc.
C P 4W S development benefited from the discus-
sions the authors had with A. Anderson, G. Kouadri-
efaoui, S. Sattanathan, and Ph. Thiran.
Anderson, A. H. (2004). An Introduction to The Web Ser-
vices Policy Language (SWPL). In Proceedings of
The 5th IEEE International Workshop on Policies for
Distributed Systems and Networks (POLICY’2004),
New-York, USA.
Baresi, L., Guinea, S., and Plebani, P. (2005). WS-Policy
for Service Monitoring. In Proceedings of The 6th
Workshop on Technologies for E-Services (TES’2005)
held in conjunction with The 31st International Con-
ference on Very Large Data Bases (VLDB’2005),
Throndeim, Norway.
Barkhuus, L. and Dey, A. (2003). Is Context-Aware Com-
puting taking Control away from The User? Three
levels of Interactivity Examined. In Proceedings
of The Fifth International Conference on Ubiqui-
tous Computing (UbiComp’2003), Seattle, Washing-
ton, USA.
Booch, G. and Rumbaugh, J. and Jacobson, I. (1998)). The
Unified Modeling Language User Guide . Addison-
Wesley Professional.
Breener, M. and Schiffers, M. (2003). Applying Web Ser-
vices Technologies to the Management of Context
Provisioning. In Proceedings of The 10th Workshop
of the OpenView University Association (OVUA2003),
Geneva, Switzerland.
Coutaz, J., Crowley, J. L., Dobson, S., and Garlan, D.
(2005). Context is Key. Communications of the ACM,
Keidl, M. and Kemper, A. (2004). A Framework for
Context-Aware Adaptable Web Services. In Proceed-
ings of The 9th International Conference on Extend-
ing Database Technology (EDBT’2004), Heraklion,
Lupu, E. and Sloman, M. (1999). Conflicts in Policy-Based
Distributed Systems Management. IEEE Transactions
on Software Engineering, 25(6).
Maamar, Z., Benslimane, B., Mrissa, M., and Ghedira, C.
(2006a). C ooP S - Towards a Method for Coordi-
nating Personalized Services. Software and System
Modeling Journal Special Section on ”Service-Based
Software and Systems Engineering”, Springer Verlag,
Maamar, Z., Benslimane, D., and Anderson, A. (2006b).
Using Policies to Manage Composite Web Services.
IEEE IT Professional, 8(5).
Maamar, Z., Kouadri Most
efaoui, S., and Yahyaoui, H.
(2005). Towards an Agent-based and Context-
oriented Approach for Web Services Composition.
IEEE Transactions on Knowledge and Data Engineer-
ing, 17(5).
Mukhi, N., Plebani, P., Silva-Lepe, I., and Mikalsen, T.
(2004). Supporting Policy-Driven Behaviors in Web
Services: Experiences and Issues. In Proceedings of
The 2nd International Conference on Service Oriented
Computing (ICSOC’2004), New York City, NY, USA.
ICEIS 2007 - International Conference on Enterprise Information Systems