TOWARDS A CONTEXTUAL MODEL-DRIVEN DEVELOPMENT

APPROACH FOR WEB SERVICES

Zakaria Maamar

, Karim Ba¨ına

, Djamal Benslimane

, Nanjangud C. Narendra

and Mehdi Chelbabi

Zayed University, Dubai, U.A.E.

ENSIAS, Mohammed V-Souissi University, Rabat, Morocco

Claude Bernard Lyon 1 University, Lyon, France

IBM India Research Lab, Bangalore, India

CERIST, Algiers, Algeria

Keywords: Context, Model-Driven, UMLProﬁle, and Web service.

Abstract: This paper discusses how we develop and apply a contextual model-driven approach to Web services. A Web

service is deﬁned using WSDL, posted on an UDDI registry, and invoked through a SOAP request. To deploy

adaptable Web services, we consider the environment in which these Web services operate. This environment’s

features exist in a structure, which we refer to as context. By adopting a contextual model-driven approach,

we aim at developing contextual speciﬁcations of Web services. To this end ContextUML, an extension of

UML through UMLProﬁle, permits developing these contextual speciﬁcations.

1 INTRODUCTION

For the World Wide Web Consortium (W3C), a Web

service is a software application identiﬁed by a URI,

whose interfaces and binding are capable of being

deﬁned, described, and discovered by XML artifacts

and supports direct interactions with other software

applications using XML based messages via Internet-

based applications. Web services constitute an at-

tractive way for running B2B scenarios and address-

ing the challenges of these scenarios like distribution,

heterogeneity, and coordination. Over the last few

years tremendous efforts have been put in develop-

ing standards for Web services in terms of just to cite

a few description, discovery, composition, and secu-

rity (Ma, 2005). Particularly Web services composi-

tion is object of intense investigations. Composition

emphasizes the complex nature of user demands and

the inability of a single Web service to satisfy these

demands by itself. Hence a collection of interacting

Web services - which forms high-level business pro-

cesses known as composite Web services - is deemed

appropriate to satisfy user demands.

Relying on standards for Web services and aiming

to ease their development, several design approaches

are proposed to those who are put on the front line

of satisfying businesses’ promise of delivering Web

services-based solutions. Some approaches adopt

models (B´ezivin et al., 2004) while others adopt soft-

ware agents (Huhns, 2002). In this paper, the focus

is on models. A model has a vocabulary and is a

kind of representation that ﬁrst, permits abstracting

the features of an application domainand second, sup-

ports interaction with end-users during validation. In

a model-drivenapproachoncethe design of a model is

completed, it is automatically converted into program

code (Grφnmo et al., 2004). With regard to Web ser-

vices, the mapping of models onto runnable speciﬁ-

cations should be geared towards the requirements of

the development stage of a Web services application.

These requirementsare about Web services deﬁnition,

composition, or even interaction.

Although the pervasive adoption of Web ser-

vice (Kulkarni et al., 2005), Web services still lack

the widespread acceptance level of traditional integra-

tion middleware like CORBA and DCOM, primarily

due to two reasons. The ﬁrst reason is the trigger-

response pattern that frames the interactions of Web

services with peers (Maamar et al., 2006a). The sec-

ond reason is that Web services are still seen by some

as distributed objects that react upon request (Birman,

2004). To tackle both reasons, a Web service needs

to be context-aware so it can detect and respond to

changes in its environment. In(Maamar et al., 2006a),

we discussed why Web services are to eb enhanced

with capabilities that permit them to be more ﬂexible

in managing the situations in which they participate.

Therefore, Web services can independently decide

when and how to process requests, why and how to

delay their participation in some compositions, why

Maamar Z., Bäına K., Benslimane D., C. Narendra N. and Chelbabi M. (2006).

TOWARDS A CONTEXTUAL MODEL-DRIVEN DEVELOPMENT APPROACH FOR WEB SERVICES.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 78-85

DOI: 10.5220/0002442000780085

 SciTePress

and how to reject requests for security reasons, etc.

The integration of context into a model-driven ap-

proach for Web services development is not straight-

forward. Many problems arise including how do we

represent and structure context in a model, how do we

specify a Web service binding to context, how do we

