TOWARDS AN AGENT-BASED AND CONTEXT-ORIENTED

APPROACH TO COMPOSE WEB SERVICES

Zakaria Maamar

, Soraya Kouadri Most

efaoui

, Hamdi Yahyaoui

, and Willem Jan van den Heuvel

Zayed University, Dubai, U.A.E

University of Fribourg, Fribourg, Switzerland

Laval University, Quebec, Canada

Tilburg University, Tilburg, The Netherlands

Keywords:

Web service, software agent, composition, context, conversation.

Abstract:

We present an agent-based and context-oriented approach for the composition of Web services. A Web service

is an accessible application that other applications and humans can discover and trigger to satisfy multiple

needs (e.g., hotel booking). Because of the complexity that characterizes the composition of Web services,

two concepts in this paper are put forward to reduce this complexity namely software agent and context. A

software agent is an autonomous entity that acts on behalf of users, whereas context is any relevant information

that characterizes a situation. During the composition process, software agents engage conversations with their

peers to agree on which Web services will participate in this process. In these conversations, agents take into

account the execution context of the Web services.

1 INTRODUCTION

Web services are nowadays emerging as a major tech-

nology for deploying automated interactions between

distributed and heterogeneous applications. Various

technologies back this deployment such as WSDL,

UDDI, and SOAP (Curbera et al., 2003). The tech-

nologies cited support the deﬁnition of Web services,

their advertisement to the community of users, and ﬁ-

nally their binding for triggering purposes.

A Web service is an accessible application that

other applications and humans can automatically dis-

cover and invoke (Benatallah et al., 2003). In gen-

eral, composing multiple Web services (also called

services in the rest of the paper) rather than access-

ing a single service is essential and provides more

beneﬁts to users (Berardi et al., 2003). Discovering

the component services, inserting the services into a

composite service, triggering the composite service

for execution, and monitoring this execution for the

needs of exception handling are among the opera-

tions that users will have to be responsible. Most of

these operations are complex, although repetitive with

a large segment suitable to computer aid and automa-

tion. Therefore, Software Agents (SAs) are deemed

appropriate to assist users in their operations. A SA is

an autonomous entity that acts on user’s behalf, makes

decisions, interacts with other agents, and migrates to

distant hosts if needed (Jennings et al., 1998).

Entrusting the composition of Web services to soft-

ware agents is challenging. Various challenges need

to be tackled including which businesses have the ca-

pacity to provision Web services, when and where

the provisioning of Web services occurs, how Web

services from separate businesses are coordinated so

conﬂicts are avoided, and what back-up strategies

handle execution exceptions of Web services. To

address a part of these issues, agents need to be

aware of the context in which the composition and

execution of the Web services happen. Context is

the information that characterizes the interaction be-

tween humans, applications, and the surrounding en-

vironment (Br

ezillon, 2003). For instance, before

provisioning a Web service for execution the com-

puting capabilities of the resources vs. the comput-

ing requirements of the Web service needs to be as-

sessed. In addition, before deploying any back-up

strategy an assessment of the type of exception is re-

quired. In this paper, we present our agent-based and

context-oriented approach for Web services compo-

sition. Existing approaches for service composition,

such as WSFL and BPEL4WS, typically facilitate or-

chestration only, while neglecting information about

the context surrounding users and services.

In our agent-based and context-oriented approach,

we leverage the interactions that occur between agents

during the composition of Web services to the level

of conversations. A conversation is a consistent ex-

change of messages between participants involved

in joint operations and thus, have common interests.

Agents engage conversations with their peers when it

comes for example to search for the component ser-

214

Maamar Z., Kouadri Mostéfaoui S., Yahyaoui H. and Jan van den Heuvel W. (2004).

TOWARDS AN AGENT-BASED AND CONTEXT-ORIENTED APPROACH TO COMPOSE WEB SERVICES.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 214-221

DOI: 10.5220/0002600102140221

 SciTePress

vices, to check the availability of these services, and

to trigger these services.

Section 2 deﬁnes Web services. Section 3 presents

the agentiﬁcation of Web services composition. Sec-

tion 4 discusses the implementation of the discussed

approach. Section 5 overviews related work. Finally,

