ENGINEERING PROCESS FOR CAPACITY-DRIVEN WEB

SERVICES

Imen Benzarti, Samir Tata

Institut TELECOM, TELECOM SudParis, CNRS UMR, Samovar, Evry, France

Zakaria Maamar

Zayed University, Dubai, U.A.E.

Nejib Ben Hadj-Alouane, Moez Yeddes

National School of Computer Sciences, Tunis, Tunisia

Keywords:

Web service, Capacity-driven Web service, Engineering process.

Abstract:

This paper presents a novel approach for the engineering of capacity-driven Web services. By capacity, we

mean how a Web service is empowered with several sets of operations from which it selectively triggers

a set of operations with respect to some run-time environmental requirements. Because of the speciﬁcities

of capacity-driven Web services compared to regular (i.e., mono-capacity) Web services, their engineering

in terms of design, development, and deployment needs to be conducted in a complete speciﬁc way. Our

approach deﬁne an engineering process composed of ﬁve steps: (1) to frame the requirements that could be

put on these Web services, (2) to deﬁne capacities and how these capacities are triggered, and last but not

least link these capacities to requirements, (3) to identify the processes in term of business logic that these

Web services could implement, (4) to generate the source code, and (5) to generate the C apacity-driven Web

Services Description Language (C -WSDL).

1 INTRODUCTION

Web services are gaining momentum in academia

and industry by achieving the promise of develop-

ing loosely-coupled, cross-enterprise business appli-

cations. To sustain this momentum, we stressed sev-

eral times the importance of designing and developing

Web services along the ﬂexibility, stability, and auton-

omy perspectives

(Maamar et al., 2006). By ﬂexibil-

ity, we refer to a Web service that can adapt itself so

that, it accommodates the characteristics of the busi-

ness scenario it implements. By stability, we refer to

a Web service that can resist to unforeseen changes so

that, it maintains operation continuity and recovers to

normal levels of operation after disturbances. Finally,

by autonomy, we refer to a Web service that can eval-

uate the possible rewards it is entitled to so that, it

These perspectives make Web services sensible to con-

text.

either accepts or rejects processing clients’ requests.

A client could be a user or another Web service.

In (Maamar et al., 2009b), we discuss the notion

of capacity and how it can smoothly be woven into

Web services. By capacity, we mean how a Web

service is empowered with several sets of operations

from which it selectively triggers a set of operations

with respect to some run-time environmental require-

ments. The description of these sets of operations

is included in the C apacity-driven Web Services De-

scription Language (C -WSDL) document of the Web

service. In this paper, we continue our discussions

on capacity-driven Web services with focus this time

on how one could engineer such Web services upon

which enterprise applications could be built. The ra-

tionale of examining capacities is backed by the claim

that “most Web services platforms are based on a

best-effort model, which treats all requests uniformly,

without any type of service differentiation or priori-

tization” (Malay Chatterjee et al., 2005). We qualify

Benzarti I., Tata S., Maamar Z., Ben Hadj-Alouane N. and Yeddes M. (2010).

ENGINEERING PROCESS FOR CAPACITY-DRIVEN WEB SERVICES.

In Proceedings of the 12th International Conference on Enterprise Information Systems - Databases and Information Systems Integration, pages 84-95

DOI: 10.5220/0002976600840095

 SciTePress

the Web services in (Malay Chatterjee et al., 2005) as

mono-capacity.

Capacity is an intrinsic element of the approach

we developed in (Maamar et al., 2009b) in response

to the speciﬁcities that characterize and the challenges

that underpin each of the aforementioned perspec-

tives. In this approach, we decided to let Web services

ﬁrst, assess themselves before they accept to partici-

pate in any composition scenario, and then identify

the requirements and track the changes that are posed

by and made in the execution environment, respec-

tively, before these Web services select a certain ca-

pacity to trigger. On the one hand, requirements could

be related to network reliability, security measures,

and data quality. On the other hand, changes could

be related to drop in network bandwidth, peer appear-

ance/disappearance without prior notice, and comput-

ing resources mobility and sometimes failure.

The deployment of capacity-driven Web services

sheds the light on the importance of assisting those

who are put in the front line of designing, develop-

ing, and maintaining such Web services. There is a

lack of guidelines that would offer the needed assis-

tance to service engineers. A part of this assistance is

usually known as requirement engineering in the soft-

ware ﬁeld (Sommerville, 2001). Our contributions in

this paper are manifold: deﬁne an engineering pro-

cess for capacity-driven Web services; provide guide-

lines to identify capacities of Web services; identify

the requirements that the environment poses on Web

services so that these Web services can satisfy them

through capacities; and, propose techniques for the

generation of the code and the description of capacity-

driven Web services.

This paper is organized as follows. Section 2

presents motivating example, provides an overviewof

the related work and recalls the deﬁnition of capacity-

driven Web services. Section 3 deﬁne our engineer-

ing process for capacity-drivenWeb services. Finally,

conclusions are drawn in Section 4.

2 BACKGROUND

This section consists in four parts. The ﬁrst part

presents a running example that we will use in this

paper for illustration purpose. The second present

a review of the related work. The third part of this

section recalls the deﬁnitions of Capacity-driven Web

services. The last part presents environment assess-

ment in service composition and invocation.

2.1 Running Example