map a contextual model onto a contextual program

code, how do we provide an automatic tool for this

conversion, and how do we show the dynamic nature

of context? A contextual model complies with the ar-

gument that ”there is no unique way to look at data

and there is no unique way to represent data” (Arara

and Benslimane, 2004) and, opens up as well research

opportunities in the ﬁeld of multi-representation. A

contextual model would permit abstracting a situation

based on the expected use (e.g., maintenance, moni-

toring) of this abstraction. During modeling, several

elements are strengthened based on the context that

is under consideration. These elements include the

amount of information to integrate into a model, the

representation and organization of this information,

the granularity level of this information, and the ra-

tionale of this information to the considered context.

This paper discusses the value-added of context to

a model-drivenapproach and to suggest extensions (if

needed) to such an approach so the obtained imple-

mentable speciﬁcations of Web services are contextu-

alized, too. The remainder of this paper is set out as

follows. Section 2 overviews prior work on model-

driven approaches, and discusses the challenges as-

sociated with the multi-representation of Web ser-

vices. Section 3 uses a scenario to discuss the need for

Web services composition and to shed the light on the

challenges that this composition faces when a model-

driven approach is adopted. Section 4 introduces our

ongoing work on a contextual model-driven approach

that we propose in terms of deﬁnition and mapping

steps. Section 5 contains our conclusions.

2 BACKGROUND

2.1 Prior Work

Model-driven approaches have been subject to var-

ious investigations as the literature shows (Mellor

et al., 2003). Usually the complete design model of an

application comprises multiple models, each model

offers a different viewpoint on the application. For

instance, UML offers models ranging from use-cases

and class diagrams to deployment diagrams, which

are used depending on the objectives to reach during

the design of an application.

In a model-driven approach, the emphasis is on

the design of very detailed models and platform in-

dependent speciﬁcations. For Backx, a model-driven

approach addresses the migration problems between

computing platforms, which are error-prone and time

consuming (Backx, 2004). By having models that are

language and platform independent,same models can

be applied in different scenarios. To boost embracing

a model-driven approach by designers, the following

models are produced (Backx, 2004): the Computa-

tion Independent Model (CIM) for business require-

ments (or business model), the Platform-Independent

Model (PIM) for system functionalities, and the Plat-

form Speciﬁc Model (PSM) for platform speciﬁc de-

tails. Initially the work starts with preparing a CIM to

be mapped onto a detailed PIM. A PIM is the start-

ing point of the derivation of the PSM according to

the characteristics of the target platform using speciﬁc

mapping rules. The last step consists of relying on a

model-driven approach-enabled tool to generate the

complete code for the system from the PSM.

In (Ba¨ına et al., 2004) the authors suggested a

framework to performa model-drivendevelopmentof

Web services, generating a set of extensible service

implementation templates and a executable service

speciﬁcations. In this framework, a protocol speci-

ﬁcation of a Web service identiﬁes the message ex-

change sequences that the Web service supports (con-

straints on the invocationorder of the Web service op-

erations). A continuation of the work of Bana et al. is

an UML-based modeling language for model-driven

and context-aware Web services (Sheng and Benatal-

lah, 2005). More details are given in Section 4.2.

Zarras et al. adopted a model-driven approach for

the development of a methodology for the depend-

ability analysis of composite Web services (Zarras

et al., 2004). In (Bordbar and Staikopoulos, 2004) the

authors noted that developing Web services by apply-

ing model-driven approaches has received consider-

able attention. However, most of the existing research

focuses on the transformation of models that express

the static structure of the system. Therefore, Bordbar

and Staikopoulos have decided to study transforma-

tions that concern the dynamic structure of the sys-

tem (Bordbar and Staikopoulos, 2004). This struc-

ture is modelled using behavioral models, expressing

how the various components collaborate in order to

manage a task and to fulﬁll the system functionali-

ties. Bordbar and Staikopoulos have developed trans-

formation mechanisms from UML activity diagrams

to BPEL speciﬁcations.

2.2 Multi-representation

Recent works on Web services deﬁne new standards

to include more semantic and contextual information

when describing, publishing, discovering, and com-

posing Web services. Many researchers recognize

that semantics is context-dependent: there is no single