Section 6 draws our conclusions and summarizes our

future work. We note at that level that the mecha-

nisms for discovering the component Web services

of a composite service, while important, do not fall

within the scope of this paper.

2 BACKGROUND - WEB

SERVICES

A Web service is an accessible application that other

applications and humans as well can discover and

trigger. A Web service is (Benatallah et al., 2003):

(i) independent as much as possible from speciﬁc

platforms and computing paradigms; (ii) developed

mainly for inter-organizational situations rather than

for intra-organizational situations; and (iii) easily

composable (i.e., its composition with other Web ser-

vices does not require complex adapters).

For the needs of our research on Web services such

as the one we conducted in (Maamar and Mansoor,

2003), we developed Service Chart Diagrams (SCDs)

as a speciﬁcation means (Maamar et al., 2003). A

SCD leverages the state chart diagram of UML (Harel

and Naamad, 1996), putting the emphasize on the

context surrounding the execution of a Web service

rather than only on the states of a Web service (Fig. 1).

Data from

previous services

Data to

next services

Perfor. type

(local or remote)

2

3

Previous

services (M/O)

Next

services (M/O)

Business1

Service

Layers

in

State 

1

State 

2

B

State 

j

E

State 

3

out

Figure 1: Service chart diagram

A SCD wraps the states of a Web service into

ﬁve perspectives, each perspective having a set of at-

tributes. The state perspective corresponds by default

to the state chart of the service. The ﬂow perspec-

tive corresponds to the execution chronology of the

composite service in which the service appears (Pre-

vious services/Next services attributes - M/O respec-

tively stands for Mandatory and Optional). The busi-

ness perspective identiﬁes the organizations that are

ready for providing the service (Business attribute).

The information perspective identiﬁes the data that

are exchanged between the services of the compos-

ite service (Data from previous services/Data for next

services attributes). Because these services can be ei-

ther mandatory or optional, the information perspec-

tive is tightly coupled to the ﬂow perspective with re-

gard to the mandatory data and optional data. Finally,

the performance perspective illustrates the ways (re-

motely or locally) the service is invoked for execution

(Performance type attribute).

Because a composite service is made of up of sev-

eral component services, the process model underly-

ing this composite service is speciﬁed as a state chart

diagram whose (i) states are associated with the ser-

vice chart diagrams of the component services (Fig. 1)

and (ii) transitions are labelled with events, condi-

tions, and variable assignment operations.

3 AGENTIFICATION OF WEB

SERVICES COMPOSITION

Three types of input sources can contribute to the

development of a context: service, user, or both.

In (Roman and Campbell, 2002), the authors observe

that a user-centric context promotes applications that

(i) move with users, (ii) adapt according to changes

in the available resources, and (iii) provide conﬁgu-

ration mechanisms based on users’ preferences. We

advocate that a service-centric context promotes ap-

plications that (i) allow service adaptability, (ii) deal

with service availability, and (iii) support on-the-ﬂy

service composition. In this paper, the focus is on the

context of services.

3.1 Agent-based deployment

The objective of agentifying Web services composi-

tion is to determine the appropriate types and roles

of agents that will deploy this composition. Cur-

rently, we are considering three types of agents:

composite-service-agent, master-service-agent, and

service-agent.

We consider a Web service as a component that is

instantiated each time it participates in a composition.

Before the instantiation happens, several elements re-

lated to the Web service have to be checked. These

elements constitute a part of the context, denoted by

W-context, of the Web service and are as follows:

• The number of service instances currently running

vs. the maximum number of service instances that

simultaneously can be run.

• The execution status and location of each service

instance deployed.

• And, the time of request of the service instance

vs. the time of availability of the service instance.

The role of the master-service-agent is to track the

Web service instances that are obtained from a Web

service. Master-service-agents, Web services, and

TOWARDS AN AGENT-BASED AND CONTEXT-ORIENTED APPROACH TO COMPOSE WEB SERVICES

215

W-contexts are all stored in a pool (Fig. 2). A master-

service-agent processes the requests of instantiation

that are submitted to a Web service. These requests

originate from composite-service-agents of the com-

posite services to set-up. For instance, the master-

service-agent makes decisions on whether a Web ser-