Our running example concerns a real-state ofﬁce that

runs and sells different types of properties such as vil-

las and ﬂats. The ofﬁce is equipped with a set of PCs,

while the staff in charge of conducting the visits are

equipped with various heterogeneous handheld de-

vices. The staff are usually in contact with customers

as per the following description. The customers con-

tact the ofﬁce to request an estimate, purchase, or rent

a property. The ofﬁce can also contact customers as

per their initial requests.

“Get the map of properties in the vicinity” is

among the services that the real-state staff use in their

day-to-day business. This service returns all the prop-

erties that the ofﬁce manages and are within a walking

distance from a staff. This distance and other criteria

like price range and number of bedrooms are set by

the staff. “Get the map of properties in the vicinity” is

treated as a composite Web service that relies on in-

ternal and external Web services as per the following

description:

1. “LocateAgent” returns the current position of a

staff in terms of latitude and longitude.

2. “LocatetProperties” retrieves the list of properties

(identiﬁer, location, etc.) that are in the vicinity

of the staff (at a maximum distance from her) and

whose characteristics match her criteria.

3. “GenerateMap” produces a navigation map that

shows some properties in response to the staff’s

request.

4. “Display” displays the map on the device of the

staff.

It is worth mentioning that “LocateAgent” and

“GenerateMap” services are context aware. Their per-

formance depends on the characteristics of the staff’s

device: network interfaces type (GSM, WiFi, GPS,

etc.), quality of the signal strength of the connexion,

screen size, etc.

2.2 Related Work

Our literature review identiﬁed a good number of re-

search initiatives that looked into the engineering Web

services (Chris Gibson, 2004; Jha, 2006; Kirda et al.,

2003; Robinson, 2003; Tsai et al., 2007; van Eck and

Wieringa, 2004). Unfortunately none of these initia-

tives is adapted to capacity-driven Web serivces. Fur-

thermore, our literature review included some other

initiatives on requirement engineering like (Damas

et al., 2006; Donzelli, 2004; Elghazi, 2007).

In (Chris Gibson, 2004), Chris Gibson stresses the

importance of developing a requirement speciﬁcation

ENGINEERING PROCESS FOR CAPACITY-DRIVEN WEB SERVICES

for software applications built around Web services.

The author reports that deﬁciencies in software re-

quirements are the leading cause of failure in software

projects. The use of Web services to provide B2B on-

line solutions turns out useful; it simpliﬁes applica-

tion development and reduces development risk and

cost. The requirement engineering process of Chris

Gibson is commonly adopted by the IT community

through the steps of elicitation, analysis, modeling

and speciﬁcation, and veriﬁcation.

In (Jha, 2006), Jha develops an approach based on

problem frames for Web services’ requirements. The

approach aligns initiatives on Web services with the

strategies of a business so that, the objectives, needs,

and context of this business are captured. Jha adopts

the deﬁnition of Zave and Jackson that requirements

are all about describing a client’s problem domain, de-

termining what desired effects the client wants to ex-

ert upon that domain, and specifying the external face

of the proposed systems to enable those desired ef-

fects to occur and to give designers a speciﬁcation that

guides them build such systems (Zave and Jackson,

1997). To capture an organization’s objective, needs,

and context, Jha suggests two steps: understand the

organization’s business strategy and overall objective,

and use progression of problems to describe this orga-

nization’s business objective and the business context

from strategy to implementation.

In (Kirda et al., 2003), Kirda et al. note that the

problem of supporting the automatic integration of

Web services into Web sites has received little atten-

tion from the research community. To remedy this

problem, they describe how Web services can be mod-

eled, implemented, composed, and automatically in-

tegrated into Web sites using the Device-Independent

Web Engineering (DIWE) framework. DIWE pro-

motes the separation between three layers known as

layout, content, and application logic.

In (Tsai et al., 2007), Tsai et al. discuss

Service-Oriented System Engineering (SOSE) with

focus on Service-Oriented Requirement Engineer-

ing (SORE). SORE is different from other tradi-

tional requirement engineering approaches because

the concerned applications have to comply with

the general guidelines of service-oriented architec-

ture. Tsai et al. indicate the following charac-

teristics of SORE: reusability-oriented and cumula-

tive, domain-speciﬁc, framework-oriented analysis,

model-driven development, evaluation-based, user-

centric analysis and speciﬁcation, and ﬁnally, policy-

based computing.

Last but not least, in (van Eck and Wieringa,

2004), van Eck and Wieringa examine the require-

ments of a speciﬁc type of Web services. This type

of Web services supports other services that are not

themselves Web services. van Eck and Wieringa

use the wording of product experience augmenters to

qualify such Web services. The authors claim that

most Web services in the future will augment existing

products or services, rather than constituting an inde-

pendent economic offering. Some characteristics that

feature product-experience-augmenters Web services

include: their functional maintenance is the respon-

sibility of the marketing & sales department or the

departments that offer the primary product, and they

need to properly ﬁt into the business processes.

2.3 Capacity-driven Web Services

Capacity is an aggregation of a set of actions that im-

plement the functionality of a Web service (Maamar

et al., 2009b).. Functionality (e.g., currencyConver-

sion) is usually used to differentiate a Web service

from other peers, though it is common that indepen-

dent bodies develop Web services with similar func-