way to look at data and functionalities of web services

TOWARDS A CONTEXTUAL MODEL-DRIVEN DEVELOPMENT APPROACH FOR WEB SERVICES

Table 1: Proposed contextual deﬁnition of a Web service.

Context C

Interface WS

{ Interface WS

{

int op

(string a); int op

(string a); string op

(string a, int b)}

string op

(string a, int b); string op

(string a, string b)}

string op

(int a)}

and there is no unique way to represent them.

Web services are described in WSDL language to

capture a set of functionalities that they offer and to

precise the description of input and output data that

they receive and deliver. The description of Web ser-

vices is necessary deﬁned according to a given con-

text or a given abstraction/conceptualization of the

real world. A context can be viewed as various cri-

teria such as the abstraction paradigm, the granular-

ity scale, interest of user communities, etc. So, a

same domain application (Travel agency, libraries, )

can have more than one set of Web services, where

each set describes the available functionalities in a

particular context. We call each one of these set of

web services, mono-representation web services. Our

motivation is to see how we can describe Web ser-

vices according to several contexts at the same time.

We shall call such Web services description a multi-

representation Web services (MuWS).

WSDL Languageis not capable of deﬁning a multi-

representation Web services. For instance, there isn’t

any possibility to deﬁne a unique WSDL descrip-

tion of a web service with different sets of func-

tionalities at the same time. So, our motivation of

this technical opinion is to deal with the problem of

multi-representation in the context of Web services

description. Our proposal can be illustrated through

the example given in Table 1. Let us consider three

real world representations, identiﬁed by the context

names C

and C

corresponding to administra-

tor, employee, and customer contexts. Some com-

ments made on Table 1 show the necessity of ex-

tending WSDL for the needs of Web services multi-

representation:

• Some operations are only visible in some contexts.

For instance, operation op

only appears in con-

texts C

and C

. It is not available in context C

• Some input and output parameter deﬁnitions differ

from one context to another. For instance, opera-

tion op

appears in the three contexts with two dif-

ferent parameter deﬁnitions.

• Some operation’s functionalities and results can

differ when context is switched to a different one.

For instance, the result of operation op

in context

can be more or less general than the result of the

same operation in other contexts.

From the point of view of Web services multi-

representation, many works can be considered. The

authors in (Spaccapietra et al., 2000) looked into the

multi-representation problem in spatial databases so

different geometries, resolutions, and scales are as-

sociated with the same spatial object. In Spaccapia-

tra et al.’s work, MADS was suggested as an extension

of the Entity-Relationship model. A stamping mech-

anism of data elements (concepts, attributes, and in-

stances) and relationships is suggested to enable ma-

nipulations of data elements from several represen-

tations. In object-oriented modeling, several object-

role languages are proposed to represent an object

with a single structure to be dynamically enhanced

with speciﬁc information (roles) related to its dif-

ferent facets (Gottlob et al., 1996; Pernici, 1990).

These languages allow, for instance, objects to move

from one type to another, to acquire new instances as

needed, and even to be dynamically regroupedto form

new classes while keeping their membership in their

original classes.

3 RUNNING SCENARIO

Consider the case of Melissa, a tourist who is visit-

ing Dubai. Upon arriving, she browses some Web

sites of tourist spots in and around Dubai. The top-

ranked Web site offers different Web services that can

be composed according to different ready-to-use pat-

terns (information on the use of Web services is not

released to Melissa). Melissa logs on at the Web

site and chooses sightseeing and shopping Web ser-

vices. Melissa’s plans are to visit outdoor places in

the morning and go shopping in the afternoon. The

ﬁrst part of the plan is subject to weather forecasts;

outdoor activities are cancelled in case of hot weather.

Initially Melissa is asked to select outdoor places, and

to indicate the pickup/drop-off times for sightseeing

and shopping.

With regard to the ﬁrst activity of Melissa’s plan,

sightseeing Web service consults with weather Web

service about the forecasts for the coming ﬁve days.

If there is no warning of hot weather, the scheduling

of the places to visit begins by ensuring that these

places are open for public on these days, and trans-

portation and guide are arranged. The logistics of

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

Melissa’s rides is assigned to transportation Web ser-