vice is authorized to join a composite service. In case

of approval, a service instance and a context, denoted

by I-context, are created. An authorization can be

rejected because for example of overloaded status.

To be informed about the running instances of a

Web service so the W-context is updated, the master-

service-agent associates each instance created with

two components: a service-agent and an I -context.

The service-agent manages the service chart diagram

(Fig. 1) and the I-context of the service instance. For

example, the service-agent knows the states that the

service instance will take, and the Web services that

need to join the composite service after the execution

of this service instance is completed.

Master-service-agents and service-agents are in

constant interactions. Indeed, the I-contexts feed the

W-contexts with various details including:

1. What is the execution status (in-progress, sus-

pended, aborted, ...) of a service instance?

2. When is the execution of a service instance sup-

posed to resume in case it has been suspended?

3. When is the execution of a service instance ex-

pected to complete? What kind of completion is

expected: success or failure?

4. What are the corrective actions that are taken in

case the execution of a service instance fails?

With regard to composite-service-agents, their role

is to trigger the speciﬁcations of the composite ser-

vices and monitor the deployment of these speciﬁ-

cations. A composite-service-agent ensures that the

appropriate component services are involved and col-

laborate according to a certain speciﬁcation. When

a composite-service-agent downloads the speciﬁca-

tion of a composite service, it (i) establishes a context

denoted by C-context for the composite service, and

(ii) identiﬁes the ﬁrst Web services to be triggered.

For the sake of simplicity, we assume that the Web

services constitute a sequence. It is needless to say

that our description of service deployment is applica-

ble to any type of chronology. When the ﬁrst Web

service is known, the composite-service-agent inter-

acts with the master-service-agent of this Web service

in the objective to ask for a service instantiation.

If the master-service-agent agrees on this instanti-

ation after checking the W-context, a service-agent

and an I-context are set up. Afterwards, the service

chart diagram of the new service-instance is trans-

ferred to the service-agent. The service-agent initiates

the execution of the service instance and notiﬁes the

master-service-agent about the execution status. Be-

cause of the regular notiﬁcations occurring between

service-agents and master-service-agents, exceptions

are immediately handled. In addition, while the Web

service instance is being performed, the service-agent

deﬁnes the next Web services after this service in-

stance (Fig. 1). In case there are Web services, the

service-agent requests from the composite-service-

agent to engage conversations with their respective

master-service-agents.

The aforementioned description of the agentiﬁca-

tion approach presents potential advantages for man-

aging services all along their life-cycle, from prepara-

tion to deployment and recomposition if needed. The

most prominent advantage is the concurrency exist-

ing between the composition and execution of the ser-

vices. While service-agents are in charge of executing

the Web service instances, composite-service-agents

engage at the same time conversations with master-

service-agents to ensure that the next Web services

are got ready for execution.

Session of composite service 

1

SCD-Web

service 

1

SCD-Web

service 

2

SCD-Web

service 

3

SCD-Web

service 

4

I-Context

Update

I-Context

Update

Interactions Pool of Master-

service-agents

W-Context

C-Context

Store of composite

service specifications

Access

SCD: Service Chart DiagramComposite-service-agent Service-agent Master-service-agent

Figure 2: Agents deployment for Web services composition

Fig. 2 represents an execution session of the com-

posite service CS

. It has 4 primitive component ser-

vices. Each service instance is associated with a ser-

vice chart diagram. The clouds in this ﬁgure corre-

spond to contexts. I-context is the core context that

the service-agent uses for updating the C-context and

W-context of the respective composite-service-agent

and master-service-agent. The exchange of informa-

tion occurring between a master-service-agent and a

service-agent has already been discussed. In addition

to a copy (or a part based on the level of details that

needs to be tracked) of that exchange that is sent to

composite-service-agents, these ones receive the fol-

lowing from service-agents: (i) the next services to be

called for execution, and (ii) the type of these services

whether mandatory or optional.

3.2 Value-added of and details on

I/W/C-contexts

Besides the three types of agents that are identiﬁed

during the agentiﬁcation of Web services composi-

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

216

tion (Fig. 2), three types of services were considered:

composite service, Web service, and Web service in-

stance. Each service has been attached to a context.