tionalities but different non-functional properties (Bui

and Gacher, 2005; Maamar et al., 2009a). Concretely

speaking, the actions in a capacity correspond to op-

erations in a WSDL document and vary according to

the business-application domain. As per our proposed

running example, the actions in LocateProperties Web

service could be:

• Retrieve a list of properties’ identiﬁers in the

vicinity of the staff using the coordinates(latitude,

longitude) of the staff and the maximum distance.

• Select from the list of identiﬁers the properties

that satisfy the staff’s requirements.

• Locate (latitude, longitude) the identiﬁed proper-

ties.

In Fig. 1 we illustrate a simple speciﬁcation of

the real-state ofﬁce service using a ﬁnite state ma-

chine (Harel and Naamad, 1996). The component

Web services that agreed to participate in this compo-

sition are “LocateAgent”, “LocateProperties”, “Gen-

erateMap” and “Display”. If one of these Web ser-

vices rejects the participation, the discovery step is

reactivated again.

Several capacities along with their respective ac-

tions satisfy the unique functionality of a Web service

in different ways. Which capacity to select and make

active out of the available capacities in a Web service

requires assessing the environment so that appropri-

ate details are collected and prepared for this selec-

tion. Depending on the characteristics of the staff’s

device, “LocateAgent” can be carried out with one of

the following capacities:

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

Figure 1: Speciﬁcation of the real-state ofﬁce example.

• “GPSGeoLocation” capacity that is an internal

function of the device if the device is equipped

with a Global Positioning System (GPS).

• “GSMGeoLocation” capacity that provides the

position of the staff’s device if the device

is equipped with a Global System for Mo-

bile (GSM).

• “AddressGeoLocation” capacity that provides the

position (latitude, longitude) of the staff from the

standardized address.

2.4 Environment Assessment

Environment assessment identiﬁes the requirements

that a Web service has to satisfy before this Web ser-

vice ﬁrst, accepts to participate in a new composition

scenario (on top of its ongoing participations in other

compositions) and second, selects a capacity to trig-

ger after accepting this participation. As a result, en-

vironment assessment is about satisfying two types

of requirements. Those associated with composition

scenarios and those associated with capacity activa-

tion. An example of composition requirement could

be the maximum number of compositions that a Web

service takes part in at a time. And an example of

capacity requirement could be the minimum network

bandwidth to maintain so that a Web service can guar-

antee regular live-content delivery to users of hand-

held devices.

3 ENGINEERING

CAPACITY-DRIVEN WEB

SERVICES

In this section, we answer the question: How to de-

velop a capacity-driven Web service. The develop-

ment of a monocapacity Web service can be done in

two different ways: The ﬁrst is to generate the skele-

ton of the code source service from the WSDL speciﬁ-

cation before completing it with the business code, the

second one is to generate WSDL speciﬁcation from a

web service code source before deploying the Web

service.

Because of the speciﬁcities of capacity-driven

Web services compared to regular (i.e., mono-

capacity) Web services, their engineering in terms

of design, development, and deployment needs to be

conducted in a complete speciﬁc way. Our approach

deﬁne an engineering process composed of ﬁve steps:

(1) to frame the requirements that could be put on

these Web services, (2) to deﬁne capacities and how

these capacities are triggered, and last but not least

link these capacities to requirements (3) to identify

the processes in term of business logic that these Web

services could implement (4) to generate the source

code and (5) to generate the C apacity-drivenWeb Ser-

vices Description Language (C -WSDL).

As prsented in Fig. 2, the proposed engineering

process for capacity-drivenWeb services is composed

of ﬁve steps:

1. Step 1: requirement engineering,

2. Step 2: capacity engineering,

3. Step 3: business logic engineering,

4. Step 4: source Code generation,

5. step 5: CWSDL description gnration

In the following, these ﬁve steps are detailed. We

use the example presented in Section 2.1 to illustrates

these steps.

3.1 Requirement Engineering

In this ﬁrst step of the engineering approach, the goal

is to contribute towards (i) reﬂecting the dynamic na-

ture of the environment, (ii) understanding the types

of requirements that this environment poses on Web

services, and last but not least (iii) linking some of

these requirements to capacity development. By dy-

namic nature, we mean Web services appearing and

disappearing without prior notice, Web services re-

suming and suspending operation, sudden drop in net-

work bandwidth, etc. As per the deﬁnition of “en-

vironment assessment” , we identify two goals and

associate them with “composition requirements” and

“capacity requirements”, respectively. The former

goal is meant to secure the participation of a Web ser-

vice in a new composition scenario, and the latter goal

is meant to secure the activation of at least one capac-

ity in a Web service at run-time.

ENGINEERING PROCESS FOR CAPACITY-DRIVEN WEB SERVICES

Figure 2: Engineering process for capacity-driven Web services.

3.1.1 Composition Requirements

In (Maamar et al., 2006), we introduced the Web ser-

vices instantiation principle that illustrates the condi-

tional participation of a Web service in composition

scenarios. Upon acceptance, this participation hap-

pens through a Web service instance. In compliance

with this instantiation principle, a Web service is or-

ganized along three dimensions: past compositions,

current compositions, and forthcoming compositions.

Requirements apply to forthcoming compositions and

thus, could limit the participation of a Web service in

these compositions.