vice, which identiﬁes for instance the vehicle type

and the possibility that Melissa shares rides with other

tourists heading towards the same places. In case of

hot-weather warning, sightseeing Web service might

suggest otherplaces (e.g., museums)where indoor ac-

tivities can take place. Similar description applies to

shopping, which consists of checking out the running

promotions in the malls that Melissa has selected.

Transportation Web service coordinates shopping’s

beginning time with sightseeing’s ﬁnishing time.

Fig. 1 shows a rough representation of the Web ser-

vices chronology that implements Melissa scenario.

This chronology yields insight into the multiple chal-

lenges that a contextual model-driven approach faces

including: how is context related to Web services;

what are the types of information that feature con-

text; what are the different models to produce, and

how do we guarantee the consistency of mappingcon-

textual models onto contextual speciﬁcations of Web

services?

Sightseeing WS

Shopping WS Weather WS

Transportation WS

xor(hot weather)

and

Figure 1: Chronology of Web services in Melissa scenario.

4 TOWARDS A CONTEXTUAL

MODEL-DRIVEN APPROACH

Any contextual model-drivenapproachhas to take ad-

vantage of the OMG’s ﬁndings. OMG initiated the

development of the model-driven architecture (Miller

and Mukerji, 2001). This architecture is a framework

for system development that proposes specifying a

complete system with platform independent models

to be converted into multiple platforms according to

the system’s technical characteristics.

4.1 Deﬁnitions

A model graphically depicts a system’s structure and

behavior from a certain point of view and at a certain

level of abstraction (Sendall and Kozaczynski, 2003).

”A certain point of view” and ”at a certain level of

abstraction” constitute what we call here context of

the model.

During modeling, several aspects need to be geared

towards the type of context (e.g., time, location, user,

resource), which is under consideration. These ele-

ments include the amount of information that needs

to be included in the model, the representation and

organization of this information, the granularity level

of this information, and the relevancy (or rationale) of

this information for this context. Relying on a contex-

tual model-driven approach, an application will have

several models, where each model sheds the light

on the elements that are relevant to a speciﬁc con-

text (Section 2.2).

When a contextual model-driven approach is used,

it is expected that the speciﬁcations to obtain out

of this approach will have a dedicated structure that

identiﬁes context and makes it apparent in these spec-

iﬁcations through, for example, stereotypes, special-

ized tags, or constraints. Besides this dedicated struc-

ture, mechanisms to manage context are deemed ap-

propriate for inclusion in a contextual model-driven

approach. Context is sensed, acquired, reﬁned, and

distributed over the interested parties. In (Maamar

et al., 2006b), we discussed how a Web service con-

nects to context. A Web service requires awareness

mechanisms, so it can take advantage of the infor-

mation that context caters. These mechanisms col-

lect contextual raw data from sensors for the purpose

of detecting changes in the environment. A change

needs to beevaluated by the Web service’s assessment

module, so the deploymentmodule of the Web service

takes actions over the environment.

4.2 ContextUML - UML Extension

The basic understanding of Web services re-

volves around three steps: deﬁnition, announce-

ment/discovery, and binding. A fourth step, known

as composition, is added but does not directly con-

tribute to this understanding. The ﬁrst three steps fea-

ture the primary steps upon which a service-oriented

architecture is built: a service provider provides a ser-

vice, a service requestor is the client that requires a

service to be performed, and a service agency pro-

vides registration and discovery facilities. Since the

announcement step, which targets an UDDI registry,

is expected to happen independently of the surround-

ing environment of a Web service, we excluded this

step from our discussions on context integration into

a model-driven approach. We also exclude from this

paper how Web services bindings are contextualized.

We only present the extensions that need to be put

forward so the deﬁnition of Web services is contextu-

alized, i.e., contextual WSDL.

A model-driven approach has a formalism that is

used for representing the models to produce. In this

TOWARDS A CONTEXTUAL MODEL-DRIVEN DEVELOPMENT APPROACH FOR WEB SERVICES

Visibility

Situation

Context

Binding

VisibilityConstraint

Action

Assignment

Description

Action

Description

Visibility

Constraint

Assignment

1 *

Service description

Subject

Composite

Subject

Atomic

Subject