The I-context is the most-grained one, whereas the C-

context is the least-grained one. The W -context is in

between the two contexts. Details on an I-context are

used for updating a W-context. Furthermore, details

on a W-context are used for updating a C-context. We

are using Tuple Spaces to implement the update op-

erations between contexts (Ahuja et al., 1986). How-

ever, to keep the paper self-contained these operations

are not discussed

. In what follows, we highlight the

structure of each context and discuss the value-added

of contexts to the composition of Web services.

The I-context of a Web service instance consists of

the parameters: label, service-agent label, status, pre-

vious service instances, next service instances, reg-

ular actions, begin time, end time (expected and ef-

fective), reasons of failure/suspension, corrective ac-

tions, and date.

The W-context of a Web service is built upon the

I-contexts of its respective Web service instances

and consists of the parameters: label, master-service-

agent label, number of instances allowed, number of

instances running, next service instance availability,

status/service instance, and date.

The C-context of a composite service is built upon

the W-contexts of its respective Web services and

consists of the parameters: label, composite-service-

agent label, previous Web services, current Web ser-

vice, next Web services, begin time, and date.

In the beginning of Section 3 we pointed out that

our focus is on service-centric context. This is shown

with the W-context of a Web service that connects

I-contexts and C-contexts. A service-centric context

promotes service adaptability, availability, and on-

the-ﬂy composition. These requirements are met in

our agentiﬁcation approach. A composite service may

have to adapt its list of component Web services be-

cause of the availability of certain components. Avail-

ability has been illustrated with two cases: (i) a ser-

vice is either mandatory or optional, and (ii) the maxi-

mum number of services instances that can be created

with regard to the current number of service instances

that are running. Since Web services are instantiated

on a request-basis, this means that a composition of

type on-the-ﬂy is supported.

Since a service-centric context is adopted, we see

a W-context of a Web service along three intercon-

nected perspectives (Fig. 3): instance, execution, and

A sample of a control tuple illustrating an update

between contexts: modiﬁed(I-context i, WebServiceIn-

stance wsi)[true]—update(W-context w, WebService ws)

means that if the I-context i of the Web service instance wsi

has been modiﬁed, therefore the respective W-context w of

the web service ws needs also to be updated after collecting

information from this I-context i.

time. Rationale of each perspective is as follows.

1. Instance perspective is concerned with creating ser-

vice instances, getting them reading, and ﬁnally as-

signing them to composite services.

2. Execution perspective is concerned with meeting

the computing resource requirements of service in-

stances, tracking their execution, and avoiding con-

ﬂicts on these computing resources.

3. Time perspective is concerned with time-related

parameters of and constraints on service instances.

Instance

Time

Execution

Deployment

Tracking

Availability

Figure 3: Perspective-based representation of context

Fig. 3 shows that instance, execution, and time per-

spectives are all interconnected. First, deployment de-

notes the connection between instance and execution

perspectives, which reﬂects the instantiation of Web

services for the needs of execution. Second, tracking

denotes the connection between execution and time

perspectives, which reﬂects the monitoring of the in-

stances of Web services that occurs over a certain pe-

riod of time. Finally, availability denotes the connec-

tion between time and instance perspectives, which

reﬂects the continuous veriﬁcation the Web services

perform before these Web services commit additional

service instances for a certain period of time.

The use of context ensures that the requirements

and constraints of the services to participate in a com-

position are considered. While current Web services

composition approaches rely on different selection

criteria such as execution cost, and reliability, we

deem appropriate to integrate the context of services

into this composition. Doulkeridis et al. also back

the importance of including context during Web ser-

vices composition (Doulkeridis et al., 2003). We have

shown that services take part in a composition based

on their availability and the current needs of the com-

posite services in component services. Moreover, the

use of context is suitable for tracing the execution of

Web services during exception handling. It would be

possible at any time to know what happened, what

is happening with a Web service and all its respec-

tive instances. Predicting what will happen to a ser-

vice could also be feasible in case the previous con-

texts (i.e., what happened with a service) are stored.

TOWARDS AN AGENT-BASED AND CONTEXT-ORIENTED APPROACH TO COMPOSE WEB SERVICES

217

In (Kouadri Most

efaoui, 2003), Kouadri Most