Deﬁnition 1 (Composition Requirement). The com-

position requirement on a Web service is a tuple

C O R

W S

= (arg

,rop

,val

,desc

,Ont) where:

- arg

is the name of a type of composition require-

ment.

- rop

is a relational operator (=,<,≤, >,≥, or 6=).

- val

is a value (numerical, string, etc.) assigned to

arg

- desc

is a narrative description of the composition

requirement.

- Ont refers to the ontology deﬁning arg

The set of all possible composition requirements

is denoted by C O R .

Examples: The following elements could popu-

late C O R :

- arg

: number of participations, rop

: ≤, val

: 10,

desc

: the maximum number of participation for

a Web service in compositions at a time should not

exceed 10, Ont: ONT

comp−req

- arg

: date of maintenance, rop

: =, val

: ev-

ery Wednesday of the week, desc

: on Wednes-

days, a Web service does not take part in any com-

position because of maintenance (upgrade, code

change, etc.), Ont: ONT

comp−req

3.1.2 Capacity Requirements

A Web service implements the functionality it offers

through capacities. Which capacity to activate at run-

time depends on which requirements are put on this

Web service. We classify requirements on capacities

into different types with focus in this paper on the fol-

lowing three types (additional ones could be added, as

need be):

1. Data requirement is about the quality of data that

a Web service receives, manipulates, and proba-

bly sends out. Such a requirement could be about

freshness (when were data obtained), source (who

is the sender of data), and validity (when do data

expire) of data.

2. Network requirement is about the nature of com-

munication means that a Web service uses to in-

teract with users and peers. Such a requirement

could be about bandwidth, throughput, and relia-

bility.

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

3. Resource requirement is about the computing fa-

cilities upon which the performance of a Web ser-

vice is scheduled. Such a requirement could be

about availability and reliability.

Deﬁnition 2 (Capacity Requirement). The capacity

requirement on a Web service is a tuple C A R

W S

(arg

,rop

,val

,desc

,thre

,Ont) where:

- arg

is the name of a capacity requirement.

- rop

is a relational operator (=,<,≤, >,≥, or 6=).

- val

is a value (numerical, string, etc.) assigned to

arg

- desc

is a narrative description of the capacity re-

quirement.

- thre

is a threshold value that keeps the capacity

requirement illustrated with arg

satisﬁed despite

changes in the environment that affect val

- Ont refers to the ontology deﬁning arg

The set of all possible capacity requirements is de-

noted by C A R .

Examples: The following elements could popu-

late C A R :

- arg

: data freshness, rop

: =, val

: current,

desc

: all data to be used by a Web service need

to be of today, thre

: null, Ont: ONT

cap−req

- arg

: resource availability, rop

: ≤, val

: 80%,

desc

: resources upon which a Web service runs,

need to have an 80% availability, thre

: 5% de-

crease in resource availability is still acceptable

to the Web service and the current activated ca-

pacity can continue to be used, Ont: ONT

cap−req

3.2 Capacity Engineering

In this second step of the engineering approach, the

goal is to contribute towards (i) understanding the dif-

ferent ways of structuring capacities, (ii) assessing

how capacities are triggered, and last but not least

(iii) linking these capacities to requirements. As per

the deﬁnition of “capacity” in Section 2.3, we identify

goals with respect to the multiple capacities that em-

power a Web service. A capacity is a set of operations

that a Web service carries out upon receiving requests

from users or peers. A Web service could have several

capacities that are differently structured according to

the functionality it implements and the requirements

that these capacities can satisfy.

Deﬁnition 3 (Web Service Capacity). The capacity

in a Web service is a couple C A P

W S

= (O P , access)

where:

- O P is a set of operations. An operation Op

∈

O P consists of a name N, a set of input argu-

ments Input along with their appropriate types,

and a set of output arguments Ouput along

with their appropriate types, and is written as

(N,Input,Output).

- access is the access modiﬁer of a capacity whether

public or private.

The set of all deﬁned capacities is denoted by

C A P . The rationale of public and private access mod-

iﬁers is given later.

Example: Let us consider C A P

PlaceBookingWS

of PlaceBookingWS. It is speciﬁed as follows:

({Op

,Op

}, public) where Op

= (check-

place, in(date:Date), out(availability:Boolean)),

= (conﬁrmplace, in(date:Date),

out(conﬁrmation:Boolean)), and access is pub-

lic.

The selection of a capacity in a Web service W S

for triggering is subject to satisfying some capacity

requirements, i.e., C A R

i=1,..,n

W S

. As a result, we deﬁne

a function that associates a capacity with capacity re-

quirements as per Deﬁnition 4.

Deﬁnition 4 (Association Function). Let C A P and

C A R be respectively, the set of all capacities deﬁned

in a Web service and the set of all possible capacity

requirements on Web services. The association func-

tion is deﬁned as follows: Assoc : C A P

W S

→ 2

C A R

The association function Assoc connects each ca-

pacity in a Web service W S with a set (possibly

empty) of capacity requirements (2

C A R

is the power

set of C A R ). This connection is done manually,

i.e., designer driven.

Example: Let us continue using

C A P

PlaceBookingWS

. Assoc(C A P

PlaceBookingWS

) =

{C A R

PlaceBookingWS

} where C A R

PlaceBookingWS

is deﬁned as follows: <