* 1 1

Figure 2: ContextUML metamodel.

paper, we adopt UML for three reasons: UML is the

de-facto standard for modeling systems, UML can

be extended, through UMLProﬁle (Amsden et al.,

2003), in order to meet the modeling speciﬁcities and

requirements of a particular application domain, and

several projects have successfully shown the map-

ping between UML models and Web services spec-

iﬁcations (Section 2.1). When it comes to extend-

ing UML, we refer to the work of Lodderstedt et al.,

who suggested SecureUML. It is a modelinglanguage

that deﬁnes a dedicated vocabulary for annotating

UML-based models with information related to secu-

rity access-control (Lodderstedt et al., 2002). More-

over, Bonnet has positively argued about the role of

UMLProﬁle in modeling Web services speciﬁcations

of type WSDL and BPEL (Bonnect, 2004). In this

paper, we propose ContextUML as a modeling lan-

guage that deﬁnes a dedicated vocabulary for anno-

tating UML-based models with information related to

context. Although Sheng and Benatallah propose also

ContextUML (Sheng and Benatallah, 2005), it is dif-

ferent from our ContextUML at the following levels.

1. We aim at extending the existing Web services’

speciﬁcations like WSDL at the meta-level;

2. We aim at developing generic contextual Web ser-

vices’ speciﬁcations regardless of the type of con-

text whether time, location, etc;

3. We aim at developing a contextual methodological

approachwhere the life cycle of a Web service from

deﬁnition, announcement, and binding is contextu-

alized.

Prior to integrating context into Web services spec-

iﬁcations, we make clear the levels of use of Contex-

tUML. We consider two levels: triggering and self-

management.

• A contextual speciﬁcation of a Web service at the

triggering level corresponds to the parts of a Web

service, which are made visible (i.e., accessible) ac-

cording to a speciﬁc context. By parts, we mean

the elements that populate for example a Web ser-

vice’s WSDL ﬁle. Interesting to note that the visi-

bility option at this level opens up the opportunity

of looking into the multi-representation issue of a

Web service (Section 2.2).

• A contextual speciﬁcation of a Web service at the

self-management level corresponds to the mecha-

nisms that permit a Web service to oversee the dif-

ferent compositions wherein it participates. These

mechanisms are thoroughly explained in our previ-

ous work (Maamar et al., 2005).

In this paper, ContextUML only concerns the trig-

gering level since the self-management level is in-

trinsic to a Web service and does not have to be

revealed to external parties. The categorization of

ContextUML’s levels of use into triggering and self-

management is backed by the work done in (Grφnmo

and Solheim, 2004). The authors consider that there

are two main aspects that can be modelled in the area

of Web services: the Web service and the workﬂow.

Web service modeling identiﬁes the functionalities

to be exposed with their interfaces and operations,

while workﬂow modeling identiﬁes the control and

data ﬂows from one component Web service to the

next component (this includes compensation in case

of execution failures of the Web service). The ﬁrst

type of modeling matches quite well the triggering

level of context use, and the second type of model-

ing matches quite well the self-management level of

context use.

4.3 Abstract Syntax of ContextUML

ContextUML or the UMLProﬁle for contextual Web

services is the outcome of extending UML with con-

structs dedicated to context. The objective of Contex-

tUML is to boost the formulation of context require-

ments at an earlier stage of the life cycle development

of Web services. ContextUML permits ﬁrst, to ex-

plicitly integrate context into the speciﬁcation meta-

models of Web services (e.g., WSDL), and second, to

facilitate the mapping of these contextual metamodels

onto concrete languages to be enhanced with context

constructs (Section 4.4).

Fig. 2 presents the metamodel diagram of the ab-

stract syntax of ContextUML. The left part of the

diagram presents a subject that is aware of its sur-

rounding environment through context. Subject is

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

ExtensibleElement

Action

(from contextUML)

Port Type Message PortTypeService

AtomicSubject

(from contextUML)

Binding

Part

Operation

Definition

hide/expose

WSDLElement

Description

(from contextUML)

Figure 3: Integration of ContextUML metamodel into WSDL metamodel.

an element of type service, which changes its be-

havior (e.g., operation interface, conversation proto-

col) according to the changes reported in the context.

