C P 4W S - A METHOD FOR DESIGNING AND DEVELOPING

SYSTEMS BASED ON WEB SERVICES

Zakaria Maamar

, Djamal Benslimane

and Chirine Ghedira

Zayed University, Dubai, United Arab Emirates

Claude Bernard Lyon 1 University, Lyon, France

Keywords:

Design, Development, Method, Web Service.

Abstract:

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 beneﬁt 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 identiﬁcation to Web services behavior speciﬁcation. A

running scenario that illustrates the use of C P 4W S is also discussed in the paper.

1 INTRODUCTION

Overview. For the W3C, a Web service is a soft-

ware application identiﬁed by a URI, whose inter-

faces and binding are capable of being deﬁned, 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 deﬁnition, 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

method,

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.

Deﬁnitions and motivation. Policies are deﬁned

as information which can be used to modify the behav-

ior of a system (Lupu and Sloman, 1999). Our deﬁ-

nition goes beyond behavior modiﬁcation and consid-

ers policies as external, dynamically modiﬁable 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 ﬁeld of Web ser-

vices, policies specify different aspects of the behav-

ior of a Web service so, this one can align its capabili-

453

Maamar Z., Benslimane D. and Ghedira C. (2007).

C P 4W S - A METHOD FOR DESIGNING AND DEVELOPING SYSTEMS BASED ON WEB SERVICES.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 453-458

DOI: 10.5220/0002349804530458

 SciTePress

ties to users’ requirements and resources’ constraints.

Context ”... is not simply the state of a prede-

ﬁned environment with a ﬁxed set of interaction re-

sources. It is part of a process of interacting with

an ever-changing environment composed of recon-

ﬁgurable, migratory, distributed, and multiscale re-

sources” (Coutaz et al., 2005). In the ﬁeld 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 deﬁning 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 deﬁnes 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 DESIGN STEPS IN C P 4W S

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 ofﬁce since she ﬁnishes 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 trafﬁc 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-

casts,

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 trafﬁc jams in Oslo force

Bus Schedule WS

to regularly interact with

Traffic

that monitors the state of the trafﬁc 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

deﬁne 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 identiﬁcation and speciﬁca-

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 speciﬁcation 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

454

identiﬁed 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

identiﬁed like itinerary development, weather fore-

cast establishment, and trafﬁc monitoring. The same

ﬁgure shows how some use-cases interact with each

other, e.g., itinerary development use-case ”uses”

trafﬁc monitoring use-case.

Itinerary

development

W. forecast

establishment

Traffic

monitoring

Weather Forecast

agency

Amin

Transporation

agency

uses

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 identiﬁed based on the outcome

of user needs identiﬁcation and speciﬁcation 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, ﬂow, business, information, and perfor-

mance. Additional details on service chart diagrams

are given in (Maamar et al., 2005).

SCD-LO

(LOcation)

SCD-IT

(ITinerary)

SCD-WE

(WEather)

(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 speciﬁed 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 speciﬁcation 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 speciﬁ-

cation.

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

participant,

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

speciﬁcation of each type of context means deﬁning

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 ﬁring 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-

CP4WS - A METHOD FOR DESIGNING AND DEVELOPING SYSTEMS BASED ON WEB SERVICES

455

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 speciﬁcation.

It consists of specifying the behavior of the Web ser-

vices that were identiﬁed in Step 2. A behavior is

ﬁrst, exposed with a set of attributes and second, spec-

iﬁed with a set of policies.

C P 4W S uses the fol-

lowing attributes to deﬁne the behavior of a Web ser-

vice: permission, restriction, dispensation, and obli-

gation.

C P 4W S suggests, also, the use of the Web

Services Policy Language (WSPL) for policy speci-

ﬁcation (Anderson, 2004). The syntax of WSPL is

strictly based on the OASIS eXtensible Access Con-

trol Markup Language (XACML) standard. Other

policy speciﬁcation languages like Ponder and WS-

Policy could also be used.

In the following, we describe ﬁrst, how the at-

tributes that deﬁne 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 deﬁned 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.

Policy

(

Aspect="Permission"

) {

</Apply>

</Apply>

</Condition>

</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 reﬂected using its re-

spective

R -context. The following illustrates a de-

ployment policy for permission in WSPL. It states

ICEIS 2007 - International Conference on Enterprise Information Systems

456

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.

Policy

(

Aspect="PermissionDeployment"

) {

<SubjectAttributeDesignator AttributeId="NbrActWS" ...

<SubjectAttributeDesignator AttributeId="MaxWS"...

</Apply>

<SubjectAttributeDesignator AttributeId="NxtAcc" ...

</Apply>

</Condition>

<proc:do> yes-permission-deployment </proc:do>

</TrueConclusion>

<proc:do> no-permission-deployment </proc:do>

</FalseConclusion>

</Conclusions>

</Rule>

}

3 IMPLEMENTATION OF AMIN

SCENARIO

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

supports

designers during the speciﬁcation of composite Web

services. This requires identifying the appropriate

component Web services. The speciﬁcation 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 speciﬁ-

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 speciﬁcations, like the one shown in Fig. 2,

into BPEL speciﬁcation. 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 identiﬁes the appropriate

composite Web service speciﬁcation. 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 ﬁles.

Before sending the selected Web services’ addresses

to the user for invocation, the

policy manager

en-

sures that these Web services comply with the differ-

ent policies. Upon approval of the

policy manager

the

selection manager

initiates the search of the re-

sources on which the Web services will operate.

4 RELATED WORK

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

shape

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

CP4WS - A METHOD FOR DESIGNING AND DEVELOPING SYSTEMS BASED ON WEB SERVICES

457

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 identiﬁed 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 deﬁned 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

policies.

5 CONCLUSION

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 satisﬁed 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.

ACKNOWLEDGEMENTS

C P 4W S development beneﬁted from the discus-

sions the authors had with A. Anderson, G. Kouadri-

Most

efaoui, S. Sattanathan, and Ph. Thiran.

REFERENCES

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

Uniﬁed 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,

48(3).

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,

Crete.

Lupu, E. and Sloman, M. (1999). Conﬂicts 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,

5(2).

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

458