data freshness,current,··· ,null,Ont

req−cap

Based on Deﬁnition 3 and Deﬁnition 4, the following

comments are made:

- A capacity in W S , which does not have any re-

quirement to satisfy is referred to as default ca-

pacity, i.e., Assoc(C A P

W S

) =

0. This capacity

is automatically selected when none of the exist-

ing capacities in W S satisﬁes the current capac-

ity requirements. By having a default capacity,

W S can always guarantee a user’s request satis-

faction.

- Independent capacities in W S could have com-

mon operations, i.e., ∩

i=1

C A P

W S

ENGINEERING PROCESS FOR CAPACITY-DRIVEN WEB SERVICES

- Common operations in independent capacities

could be overloaded if needed. For example,

could take one input argument in C A P

W S

e.g., in(username:String), and two input argu-

ments in C A P

W S

, e.g., in(username:String, pass-

word:String).

In Deﬁnition 3, capacity has either public or pri-

vate access-modiﬁer like in object-oriented program-

ming languages (Fig. 3)

. On the one hand, public

capacities are offered to the external environment par-

ticularly to users and other Web services. Submitting

invocation messages to public capacities requires ful-

ﬁlling capacity requirements. On the other hand, pri-

vate capacities are hidden as their name hints and are

just called by public capacities. By doing so, the pri-

vacy of a Web service in terms of offered and existing

capacities is maintained; only the necessary capacities

are exposed. It should be noted that private capacities

might call each other if needed ((0,n) cardinality in

Fig. 3), but this is not the case with public capacities

((0,0) cardinality in Fig. 3) since they all implement

the unique functionality of a Web service.

Capacity

Public Private

Specialized into

Call (1,n)

Call

(0.n)

Call

(0.0)

Requirements

+

Invocation messages

To trigger

Restrict

/[Cap]

Call(min,max): min/max calls to a capacity

Legend

Figure 3: Capacity categorization.

3.3 Business Logic Engineering

In this third step of the engineering approach, the goal

is to contribute towards (i) understanding the current

practices in terms of business processes, (ii) motivat-

ing the need of changing these processes, and last but

not least (iii) linking these changes in processes to re-

quirement satisfaction.

As per the deﬁnition of “Web service functional-

ity” in Section 2.3, we identify a goal with respect

to the functionality (e.g., currencyConversion) of a

Web service. A functionality is about a business logic

that describes the processes to execute in terms of

how, when, and where. A business logic is domain-

application dependent (e.g., education, tourism) and

varies from one case study to another according to

In Fig. 3, Restrict/[Cap] means that requirements are

here to restrict the capacity that a Web service could se-

lect. And, Call(min,max) means the minimum and maxi-

mum times that a capacity could be called by another ca-

pacity; for example Call(0,0) means that a capacity is never

called by any other capacity; this applies to public capac-

ities, only. Contrarily, private capacities could be either

called or never called Call(0,n).

different elements such as users (e.g., minimum age

to submit an application), security (e.g., maximum

length of encrypted key), and legal (e.g., minimum

VAT rate).

Deﬁnition 5 (Web Service Goal). The goal of a Web

service is a couple G

W S

= ( fct, bl) where:

- fct is a narrative description of the functionality.

- bl is a speciﬁcation of the business logic.

The speciﬁcation of a business logic uses

state charts but other techniques like petri-nets could

be used.

Deﬁnition 6 (Web Service Business-logic). The

S tate C hart S C of the business logic of a Web service

is a tuple S C

W S

(bl)

= (S , S

,L , T ,s

) where:

- S is a ﬁnite set of state names.

- s

∈ S is the initial state in S C

W S

- S

⊂ S is a ﬁnite set of ﬁnal states.

- L is a set of labels. In state chart, a label con-

sists of an event component E, a condition compo-

nent C, and an action component A, and is written

as E[C]/A. For representation purposes in Fig. 4,

we just name labels without giving full details on

conditions and actions.

Figure 4: Business logic of the real-state ofﬁce example.

In our engineering approach, condition C is split

into pre-condition represented as •C and post-

condition represented as C•. If state s

is directly

connected to state s

i+1

, the post-conditions of s

subsume the pre-conditions of s

i+1

, i.e., s

(C•) ⇒

i+1

(•C).

- T ⊆ (S × L × S ) is a ﬁnite set of transitions.

Each transition t ∈ T ,t = (s

src

,l, s

tgt

) consists of

a source state s

src

∈ S , a target state s

tgt

∈ S , and

a transition label l ∈ L .

Example: Fig. 4 is a state chart that represents

weatherForecast functionality of WeatherWS. Several

states like city-located, report-delivered, and search-

canceled are included in this state chart. More-

over, this state chart includes various transitions such

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

as (city-located, unavailable, search-canceled) where

city-located and search-canceled are the source and

target states, respectively, and unavailable is the la-

bel of the transition.

The business logic in Fig. 4 is an example of how

a “regular” (i.e., mono-capacity) Web service for in-

stance WeatherWS would function independently of

the requirements of type capacity (could be of related

to security, network, trust, etc.) that could be posed on

this Web service, and thus could restrict the function-

ing of this Web service. Unfortunately, the speciﬁca-

tion of a business logic is tightened to the functional-

ity to offer and does not show how these capacity re-