Independently of the specialization of Subject into

CompositeSubject (i.e., composite Web service) and

AtomicSubject (i.e., Web service), Subject binds to

Context. Context tracks and assesses the changes in

the environment of a subject. These changes are mul-

tiple ranging from time and location to access privi-

leges and resource scheduling.

Still in Fig. 2, the right part of the diagram high-

lights the visibility mechanisms. Visibility is the

capacity of a context-aware subject to adapt its de-

scription because of a given context. This adaptation

happens with the use of Action that corresponds to

the operations to perform over the description of a

subject. The rationale of this performance is to ex-

pose/hide some elements of a subject to/from other

subjects. An example of process visibility is dis-

cussed in (Ba¨ına et al., 2005). Finally, Description

corresponds to the speciﬁcation of a subject for ex-

ample in WSDL. It should be noted that Visibility

is framed using VisibilityConstraint, which permits

achieving the consistency of the description of a sub-

ject after adaptation.

The VisibilityConstraint represents the frame-

work through which the expose and hide operations

are implemented. As part of our work we will be de-

veloping a Context Constraint Language (CCL), as an

enhancement of UML’s OCL, for specifying visibility

constraints. In particular, we will be enhancing OCL

for specifying pre- and post-conditions to run over a

description of type WSDL speciﬁcation.

According to (Srivastava and Koehler, 2003), the

functionality of a Web service needs to be described

with additional pieces of information including se-

mantic annotation of what it does and functional an-

notation of how it behaves. The contextual deﬁnition

of a Web service enables the adaptation of seman-

tic and functional annotations to be adaptable accord-

ing to the context wherein this Web service evolves,

i.e., the different compositions in which the Web ser-

vice participates. Hence the ﬁrst step of developing

a contextual WSDL is to extend the abstract syntax

of WSDL with the vocabulary of ContextUML. In

Fig. 3, the extension of WSDL is represented and oc-

curs by importing constructs from the ContextUML

metamodel (Fig. 2). Thus, WSDL will now include

more constructs such as visibility and context.

After a thoroughanalysis of WSDL metamodel,we

established a list ofelements to be subject to contextu-

alization in a WSDL speciﬁcation: Port, Type, Mes-

sage, Binding, and PortType. These elements are

all derived from Description of ContextUML meta-

model. Using Visibility, expose/hide actions are ex-

ecuted over each of these elements. More details on

the executionof these actions are givenin Section 4.4.

Besides Port, Type, Message, Binding, and PortType

elements, additional elements are added because the

semantics of ContextUML states that the contextual-

ized of a description means the contextualization of it

constituents (e.g., Part with regard to Message, and

Operation with regard to PortType and Binding). In

Fig. 3, it is also shown that Service is derived from

AtomicSubject of the ContextUML metamodel.

4.4 Concrete Syntax of ContextUML

Using the running scenario of Section 3, we

now illustrate the concrete syntax of Contex-

TOWARDS A CONTEXTUAL MODEL-DRIVEN DEVELOPMENT APPROACH FOR WEB SERVICES

<<ContextUML.Context>>

ServiceContext

<<ContextUML.Description>>

SightseeingPortType

<<ContextUML.AtomicSubject>>

DubaiSightseeingService

<<ContextUML.ContextBinding>>

<<ContextUML.Visibility>>

PortTypeVisibility

<<ContextUML.Action>> PortType.expose

<<ContextUML.Action>> PortType.hide

<<ContextUML.Description>>

SightseeingBinding

<<ContextUML.Visibility>>

BindingVisibility

<<ContextUML.Action>> Binding.expose

<<ContextUML.Action>> Binding.hide

<<ContextUML.Description>>

SightseeingMessage

<<ContextUML.Visibility>>

MessageVisibility

<<ContextUML.Action>> Message.expose

<<ContextUML.Action>> Message.hide

<<ContextUML.Description>>

SightseeingDefinition

<<ContextUML.Visibility>>

DefinitionVisibility

<<ContextUML.Action>> Definition.expose

<<ContextUML.Action>> Definition.hide

Figure 4: Concrete description of a Web service using contextual WSDL metamodel.

tUML in Fig. 4. Each Web service of the sce-