efaoui

makes a reference to different types of context: user,

computing, time, physical, and history. History con-

text stores details on other contexts for future and fur-

ther use. Applications can make use of not just the

current context, but also past contexts to adapt their

behavior for better actions and interactions with users.

3.3 Conversations and composition

In the following and for the sake of simplicity, a com-

ponent service always refers to a Web service. In

a reactive composition such as the one that features

our agentiﬁcation approach (Chakraborty and Joshi,

2001), the selection of the component services to con-

stitute a composite service is done on-the-ﬂy. We out-

source the selection operations to composite-service-

agents that engage conversations with the respective

master-service-agent of the Web services. In these

conversations, master-service-agents decide if their

Web service will join the composition process after

checking the C-contexts. In case of a positive deci-

sion, Web service instances, service-agents, and I-

contexts are deployed.

When a Web service instance is being executed, its

service-agent checks the service chart diagram of this

instance. The purpose is to verify if extra Web ser-

vices are needed. If yes, the service-agent requests

from the composite-service-agent to engage conver-

sations with the master-service-agents of these Web

services. These conversations have two aims: (i) in-

vite master-service-agents and thus their Web service

to participate in the composition process; and (ii) en-

sure that the Web services are got ready for instantia-

tion in case of invitation acceptance.

Fig. 4 depicts a conversation diagram between

a service-agent, a composite-service-agent, and a

master-service-agent. The composite-service-agent is

in charge of a composite service that has n compo-

nent Web services

(1, ··· , i, j, ··· , n)

. In Fig. 4, rounded

rectangles are states (states with underlined labels be-

long to Web service instances, whereas other states

belong to agents), italic sentences are conversations,

and numbers are the chronology of conversations. Ini-

tially, Web service instance

takes an execution state.

Further, service-agent

and the composite-service-

agent take each a conversation state. In these conver-

sation states, activities to ask the participation of the

next Web services (i.e., Web service

) are performed.

Upon receiving a request from service-agent

about

the need to involve Web service

(0), the composite-

service-agent engages conversations with master-

service-agent

(1). This service is an element of

the composite service under preparation. A com-

posite service is decomposed into three parts. The

ﬁrst part corresponds to the Web service instances

that have already completed their execution (Web

services

1, ··· , i−1

). The second part corresponds to the

Web service instance that is now being executed (Web

service instance

). Finally, the third part corresponds

to the rest of the composite service that is due for exe-

cution and hence, has to get ready for execution (Web

services

j, ··· , n

). Initially, master-service-agent

is in

a monitoring mode; it tracks the instances of Web

service

that are currently participating in different

composite services. When it receives a request to cre-

ate an additional instance, master-service-agent

en-

ters the assessment state. Based on the W-context

of Web service

, master-service-agent

evaluates the

request of the composite-service-agent and makes a

decision on one of the options: decline the request,

delay its making decision, or accept the request.

Option a. Master-service-agent

of Web service

de-

clines the request of the composite-service-agent.

A conversation message is sent back from master-

service-agent

to the composite-service-agent for

information (2.1). Because a component service

can be either mandatory or optional in a compos-

ite service, the composite-service-agent has to de-

cide whether it has to pursue with master-service-

agent

. To this end, the composite-service-agent

relies on the speciﬁcation of Web service

and the

C-context of the composite service. Two exclusive

cases are offered to the composite-service-agent:

• If Web service

is optional, the composite-

service-agent enters again the conversation state,

asking the master-service-agent of another Web

service

k, (k 6= j)

(i.e., a substitute) to join the

composite service (1).

• Otherwise (i.e., Web service

is mandatory), the

composite-service-agent engages further conver-

sations with master-service-agent

asking for ex-

ample for the reasons of rejection or the avail-

ability of the next instance of Web service

Option b. Master-service-agent

of Web service

cannot make a decision before the response

deadline that the composite-service-agent has

ﬁxed. Thus, master-service-agent

requests from

the composite-service-agent to extend the dead-

line (2.2). The composite-service-agent has two al-

ternatives based on the C-context of the composite

service and the fact that a component service can

be either mandatory or optional:

• Refuse to extend the deadline as master-

service-agent