quirements need to be handled nor how this function-

ality might be affected because of these requirements.

To address this lack of handling, we review the busi-

ness logic of a Web service with focus on the needs

of each type of capacity requirement. As a result, we

deﬁne a conversion function that

- takes two inputs namely a business logic bl (repre-

sented here with a state chart) and a set of capacity

requirements, i.e., C A R

i=1,..,n

W S

(Deﬁnition 2), and

- returns one output, which is a revised business

logic bl

C A P

that shows the capacities that are

needed to satisfy this set of capacity requirements.

This way of doing creates the missing link between

business logic and capacities through the link that

exists between capacities and capacity require-

ments (Deﬁnition 4). The conversion function is as

follows (Deﬁnition 7).

Deﬁnition 7 (Conversion Function). Let bl and

C A R be the business logic of a Web service and the

set of all possible capacity requirements on this Web

service, respectively. The conversion function is de-

ﬁned as follows: Conv : bl × 2

C A R

→ bl

C A P

The conversion function Conv takes a business

logic bl and a set (possibly empty) of capacity re-

quirements (2

C A R

is the power set of C A R ) and pro-

duces a revised business logic bl

C A P

. This process is

done manually, i.e., designer driven. An illustration

of a revised business logic is given in Fig. 5.

Because of the conversion exercise, the initial

goal, which identiﬁes the functionality of a Web ser-

vice, is reviewed with respect to the additional mech-

anisms (in terms of capacities) that empower this Web

service. These mechanisms are used for satisfying the

capacity requirements. This empowerment has to be

captured and reﬂected on the initial state chart of the

business logic of a Web service and could be imple-

mented through three types of actions: states to re-

peat, states to add, and states to skip (the outcomes

of these actions are represented with dashed lines in

Fig. 5).

• States to Repeat. This occurs when the execu-

tion of the actions in a certain state did not permit

meeting a certain capacity requirement that is put

on the Web service. This is detected by check-

ing the post-conditions (C•) of this state, which

results in repeating the execution of these actions.

For example, report-delivered state in Weath-

erWS will be repeated if the minimum accept-

able network-bandwidth requirement drops below

a certain threshold (report-delivered’s C•: net-

work bandwidth did not improve). The objective

is to guarantee the delivery of weather-forecast re-

port. Report-delivered state is now bound to a ca-

pacity requirement of type network.

• States to Add. This occurs when the preparation

work that is carried out to execute the actions in

a certain state did not permit meeting the capacity

requirements that are put on the Web service. This

is detected by checking the pre-conditions (•C) of

this state, which results in adding new states to the

state chart of this Web service. The new states will

be executed several times (obviously bound to a

maximum number) until their post-conditions per-

mit satisfying the pre-conditions of the state they

precede.

For example, city-located state will be preceded

by veriﬁcation state if the minimum security-level

requirement is not guaranteed. The goal is to re-

strict the use of WeatherWS in an unsecure en-

vironment (city-located’s •C: unsecure environ-

ment). Contrarily, veriﬁcation state is simply ig-

nored. City-located state is now bound to a capac-

ity requirement of type security.

• States to Skip. This occurs when the number of

times that the execution of the actions in a certain

state reaches the maximum following the contin-

uous unsatisfaction of a certain capacity require-

ment that is put on the Web service. This is de-

tected by checking the post-conditions(C• ) of this

state, which results in skipping some of the next

states and make the Web service take on appropri-

ate states.

For example, weather collected, access-failed,

and search canceled states will be ignored if

city-located state cannot satisfy the minimum

freshness-level requirement of the data it collects

out of the database. (city-located’sC•: data fresh-

ness is 2 days old). The objective is to guarantee

the use of up-to-date data. City-located state is

now bound to a capacity requirement of type data.

• Note. The fact of repeating, adding, or skipping

ENGINEERING PROCESS FOR CAPACITY-DRIVEN WEB SERVICES

states

impacts the set of transitions that are es-

tablished in the initial state chart of the business

logic of the Web service (Fig. 4). As a result, new

transitions are considered if needed.

Fig. 5 shows now the reviewed state chart of

WeatherWS after making some changes in its initial

state chart (Fig. 4). These changes show some

requirement types that are anchored to some states in

this Web service.

Deﬁnition 8 (Web Service Reviewed Goal). The

reviewed goal of a Web service R G

W S

complies

with the deﬁnition of a goal as per Deﬁnition 5.While

the functionality of a Web service remains the same,

the business logic is reviewed R G

W S

= ( fct,rbl)

like Fig. 5 illustrates.

Deﬁnition 9 (Web Service Reviewed Business-

Logic). The state chart of the reviewed business-logic

a Web service R S C

W S

(bl)

complies with the deﬁni-

tion of a state chart as per Deﬁnition 6.

Figure 5: Reviewed business logic of GeoLocProp.

3.4 Source Code Generation

Our goal is to generate java code annotated with dif-

ferent capacities from the reviewed statechart. This

led us to study the generator of Java code from state-

charts diagrams (ﬁnal state machine: FSM)

3.4.1 The Annotation of Java Code with

Capacity

Many APIs require a fair amount of boilerplate code.

For example, in order to write a JAX-RPC web ser-

vice, we must provide a paired interface and imple-

mentation. This boilerplate could be generated auto-