nario like sightseeing and transportation is rep-

resented by an UML class with the stereotype

<<ContextUML.AtomicSubject>>. In addition the

context of a Web service is deﬁned as an UML class

with the stereotype <<ContextUML.Context>>.

The connection between Web service and context

is illustrated using a dependency and the stereotype

<<ContextUML.ContextBinding>>.

The rest of Fig. 4 speciﬁes a visibility situa-

tion that involves the description of a Web ser-

vice. We focus on Port, Type, Message, Bind-

ing, and PortType constituents of this descrip-

tion. A visibility along with its relation to ac-

tion and description (<<ActionAssignment>> and

<<ActionDescription>>, respectively as reported in

Fig. 2) is deﬁned with a single UML association that

has the stereotype <<ContextUML.Description>>.

This association connects context to these ﬁve con-

stituents subject to contextualization. Each con-

stituent is represented as an UML class with the

stereotype <<ContextUML.Description>>. For ex-

ample the message constituent of a WSDL speciﬁ-

cation of sightseeing Web service is represented as

UML class denoted by SightseeingMessage and the

stereotype <<ContextUML.Description>>. In ad-

dition each attribute of the association represents the

actions that could be carried out over a description, in

that case a WSDL speciﬁcation. An action is identi-

ﬁed by the name of a WSDL constituent and its na-

ture whether expose or hide. It should be noted at

this point of time constraints through VisibilityCon-

straint are not yet integrated into Fig. 4.

5 CONCLUSION

In this paper we presented our contextual model-

driven approach for Web services with emphasis on

their deﬁnition. The features of the environment

in which Web services operate were modelled using

context. Our aim is to develop contextual speciﬁca-

tions of Web Services using ContextUML an exten-

sion of UML using UMLProﬁle. Future work will fo-

cus on the application of our approachto modelingthe

control and data ﬂow of the Web services workﬂows,

including exception handling and compensation. We

will also be focusing on developing the context con-

straint language.

ACKNOWLEDGMENTS

The authors wish to thank R. Hauser from IBM Re-

search Lab in Zurich, Switzerland for his feedback.

The fourth author wishes to thank his manager, K.

Muralidharan, for supporting his work. Other com-

pany (i.e., non-IBM), product and service names may

be trademarks or service marks of others.

REFERENCES

Amsden, J., Gardner, T., Grifﬁn, C., and Iyengar,

S. (2003). Draft UML 1.4 Proﬁle for Auto-

mated Business Processes with a Mapping to

BPEL 1.0. Technical report, IBM. http://www-

128.ibm.com/developerworks/rational/library/4593.html.

Arara, A. and Benslimane, D. (2004). Towards Formal

Ontologies Requirements with Multiple Perspectives.

In Proceedings of The 6th International Conference

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

on Flexible Query Answering Systems (FQAS’2004),

Lyon, France.

Backx, N. (2004). Model-Driven Architecture for Web Ser-

vices Applications. Technical report, University of

Twente, The Netherlands, and Universidade Federal

do Esp´ırito Santo, Brazil.

Ba¨ına, K., Benali, K., and Godart, C. (2005). DISCOBOLE:

A Service Architecture for Interconnecting Workﬂow

Processes. Computers in Industry - Special issue Con-

current Engineering (CE’03), Elsevier Science Pub-

lisher.

Ba¨ına, K., Benatallah, B., Casati, F., and Toumani, F.

(2004). Model-Driven Web Service Development. In

Proceedings of The 16th Conference On Advanced In-

formation Systems Engineering (CAiSE’2004), Riga,

Latvia.

B´ezivin, J., Hammoudi, S., Lopes, D., and Jouault, F.

(2004). Applying MDA Approach for Web Ser-

vice Platform. In Proceedings of The 8th Interna-

tional Enterprise Distributed Object Computing Con-

ference (EDOC’2004), Monterey, CA, USA.

Birman, K. P. (2004). Like It or Not, Web Services Are

Distributed Objects. Communications of the ACM,

47(12).

Bonnect, P. (2004). Offshore + MDA + SOA,