has requested; this means

that the composite-service-agent has to start

again conversing with another master-service-

agent

k, (k 6= j)

(Option a).

• Accept to extend the deadline as master-service-

agent

has requested; this means that master-

service-agent

will get notiﬁed about the ac-

ceptance of the composite-service-agent (2.2.1).

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

218

I-Context

Conversation

1. Request to join

a composite service

2.1 Decline to join

Monitoring

Assessment

Request

considered

2.2 Request to delay

Assessment

Preparation

Decision made

Conversation

Web service

instance 

i 

done

Composite-service-agent

2.2.1 Accept to delay

Reject to

delay/decline

2.3 Accept to join Service to

get ready

Execution

Conversation

Web service 

j

Master-service-agent 

j

Execution Conversation

0. Web service

needed

Invitation

accepted

Execution

with success

Service-agent 

i

Web service

instance 

i

Service-agent 

j

Web service

instance 

j

Deployment

later on

Conversation

Invocation Web service instance 

j

W-Context

C-Context

I-Context

Figure 4: Conversation diagram between agents

After receiving the acceptance, master-service-

agent

of Web service

enters again the assess-

ment state and checks the W -context in order to

make a decision on whether to join the composite

service (Option a). A master-service-agent may

request a deadline extension for several reasons

such as additional instances of Web service

can-

not be committed before other instances com-

plete their execution.

Option c. Master-service-agent

of Web service

ac-

cepts to join the composite service. Consequently,

it informs its acceptance to the composite-service-

agent (2.3). This is followed by a Web Ser-

vice Level Agreement (WSLA) between the two

agents (Ludwig et al., 2002). At the same time,

master-service-agent

ensures that Web service

getting ready for execution through the preparation