matically by a tool if the program were ”decorated”

with annotations indicating which methods were re-

motely accessible. Annotations play a critical role

in JAX-WS 2.0 (the successor of JAX-RPC API).

First, annotations are used in mapping Java to WSDL

State skipping could be used to implement state dele-

tion if needed.

and schema. Second, annotations are used a run-

time to control how the JAX-WS runtime processes

and responds to web service invocations. In our case

we are interested to the mapping between java and

WSDL. We propose new annotation that will process

the transformation from java to WSDL annotated with

capacity (CWSDL).

Figure 6: Implementation of interface WebCapacity.

Figure 6 presents the implementation of the inter-

face WebCapacity that takes as parameters the name

capacity, visibility, requirements of type data, re-

sources and network.

3.4.2 Java Code Generators from FSM

According to our study of the generator FSM, we

distinguish two types of generator. (i) Generators

that generate the machine into a single class that

presents the business logic like FSMGneretor (Gurp

and Bosch, 1999) (ii) generator that generates a java

class for each state(Mura and Sami, 2008). On the

other hand, the speciﬁcation of departure may be (i) a

java class (Sakharov, 2000) or (ii) in XML (Gurp and

Bosch, 1999).

Our goal is to generate java code from a state ma-

chine that describes the behavior of a web service and

annotated with the capacity for this service. The gen-

erated code must represent the business logic of web

service by a single Java class. The generation must

therefore be done in one class. On the other hand, the

speciﬁcation of the state machine must be simple and

consistent with the deﬁnition of a state machine . The

speciﬁcation is most consistent with the XML speci-

ﬁcation (Figure 7) ; the other code generated by this

tool is one class that describes the business logic of

the state machine.

3.4.3 Code Generator

Generating Java code from state machine of the web

service described in XML is based on the generator

FSMGenerator. The generated code also contains the

annotation @WebService and @WebCapacity.

Capacity requirements are extracted from the tran-

sitions added in the state diagram transition revised.

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

Figure 7: Speciﬁcation of FSM of GeoLocProp in XML.

To associate these transitions with the type of capac-

ity requirements (data, resources, network) a model is

used. This led us to look into the existing approach

for requirement modeling. Modeling of requirements

must be divided into three subtypes (data, resources,

network) this has led us to study models of device ca-

pability.

As the number of user devices is proliferating and

as the capabilities of the devices are augmenting on

daily basis, there have been a number of different

approaches for describing devices capability. The

CC/PP (Kim and Lee, 2006)proﬁle describes the ca-

pabilities of the device and, possibly, the preferences

of the user. It serves a model and provides core vo-

cabulary for the devices’ capabilities description. The

extended CC/PP presented in (Mukhtar et al., 2008)

model classiﬁes device capability into hardware, soft-

ware and network categories. (Bandara et al., 2004)

introduces ontology for devices description intended

at providing a general framework to describe any type

of device. The information related to a device is

logically divided into ﬁve classes depending on the

type of information they provide: namely Device De-

scription, Hardware Description, Software Descrip-

tion, Device Status (including location) and Service.

These approaches have common characteristics that

they are both based on languages designed for se-

mantic matching purposes (OWL and RDF). We rely

on these models to create a modeling for capacity re-

quirements (Figure 8) . We associate the data level to

software level while adding other concepts, resources

level to hardware level and network level is already in

the models already presented.

To deﬁne the different types of capacity in FSM

the generator uses this model to associate each transi-

tion to capacity in order to generate the annotation in

Figure 8: Modelling for capacity requirements.

the Java code. Part of the generated code is presented

in Fig Figure 9.

3.5 CWSDL Description Generation

CWSDL generation is done with the same process as

generating WSDL. We studied the source code for the

JAX-WS API. This API uses the tool wsgen that in-

terprets different annotations in java code and gener-

ates the wsdl while relying on the XML schema for

WSDL.

To generate the CWSDL by JAX-WS we went

through the following steps: (1)development of the

class interface WebCapacity (2)replace the XML

schema of the WSDL CWSDL (3)modiﬁed the tool

wsgen that it interprets the new annotation. The Fig-

ure 10 present a fragment of the generated cwsdl for

the service GeoLocProp.

ENGINEERING PROCESS FOR CAPACITY-DRIVEN WEB SERVICES

Figure 9: The generated code for GeoLocProp.

Figure 10: A fragment of the generated cwsdk for the ser-

vice GeoLocProp.

4 CONCLUSIONS

In this paper we presented the concepts, deﬁnitions,

issues, and solutions that underpin the design, de-

velopment, and deployment of capacity-driven Web

services. We recalled the concept of capacity as a

new way of making Web services take appropriate

actions in response to some environmental require-

ments. Then we deﬁned a novel approach for en-

gineering capacity-driven Web services composed of

ﬁve steps: to frame the requirements, to deﬁne capac-

ities, to identify the business logic, (4) to generate the

source code, and (5) to generate the C apacity-driven

Web Services Description Language (C -WSDL).

In term of future we identiﬁed different research

issues that need to be addressed such as requirement

consistency and capacity types and Capacity-driven

web service deployment based on the extension of

Web service containers .

REFERENCES

Bandara, A., Payne, T. R., de Roure, D., and Clemo, G.

(2004). An ontological framework for semantic de-