Vers L’ing´enierie des Mod`eles. Technical report.

http://www.orchestranetworks.com/.

Bordbar, B. and Staikopoulos, A. (2004). On Behavioural

Model Transformation in Web Services. In Proceed-

ings of The 5th International Workshop on Conceptual

Modeling Approaches for e-Business (eCOMO’2004)

held in conjunction with The 23rd International Con-

ference on Conceptual Modeling (ER’2004), Shang-

hai, China.

Gottlob, G., Schreﬂ, M., and Rck, B. (1996). Extending

Object-oriented Systems with Roles. ACM Transac-

tions on Information systems, 14(3).

Grφnmo, R., Skogan, D., Solheim, I., and Oldevik,

J. (2004). Model-Driven Web Services Develop-

ment. In Proceedings of The 2004 IEEE Interna-

tional Conference on e-Technology, e-Commerce and

e-Service (EEE’2004), Taipei, Taiwan.

Grφnmo, R. and Solheim, I. (2004). Towards Model-

ing Web Service Composition in UML. In Proceed-

ings of The 2nd International Workshop on Web Ser-

vices: Modeling, Architecture and Infrastructure (WS-

MAI’2004) held in conjunction with The 6th Inter-

national Conference on Enterprise Information Sys-

tems (ICEIS’2004), Porto, Portugal.

Huhns, M. (2002). Agents as Web Services. IEEE Internet

Computing, 6(4).

Kulkarni, N., Kumar, S., Mani, S., and Padmanabhuni, S.

(2005). Web Services: E-Commerce Partner Integra-

tion. IEEE IT Professional, 7(2).

Lodderstedt, T., Basin, D., and Doser, J. (2002). Se-

cureUML: A UML-Based Modeling Language for

Model-Driven Security. In Proceedings of The

5th International Conference on the Uniﬁed Mod-

eling Language - The Language and its Applica-

tions (UML’2002), Dresden, Germany.

Ma, K. L. (2005). Web Services: What’s Real and What’s

Not. IEEE IT Professional, 7(2).

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

What Can Context do for Web Services? Communi-

cations of the ACM. (to appear).

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).

Maamar, Z., Narendra, N. C., and Sattanathan, S. (2006b).

Towards an Ontology-based Approach for Specifying

and Securing Web Services. Journal of Information &

Software Technology, Elsevier Science Publisher. (to

appear).

Mellor, S. J., Clark, A. N., and Futagami, T. (2003). Intro-

duction to the Special Issue on Model-Driven Devel-

opment. IEEE Software, 20(5).

Miller, J. and Mukerji, J. (2001). Model Driven Archi-

tecture. Technical Report ormsc/2001-07-01, Object

Management Group. www.omg.com/mda.

Pernici, B. (1990). Objects with Roles. In Proceedings of

The ACM Conference on Ofﬁce Information Systems,

Cambridge, Massachusetts, US.

Sendall, S. and Kozaczynski, W. (2003). Model Transfor-

mation: The Heart and Soul of Model-Model-Driven

Software Development. IEEE Software, 20(5).

Sheng, Q. Z. and Benatallah, B. (2005). ContextUML:

A UML-based Modeling Language for Model-driven

and Context-Aware Web Services. In Proceedings

of The 4th International Conference on Mobile Busi-

ness (ICMB’2005), Sydney, Australia.

Spaccapietra, S., Parent, C., and Vangenot, C. (2000).

GIS Databases: From Multiscale to MultiRepresen-

tation. In Proceedings of The 4th International Sym-

posium Abstraction, Reformulation, and Approxima-

tion (SARA’2004), Horseshoe Bay, Texas, USA.

Srivastava, B. and Koehler, J. (2003). Web Service Com-

position - Current Solutions and Open Problems. In

Proceedings of The Workshop on Planning for Web

Services held in conjunction with The 13th Interna-

tional Conference on Automated Planning & Schedul-

ing (ICAPS’2003), Trento, Italy.

Zarras, A., Vassiliadis, P., and Issarny, V. (2004). Model-

Driven Dependability Analysis of Web Services. In

Proceedings of The 6th International Symposium on

Distributed Objects and Applications (DOA’2004),

Larnaca, Cyprus.

TOWARDS A CONTEXTUAL MODEL-DRIVEN DEVELOPMENT APPROACH FOR WEB SERVICES