state (i.e., deploy I-context and service-agent

When the execution of Web service instance

terminated, service-agent

informs the composite-

service-agent about that. According to the agree-

ment that was established in Option c, the composite-

service-agent interacts with service-agent

so the

newly-created instance of Web service

is triggered.

Therefore, Web service instance

enters the execution

state. At the same time, the composite-service-agent

initiates conversations with the master-service-agents

of the next Web services that follow Web service

. It

should be noted that the content of agreements is be-

yond this paper’s scope.

4 PROTOTYPE

IMPLEMENTATION

Based on the approach introduced in Section 3, we are

in the process of implementing a prototype. Its archi-

tectural overview is depicted in Fig. 5. In what fol-

lows we outline the functionality of the major classes

of the prototype:

• Service chart diagram: is used to specify Web ser-

vices and Web Services instances.

• State chart diagram: is used to specify the compos-

ite services. It is an aggregation of the different

service chart diagrams that correspond to the Web

services participating in the composition.

• Agents: the agents set of classes (service agent,

master service agent, and composite service agent)

is used to specify the agents of the prototype.

The service agent and the composite service agent

classes are associated with the Web service in-

stance and the composite service classes respec-

tively. Each agent has a label, type, and loca-

tion (platform where it resides).

• Context: the context set of classes (I-context, W-

context, C-context) is responsible for gathering,

processing and parsing contextual information. It

translates the information parsed into XML doc-

uments and attaches each context to its respec-

tive agent (service agent, master service agent, and

composite service agent).

• Conversation: is the central unit for managing

and maintaining conversations between the differ-

TOWARDS AN AGENT-BASED AND CONTEXT-ORIENTED APPROACH TO COMPOSE WEB SERVICES

219

Agents

FIPA, Aglets, Jade, Leap

Service Agent



Web Service



Service Chart Diargram

specified by

Master Service Agent

1..1

Composite Service Agent



Composite Service

instantiated

Web Service Instance

+Label

+Location

+Type



+Label

+Location

+Type



+Name

+ID: 

+Location

+State

+Label

+Location

+Type



+Name

+ID

+Perspectives



+Name

+ID: 

+Location

+Services



+Name

+ID: 

+Location

+Instances



1..*

associated with

1..1



participates in

1..*

specified by

1..1

associated with

1..1

State Chart Diargram

+Name

+ID

+Perspectives



Conversation

participates in

1..*

specified by

1..1

Context

+Service-agent label

+Status

+Previous service instances

+Next service instances

+Regular actions

+Time

+Reasons of failure

+Corrective actions

Specifications

XML, RDF, CC/PP

Resource

+Label

+Capabilities

Context

+Master-service-agent label

+Number of instances allowed

+Number of instances running

+Next service instance availability

+Status

Context

+Master-service-agent label

+Previous web services

+Current web services

+Next web services

+Status

Context

+Services

+Calling operations



+Label

+Session name

+Topic

engages in

1..*

engages in

1..*

attached to

1..1

attached to

1..1

attached to

1..1

attached to

1..1



Context

+Label

+Date

Figure 5: Class model of agent-based deployment

ent agents of the system. Conversation sessions are

represented as XML documents.

5 RELATED WORK

There are several research initiatives in the ﬁeld of

Web services composition. Besides the traditional se-

lection criteria that are used for composition (e.g., ex-

ecution cost and time), we have shown that context

has a major effect on the Web services in general and

their composition in particular. For example, reaching

the maximum number of instances that can be created

from a Web service deﬁnitely delays the development

of a composite service. Furthermore, being aware of

when these instances will become available helps in

adjusting the execution of the composite service. We

have also shown that the context has been part of the

conversations that agents of the Web services engage.

In the service chart diagram of Fig. 1, the ﬂow per-

spective illustrates the pre- and post-component ser-

vices of a composite service. These component ser-

vices can be either optional or mandatory. These

types of service are similar to what Berﬁeld et al. call

in (Berﬁeld et al., 2002) by vital and nonvital services

for a workﬂow application. Another use of previous

and next services of the ﬂow perspective is related

to pre- and post-conditions. These conditions spec-

ify what must be true before a component service can

be executed, and what will be true as a result of the

component service execution.

The Web Services Conversation Lan-

guage (WSCL) is a sample of the initiatives on

conversations in the ﬁeld of Web services (Beringer

et al., 2001). This language describes the structures of

documents that a Web service expects to receive and

produce, as well as the order in which the interchange

of these documents is supposed to occur. While the

WSCL focuses on the speciﬁcation of the operations

that Web services support, our conversations focus on

the mechanisms of establishing composite services.

Finally, another use of conversations for Web ser-

vices enables us dealing with the composability issue

of Web services as Medjahed et al. discuss in (Med-

jahed et al., 2003). For instance, mapping opera-

tions of the information exchanged between Web ser-

vices may be required. Ensuring the composability of

Web services can be achieved through conversations.

Agents engage conversations for agreing on what to

exchange, how to exchange, when to exchange, and

what to expect from an exchange.

6 CONCLUSION AND FUTURE

WORK

In this paper, we presented our approach for com-

posing Web services using software agent and con-

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

220

text. Several types of agents have been considered

namely composite-service-agents for composite ser-

vices, master-service-agents for Web services, and

service-agents for Web service instances. The dif-

ferent agents have been aware of the context of their

respective services in the objective to devise com-

posite services on-the-ﬂy. To reach this objective,

three types of context have been used: I-context, W-

context, and C-context. Conversations between agents

have also featured the composition of Web services.

Before Web service instances are created, agents en-

gage conversations to decide if service instances can

be created and annexed to a composite service. Such

a decision is based on several factors among them the

maximum number of service instances that can be de-

ployed at the same time and the availability of these

instances for a certain period of time.

Our ongoing work is decomposed into several

thrusts. A security is one them as it is important to

make sure that services do not misuse the comput-

ing resources on which they will be performed. An-

other thrust consists of composite service adaptabil-

ity by allowing composite-service-agents to carry out

some run-time modiﬁcations by for instance adding

new component services, removing certain compo-

nent services, or replacing certain component ser-

vices. Therefore, the assessment of the effects of

adaptation is deemed appropriate. Another thrust con-

sists of reﬁning the update operations that occur be-

tween contexts. We already pointed out the support

of Tuple Spaces to such operations.

REFERENCES

Ahuja, S., Carriero, N., and Gelernter, D. (1986). Linda and

Friends. Computer, 19(8).

Benatallah, B., Sheng, Q. Z., and Dumas, M. (2003). The

Self-Serv Environment for Web Services Composi-

tion. IEEE Internet Computing, 7(1).

Berardi, D., Calvanese, D., De Giacomo, G., Lenzerini,

M., and Mecella, M. (2003). A Foundational Vi-

sion for e-Services. In Proceedings of The Work-

shop on Web Services, e-Business, and the Semantic

Web (WES’2003) held in conjunction with The 15th

Conference On Advanced Information Systems Engi-

neering (CAiSE’2003), Klagenfurt/Velden, Austria.

Berﬁeld, A., Chrysanthis, P. K., Tsamardinos, I., Pollack,

M. E., and Banerjee, S. (2002). A Scheme for Inte-

gration E-Services in Establishing Virtual Enterprises.

In Proceedings of The Twelfth International Workshop

on Research Issues in Data Engineering: Engineer-

ing e-Commerce/e-Business Systems (RIDE’02), San

Jose, USA.

Beringer, D., Kuno, H., and Lemon, M. (2001).

Using WSCL in a UDDI Registry 1.02.

http://www.uddi.org/pubs/wsclBPforUDDI

5 16 011.doc.

ezillon, P. (2003). Focusing on Context in Human-

Centered Computing. IEEE Intelligent Systems, 18(3).

Chakraborty, D. and Joshi, A. (2001). Dynamic Service

Composition: State-of-the-Art and Research Direc-

tions. Technical report, TR-CS-01-19, Department of

Computer Science and Electrical Engineering, Uni-

versity of Maryland, Baltimore County, Maryland,

USA.

Curbera, F., Khalaf, R., Mukhi, N., Tai, S., and Weer-

awarana, S. (2003). The Next Step in Web Services.

Communications of the ACM, 46(10).

Doulkeridis, C., Valavanis, E., and Vazirgiannis, M. (2003).

Towards a Context-Aware Service Directory. In Pro-

ceedings of The 4th Workshop on Technologies for

E-Services (TES’03) held in conjunction with The

29th International Conference on Very Large Data

Bases (VLDB’2003), Berlin, Germany.

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

mantics of Statecharts. ACM Transactions on Soft-

ware Engineering and Methodology, 5(4).

Jennings, N., Sycara, K., and Wooldridge, M. (1998). A

Roadmap of Agent Research and Development. Au-

tonomous Agents and Multi-Agent Systems, Kluwer

Academic Publishers, 1(1).

Kouadri Most

efaoui, S. (2003). Towards a Context-

Oriented Services Discovery and Composition Frame-

work. In Proceedings of AI Moves to IA: Work-

shop on Artiﬁcial Intelligence, Information Access,

and Mobile Computing held in conjonction with the

18th International Joint Conference on Artiﬁcial In-

telligence (IJCAI’2003), Acapulco, Mexico.

Ludwig, H., Keller, A., Dah, A., and King, R. (2002).

A Service Level Agreement Language for Dynamic

Electronic Services. In Proceedings of the 4th

IEEE International Workshop on Advanced Issues

of E-Commerce and Web-Based Information Sys-

tem (WECWIS’2002), Newport Beach, California,

USA.

Maamar, Z., Benatallah, B., and Mansoor, W. (2003). Ser-

vice Chart Diagrams - Description & Application. In

Proceedings of The Twelfth International World Wide

Web Conference (WWW’2003), Budapest, Hungary.

Maamar, Z. and Mansoor, W. (2003). Design and Develop-

ment of a Software Agent-based and Mobile Service-

oriented Environment. e-Service Journal, Indiana

University Press, 2(3).

Medjahed, B., Rezgui, A., Bouguettaya, A., and Ouzzani,

M. (2003). Infrastructure for E-Government Web Ser-

vices. IEEE Internet Computing, 7(1).

Roman, M. and Campbell, R. H. (2002). A User-

Centric, Resource-Aware, Context-Sensitive, Multi-

Device Application Framework for Ubiquitous Com-

puting Environments. Technical report, UIUCDCS-R-

2002-2282 UILU-ENG-2002-1728, Departement of

Computer Science, University of Illinois at Urbana-

Champaign, Urbana, IL, USA.

TOWARDS AN AGENT-BASED AND CONTEXT-ORIENTED APPROACH TO COMPOSE WEB SERVICES

221