scription of devices. In International Semantic Web

Conference (ISWC).

Bui, T. and Gacher, A. (2005). Web Services for Negoti-

ation and Bargaining in Electronic Markets: Design

Requirements and Implementation Framework. In

Proceedings of The 38th Hawaii International Con-

ference on System Sciences (HICSS’2005), Big Island,

Hawaii, USA.

Chris Gibson, J. (2004). Developing a Requirements Spec-

iﬁcation for a Web Service Application. In Proceed-

ings of The 12th IEEE International Requirements En-

gineering Conference (RE’2004), Kyoto, Japan.

Damas, C., Lambeau, B., and van Lamsweerde, A. (2006).

Scenarios, Goals, and State Machines: a Win-Win

Partnership for Model Synthesis. In Proceedings

of the 14th ACM SIGSOFT International Symposium

on Foundations of Software Engineering (FSE’2006),

Portland, Oregon, USA.

Donzelli, P. (2004). A Goal-driven and Agent-based Re-

quirements Engineering Framework. Requirement En-

gineering, Springer, 9(1).

Elghazi, H. (2007). A Goal-driven Method for Automated

Systems Requirements Engineering. In Proceedings

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

of the First International Conference on Research

Challenges in Information Science (RCIS’2007),

Ouarzazate, Morocco.

Gurp, J. V. and Bosch, J. (1999). On the implementation

of ﬁnite state machines. In in Proceedings of the 3rd

Annual IASTED International Conference Software

Engineering and Applications, IASTED/Acta, pages

172–178. Press.

Harel, D. and Naamad, A. (1996). The STATEMATE Se-

mantics of Statecharts. ACM Transactions on Soft-

ware Engineering and Methodology, 5(4).

Jha, A. (2006). Problem Frames Approach to Web Ser-

vices Requirements. In Proceedings of the 2nd Inter-

national Workshop on Advances and Applications of

Problem Frames (IWAAPF’2006), Shanghai, China.

Kim, H.-M. and Lee, K.-H. (2006). Device-independent

web browsing based on cc/pp and annotation. Inter-

act. Comput., 18(2):283–303.

Kirda, E., Kerer, C., Kruegel, C., and Kurmanowytsch,

R. (2003). Web Service Engineerning with DIWE.

In Proceedings of the 29th EUROMICRO Conference

2003, New Waves in System Architecture (EUROMI-

CRO’2003), Belek-Antalya, Turkey.

Maamar, Z., Benslimane, D., and Narendra, N. C. (2006).

What Can Context do for Web Services? Communi-

cations of the ACM, 49(12).

Maamar, Z., Subramanian, S., Bentahar, J., Thiran, P., and

Benslimane, D. (2009a). An Approach to Engineer

Communities of Web Services - Concepts, Architec-

ture, Operation, and Deployment . International Jour-

nal of E-Business Research, IGI Global, 5(4).

Maamar, Z., Tata, S., Bela¨ıd, D., and Boukadi, K. (2009b).

Towards An Approach to Deﬁning Capacity-Driven

Web Services. In Proceedings of the 23rd Interna-

tional Conference on Advanced Information Network-

ing and Applications (AINA’2009), Bradford, UK.

Malay Chatterjee, A., Pal Chaudhari, A., Saurav Das, A.,

Dias, T., and Erradi, A. (2005). Differential QoS Sup-

port in Web Services Management. SOA World Mag-

azine, 5(8).

Mukhtar, H., Bela¨ıd, D., and Bernard, G. (2008). A model

for resource speciﬁcation in mobile services. In SIPE

’08: Proceedings of the 3rd international workshop

on Services integration in pervasive environments,

pages 37–42, New York, NY, USA. ACM.

Mura, M. and Sami, M. G. (2008). Code generation from

statecharts: Simulation of wireless sensor networks.

In DSD ’08: Proceedings of the 2008 11th EUROMI-

CRO Conference on Digital System Design Architec-

tures, Methods and Tools, pages 525–532, Washing-

ton, DC, USA. IEEE Computer Society.

Robinson, W. N. (2003). Monitoring Web Service Require-

ments. In Proceedings of The 11th IEEE International

Requirements Engineering Conference (RE’2003),

Monterey, California, US.

Sakharov, A. (2000). A hybrid state machine notation for

component speciﬁcation. SIGPLAN Not., 35(4):51–

56.

Sommerville, I. (2001). Software Engineering, 6th Edition.

Addison-Wesly Publishers Limited.

Tsai, W. T., Jin, Z., Wang, P., and Wu, B. (2007). Re-

quirement Engineering in Service-Oriented System

Engineering. In Proceedings of the 2007 IEEE

International Conference on e-Business Engineer-

ing (ICEBE’2007), Hong Kong, China.

van Eck, P. and Wieringa, R. (2004). Web Services as Prod-

uct Experience Augmenters and the Implications for

Requirements Engineering: A Position Paper. In Pro-

ceedings of the International Workshop on Service-

oriented Requirements Engineerings (SoRE’2004),

Kyoto, Japan.

Zave, P. and Jackson, M. (1997). Four Dark Corners of Re-

quirements Engineering. ACM Transactions on Soft-

ware Engineering and Methodology, 6(1).

ENGINEERING PROCESS FOR CAPACITY-DRIVEN WEB SERVICES