A NOVEL APPROACH FOR ROBUST WEB SERVICES

PROVISIONING

Quan Z. Sheng

School of Computer Science, The University of Adelaide, Adelaide, SA 5005, Australia

Anne H. H. Ngu

Department of Computer Science, Texas State University, San Marcos, TX, USA

Keywords:

Web services, mobile agent, computing resource, matchmaking, resource planning.

Abstract:

Availability and reliability of Web services are important issues for developing many electronic business appli-

cations. Unfortunately, it is hard to guarantee the availability of a service given that the number of its requests

might be potentially huge. In this paper, we propose a novel approach for robust Web service provisioning

based on mobile agent and resource discovery technologies. With our approach, new service instance can be

instantiated at appropriate idle computing resources on demand, therefore reducing the risk of service being

unavailable. We present a matchmaking algorithm for resources selection, as well as a multi-phase resource

planning algorithm for composite Web services.

1 INTRODUCTION

Web services, and more in general Service-Oriented

Architectures (SOAs), are gathering considerable mo-

mentum as the technologies of choice to implement

distributed systems and perform application integra-

tion (Alonso et al., 2004). Recently, more and more

enterprises are encapsulating their applications as

Web services so that service consumers (either end

users or applications) are able to locate and invoke

those applications.

Some important issues for Web service provision-

ing that have deterred its wide adoption are respon-

siveness and robustness (Curbera et al., 2003; Ingham

et al., 2000; Keidl et al., 2003). It is costly for an en-

terprise if its services are down, for even a few min-

utes. Situations like service delay and unavailability

could be vital and are not acceptable for many im-

portant Web applications (e.g., mission-critical appli-

cations of companies). Unfortunately, given that the

number of requests of a Web service can potentially

be large, a single service host may not be sufﬁcient to

provide quick response time and high availability. It

is advantageous for a service to be initialized at multi-

ple hosts and for the invocation request of the service

to be always directed to the host with the lowest work-

load.

Code mobility is a powerful concept in general for

handling load balancing, performance optimization,

fault tolerance, and network disconnections (Fuggetta

et al., 1998). Code mobility can contribute signiﬁ-

cantly to prompt service responses in the sense that

heavily loaded or unavailable service hosts can be re-

placed dynamically by lightly loaded service hosts.

Many available mobile code technologies like Aglets,

Java, and Sumatra (Acharya et al., 1997) can provide

the foundation for the development of novel solutions

for robust Web services provisioning.

In this paper, we propose an approach for robust

Web services provisioning that builds upon our ear-

lier work in (Benatallah et al., 2003). The core part

of our design is a service container component called

service migrator. A service migrator, which is associ-

ated with a Web service, can instantiate a new copy of

the service at an idle computing resources on demand

or during runtime and therefore, reduces the risk of

the service being unavailable when the number of re-

quests to a speciﬁc service are becoming very large.

Furthermore, with load balancing, faster processing

of service requests can be achieved. To facilitate dy-

namic resource selection for migration, we introduce

a matchmaking algorithm for selecting computing re-

sources that meet the requirements of Web services.

To achieve optimized overall performance of a com-

121

Z. Sheng Q. and H. H. Ngu A. (2007).

A NOVEL APPROACH FOR ROBUST WEB SERVICES PROVISIONING.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - SAIC, pages 121-128

DOI: 10.5220/0002357901210128

 SciTePress

posite Web service, we also propose a multi-phase

resource planning approach where resources are se-

lected for the components of the composite service

based on a number of criteria such as communication

cost, or availability.

The paper is organized as follows. In Section 2,

we introduce our model for robust services provision-

ing, in particular the functionalities of service migra-

tors and their interactions with other components such

as service controllers, matchmaker, and computing re-

sources. Then, in Section 3, we present our algorithm

for resource matchmaking. In Section 4, we propose a

multi-phase resource planning algorithm for compos-

ite Web services. Finally, in Section 5, we discuss the

related work and outline future research directions.

2 THE MODEL FOR ROBUST

SERVICE PROVISIONING

In this section, we ﬁrst introduce the concept of mo-

bile Web services and followed by the description of

our model for robust services provisioning.

2.1 Mobile Web Services

We distinguish between stationary and mobile ser-

vices. Stationary services are location dependent.

Such a service cannot move because e.g., the ser-

vice needs to access a DBMS that is only available

on its dedicated server. Meanwhile, mobile Web ser-

vices are services with migration ability (Keidl et al.,

2003). They are similar to mobile agents which have

the ability to interact locally with a service or se-

lect a speciﬁc computing resource to use. In addi-

tion, mobile Web services can function just like sta-

tionary Web services. They can dynamically interact

with other services or clients (e.g., accepting invoca-

tion requests, form part of a composite service). Mo-

bile Web services are location independent. They are

stateless (i.e., the internal state of such a service is

discarded after a request is processed) and do not re-

quire special resources or permissions. A mobile Web

service can therefore be executed on arbitrary service

hosts whose capabilities satisfy the requirements of

the service.

Mobile Web services provide a number of distinct

features. Firstly, mobile Web services can migrate

to the client sites where services are invoked as local

calls. It is extremely useful when the data (input and

output of the services) are huge since the data do not

have to be streamed over on the network. Secondly,

mobile Web services can dynamically select a host to

migrate so that they can use the selected computing

resources to accomplish their tasks or to achieve load

balancing. Thirdly, mobile Web services have pro-

vided a solution to the robust service provisioning in

mobile computing environment in which limited re-

sources and unstable connections are a norm. Ser-

vices can always be migrated to more stable hosts.

Mobile Web services have recently attracted a

signiﬁcant interest (Chen and Petrie, 2003; Liu and

Lewis, 2005; Ishikawa et al., 2004; Keidl et al., 2003).

The work proposed in (Ishikawa et al., 2004) consid-

ers mobile Web services as synthesis of Web services

and mobile agents. While the work in (Liu and Lewis,

2005) develops an XML-based mobile code language

called X# and presents an approach for enabling Web

services containers to accept and run mobile codes. It

should be noted that proposing tools for the develop-

ment of mobile Web services is not the focus of our

work. Instead, we use the concept of mobile Web ser-

vices in our model as the basis for the robust services

provisioning.

2.2 System Design

Central to our design toward a robust provisioning

of Web services are a set of service hosts, a moni-

toring service, and a service container that consists

of two components, namely execution controller and

service migrator. A service host is a computing re-

source that is running an engine where service codes

can be executed. Service hosts can register them-

selves at a UDDI registry using appropriate tModel

(e.g.,

ServiceHost

) so that they can be found by ser-

vice requesters. A monitoring service monitors the

status of a computing resource or the server of a Web

service (e.g., CPU and memory usage). The execu-

tion controller interacts with the monitoring services

and coordinates the execution of the corresponding

Web service. If the value of a monitored item is

beyond a threshold —which can be set by the ser-

vice provider—and the service is mobile, the con-

troller sends a migration request to the service migra-

tor, which moves the execution of the service to an-

other service host. If no such a service host is avail-

able or the Web service cannot move, the controller

triggers an exception handling policy, if such a policy

has been speciﬁed by the service provider.

A service migrator is a light weight scheduler that

helps the controller to execute the associated mobile

Web service in other computing resources whenever

it is necessary. In particular, the service migrator is

responsible for:

In UDDI, a tModel provides a semantic classiﬁcation

of the functionality of a service or a resource, together with

a formal description of its interfaces.

ICEIS 2007 - International Conference on Enterprise Information Systems

122

Match

Maker

Service

Service Container

migrate

service

Mobile agent

Service host

Service Migrator

Computing resource

registration

Legend

Resource

Repository

Execution Controller

Monitoring service

Computing

Resources

Figure 1: Interactions of system components.

• Receiving service migration requests from the ex-

ecution controller and sending a matchmaking re-

quest to the matchmaker to ﬁnd an appropriate

computing resource. The matchmaking request

includes the relevant information (e.g., ability to

book airline tickets ) that will be used by the

matchmaker for the resource selection.

• Loading the service codes (of mobile Web ser-

vices) onto the computing resource recommended

by the matchmaker,

• Dispatching a mobile agent to the site of the re-

source for invoking the service. Upon completion

of the invocation, the results are carried back by

the mobile agent to the service migrator, which in

turn, notiﬁes the service controller about the com-

pletion of the invocation.

Figure 1 gives an overview of the interactions

among different components during the service mi-

gration. When a monitored item reaches a particular

threshold (e.g., the CPU usage of the server is higher

than 90%, see step 1), the controller of a service sends

a migration request to the service migrator (step 2).

The migrator interacts with the matchmaker for the

recommendation of an appropriate service host (steps

3 and 4). If such a service host exists, the migrator

loads the service code to the host and dispatches a mo-

bile agent for the service invocation and result collec-

tion (steps 5 and 6). Otherwise, the migrator informs

the controller, which then may trigger exception han-

dling policies (e.g., forward the service invocation to

an alternative Web service).

The selection of computing resources is based on

a matchmaking algorithm that is implemented in the

matchmaker. We will give a detailed description of

the resource matchmaking in Section 3.

The overall performance of a composite Web ser-

vice, which is an aggregation of several Web services

to fulﬁl a complex task (e.g., travel planning), can be

improved by code mobility (Casati and Shan, 2001).

For example, multiple component services in a com-

posite service could be gathered in a single site or sev-

eral sites in the same domain for the invocation to re-

duce the communication cost. In Section 4, we will

present an execution planning approach to optimally

select resources on which the execution of the com-

ponent services take place.

3 RESOURCE MATCHMAKING

The resource matchmaking consists of two main

steps: 1) service migrators and resource providers ad-

vertise their requirements and characteristics of the

Web services and resources; a designated matchmak-

ing service (i.e., matchmaker) matches the advertise-

ments in a manner that meets the requirements and

constraints speciﬁed in the respective advertisements.

The descriptions of Web services and resources

consist of two parts: attributes and constraints. The

attributes part includes characteristics of a service

(e.g., service location, mobility, input and output pa-

rameters) or a resource (e.g., CPU usage, free mem-

ory, price). While the constraints part includes con-

straint expressions deﬁned by a service or a resource

provider, indicating the requirements to select or al-

locate resources. For example, the provider of a re-

source may specify that the resource will not be of-

fered to any request from company A because e.g., it

always delays the payments. Similarly, the provider

of a (mobile) Web service may specify that only re-

sources with more than 200K bytes of free disk space

and at least 128K bytes of free memory are eligible to

invoke the service.

Resources can be described using W3C’s RDF

(Resource Description Framework)

, while Web ser-

vices can be described using WSDL (Web Service

Description Language)

. We will not give detailed

description of RDF and WSDL due to space limita-

tions. In the rest of this section, we will focus on the

introduction of our approach on resources matchmak-

ing and selection.

3.1 Matchmaking Process

Matchmaking is deﬁned as a process that requires

a service description as input and returns a set of

matched computing resources. A computing resource

is matched with a service if both the requirement ex-

pressions of the service and the constraints of the re-

source are evaluated to true.

http://www.w3.org/TR/REC-rdf-syntax.

http://www.w3.org/TR/wsdl.

A NOVEL APPROACH FOR ROBUST WEB SERVICES PROVISIONING

123

Figure 2: Interactions in the matchmaking process.

Matchmaking Interactions. Figure 2 shows the in-

teractions in a matchmaking process. Service mi-

grators and resource providers construct advertise-

ments describing their requirements and attributes

and send them to the matchmaker (step 1). The

matchmaker then invokes a matchmaking algorithm

by which matches are identiﬁed (step 2). The invo-

cation includes ﬁnding service-resource description

pairs that satisfy the constraints and requirements of

resources and services. We will describe this step in

more detail later. After the matching step, the match-

maker notiﬁes the service migrator and the resource

providers (step 3). The service migrator and the re-

source provider(s) then contact each other and estab-

lish a working relationship (step 4). It should be noted

that a matched resource of a service does not mean

that the resource is allocated to the service. Rather,

the matching is a mutual introduction between ser-

vices and resources and the real working relationship

can be consequently built after the successful initial

communication between the two partners.

The separation of matching and claiming has

some signiﬁcant advantages. The most important

beneﬁt from the separation is the resilience to changes

of resources and services. As we mentioned be-

fore, the state of Web services and resources may

be changing continuously in dynamic environments.

There is a possibility that the matches made by the

matchmaker are based on out-dated advertised infor-

mation. Claiming allows the provider of services and

resources to verify their requirements and constraints

in terms of their current states. In addition, a more

secure system has resulted from the separation in the

sense that in the claiming phase, the providers of re-

sources and services could verify their identities using

cryptographic techniques before building the working

relationship.

Expression Evaluation. Expression evaluation

plays an important role in the matchmaking process.

To evaluate a constraint expression in a advertisement

(service description), the attribute of the expression

is replaced with the value of the corresponding

attribute of the resource. If the corresponding

attribute does not exist in the resource advertisement,

the attribute of the expression is replaced with the

constant

undefined

. In our matchmaking algorithm,

expressions containing

undefined

are eventually

evaluated as false. The constraints of the resource

advertisement have the similar evaluation process.

For example, assume that a consultation booking

service needs at least 128K bytes free memory to run

the service (i.e.,

memoryfree

>=128K). The match-

maker scans the advertisement of the computing re-

source for the attribute

memoryfree

. The value of

the attribute (e.g., 512000K bytes) is used to replace

the attribute in the expression (i.e., 512000 >= 128),

which is in turn evaluated to true by the matchmaker.

When receiving a request from a service migrator,

the matchmaker takes the advertisement, evaluates all

the resources advertised in the resource repository us-

ing the matchmaking algorithm described above, and

returns a set of matched resources to the service mi-

grator. To express it more precisely, we present a

piece of pseudo code of the algorithm in Figure 3.

3.2 Resources Selection

For a speciﬁc service, there could be multiple comput-

ing resources matched for executing the service. The

service provider, therefore, should be able to choose

the best resource (or top N best resources) that satis-

ﬁes her particular needs from the matched resources.

To specify preferences over resources of a partic-

ular Web service, we exploit a multi-criteria utility

function,

U (r) =

∑

i∈S A

S core

(r)

where i) r is a resource, ii)

S core

(r) is an attribute

scoring function, iii)

S A is the set of selection at-

tributes, and iv) w

is the weight assigned to attribute

i. The scoring service computes the weighted sum

of criteria scores using the weight property of each

selection criterion. It selects the resource of a service

that produces the higher overall score according to the

multi-criteria utility function. Several criteria—such

as price, availability, reliability, and reputation—can

be used in the function.

By using multi-criteria selection function, the best

computing resource can be selected from the matched

resources, which will be contacted by the service mi-

grator for the consequent operations (e.g., migrate

service code and invoke the service at the resource).

ICEIS 2007 - International Conference on Enterprise Information Systems

124

doMatchMaking(serviceDescription){

SET matchedResources to empty

FOR every advertised resource in Repository DO {

matchR=matchRequirements(serviceRequirements,

resourceDescription)

matchC=matchConstraints(resourceConstraints,

serviceDescription)

IF (matchR and matchC)

addResource(matchedResources, resource)

}

RETURN matchedResources

}

matchRequirements(S R , R D ){

SET matchRequirements to false

FOR every requirement expression in S R DO {

IF evaluation(requirement)

SET matchRequirements to true

ELSE

SET matchReuirements to false

BREAK

}

RETURN matchRequirements

}

matchConstraints(R C , S D ){

SET matchConstraints to false

FOR every constraint expression in R C DO {

IF evaluation(constraint)

SET matchConstraints to true

ELSE

SET matchConstraints to false

BREAK

}

RETURN matchConstraints

}

Figure 3: Pseudocode for resource matchmaking.

A service migrator may also select a number of

matched resources (e.g., top N best resources) to

form a pool of service hosts for that service. If the

server where the service is currently running is heav-

ily loaded, the migrator generates a new instance of

the service (i.e., migrate a copy of the service and in-

voke it) on a service host with low workload in the

pool. Obviously, multiple service hosts of a service

can signiﬁcantly increase the service availability.

4 RESOURCE SELECTION FOR

COMPOSITE SERVICES

So far, we only consider the resource selection for an

individual service where the selection is determined

solely on the requirements of the service. Although

this approach is sound enough to improve the avail-

ability of the individual (component) service (e.g.,

move the service to a new resource for the invoca-

tion in case the current server is overloaded), the over-

all performance of a composite Web service may not

be optimized. For example, component services in

a composite service may choose various resources.

From a particular component service point of view,

the performance is the best. Whereas from the com-

posite service point of view, the performance might

not be the best because these component services

could all be put in a single service host or multiple

service hosts of the same domain where the commu-

nication cost can be dramatically reduced.

In this section, we ﬁrst introduce the concept of

execution plan and then present an approach for se-

lecting optimal execution plans for composite ser-

vices.

4.1 Execution Plans

As stated before, the components of a composite ser-

vice can be executed using several resources. There-

fore, there can be multiple execution plans for a com-

posite service. By execution plan, we mean those re-

sources which can be used to execute a composite

service. In other words, an execution plan indicates

which resource is used for each component of a com-

posite service.

Assume a composite service C S has m component

services,

C S

= {s

, s

, ··· , s

}, an execution plan p

C S is deﬁned as follows:

Deﬁnition 1 (Execution plan). p = {<s

, r

>, <s

>, · · ·, <s

, r

>} is an execution plan of compos-

ite service S if:

•

i=1

C S

, and

• for each 2-tuple <s

, r

> (i ∈[1,m]) in p, the ser-

vice s

is executed in resource r

. 

4.2 A Multi-phase Execution Planning

Building an optimal execution plan consists of several

phases. In the following, we will describe and illus-

trate the phases using an example.

Phase 1: Matching Resources. The purpose of this

phase is to search for the resources on which the com-

ponent services could be executed. It should be noted

that only those component services that are movable,

their codes can be transferred to other computing re-

sources, are involved in this stage

The matchmaker evaluates the requirement and

constraint expressions of the services and resources.

The component services that can not move (i.e., sta-

tionary services) have only one “matched” resource (i.e.,

their own service servers).

A NOVEL APPROACH FOR ROBUST WEB SERVICES PROVISIONING

125

If all the requirements of a component service s

are

evaluated to true using the attributes of a resource r

and all the constraint expressions of the resource r

are evaluated to true using the attributes of the ser-

vice s

, we say r

is a matched resource of s

. A ref-

erence to a non-existent attribute evaluates to the con-

stant

undefined

which is treated as false. Since there

could be multiple matched resources of a speciﬁc ser-

vice, for each component service s

of a composite

service

C S , the result of the matching phase of C S is

represented as:

M ={<s

, R

>, <s

>, ···, <s

>}, where

is the set of matched resources of

service s

∈

C S

, represented as

={r

, r

, ···, r

For example, imagine a composite service con-

sists of 8 component services (s

, s

, ···, s

) and the

matching results of the composite service are given in

Figure 4 (a). From the table we can see that resources

, r

and r

can be used to execute service s

. The

resource r

can also be used to execute service s

, s

, and s

. Figure 4 (b) gives the domain information

of these matched resources. For instance, resources

, r

, and r

belong to a domain named

K-17

Phase 2: Pruning Phase. For component services

which are supposed to run concurrently, if a resource

r is shared by several such services, a rematch proce-

dure must be performed to ensure that these compo-

nent services can be executed in r concurrently.

For example, suppose s

and s

are executed in

parallel and require at least 150K bytes and 120K

bytes of free memory to carry out their executions,

respectively. Also suppose that resource r

has 260K

bytes of free memory. Intuitively, r

meets the re-

quirements of both s

and s

separately. However, r

does not meet the requirements when s

and s

are ex-

ecuted at the same time because they need 270K bytes

of free memory totally. As a result, the resource r

removed from the sets of the matched resource of s

and s

Phase 3: Generating Execution Plan. Since each

component service s

∈

C S

) has a set of matched

resources (

), the association of a component service

with a speciﬁc resource must be completed in order to

build an execution plan for composite service

C S .

Initially, the work starts with the ﬁrst component

service s

(i=1) of the composite service

C S. In this

step, the best resource will be selected from

us-

ing the multi-attribute (e.g., price, availability) utility

function (see Section 3.2). End users can customize

the weights for the selection criteria in order to ﬁnd a

desired resource for the component service. For ex-

ample, if the price is the most important factor to a

customer, she can set its weight to 1. For each re-

source, a score is computed using the above utility

function and the resource with the maximal value is

selected. If there is more than one resource which

have the same maximal value, then a resource will be

chosen randomly from them. Suppose that resource

is ﬁnally selected to execute service s

, the plan for

executing service s

is represented as <s

, r

After the preparation of the ﬁrst component ser-

vice s

(i=1) is ﬁnished, the resources should be se-

lected for the remaining component services s

(i=2

. . . m). The location criterion is considered at this

stage. Obviously, the resource that is going to be as-

signed to a component service s

(i=2 . . . m) depends

on the location of the resource that is assigned to its

predecessor s

i−1

. In particular, if the resources

service s

contains the resource selected for s

i−1

(i.e.,

i−1

), the resource should also be selected for s

. Oth-

erwise, a number of resources

domain

that have the

same domain as r

i−1

are selected from

. The best

resource is selected from the

domain

by using the util-

ity function in Step 1. If there is no resource having

the same domain with r

i−1

, a resource will be selected

using the utility function by going to Step 1. For ex-

ample, suppose that r

is selected for s

, a resource

will be selected from r

and r

for s

because r

, and r

has the same domain (see Figure 4 (b)).

After the optimized execution plan of

C S is built,

when the composite service

C S is invoked, the migra-

tor of its component services are in charge of migrat-

ing and invoking the services in the assigned comput-

ing resources.

5 DISCUSSIONS

The work presented in this paper is related to robust

provisioning of Web services. Regarding the reliabil-

ity and availability of Web services, several proposals

have been presented in the literature (Casati and Shan,

2001; Keidl et al., 2003). The eFlow system (Casati

and Shan, 2001) provides a dynamic service selection

technique. With dynamic service selection, a com-

posite service searches for component services based

on available metadata, its own internal state, and a

rating function. In contrast, our work allows Web ser-

vices to be highly available by moving the execution

of services to other service hosts dynamically. The

dispatcher service that is capable of automatic service

replication presented in (Keidl et al., 2003) is most

similar to our work. However, the strategies on ser-

vice hosts selection have not been discussed. Instead,

a dispatcher is responsible for a set of service hosts

that are known a priori. In addition, their approach

only considers individual services, not composite ser-

vices. Comparing to their work, we not only present

ICEIS 2007 - International Conference on Enterprise Information Systems

126

Service Matched resources

, r

}

, r

}

, r

}

, r

}

, r

}

, r

}

, r

}

, r

}

(a)

K-17

J-10

C-8

(b)

Figure 4: (a) Matched resources of the composite service; (b) domains of the matched resources.

an approach for resources matchmaking where appro-

priate service hosts are selected dynamically, but also

present a multi-phase execution planning mechanism

for the high availability and best overall performance

of composite Web services. It is also worth mention-

ing that the Web Service Reliability (WS-Reliability)

speciﬁcation (Iwasa et. al., ) is an industry effort

for open, reliable Web services messaging including

guaranteed delivery, duplicate message elimination

and message ordering. However, although the spec-

iﬁcation was named as “Web service reliability”, it

deals less with the overall reliability of Web services

than with “Web services reliable message delivery”.

With regard to the matchmaking approaches, In-

foSleuth (Nodine et al., 2003) is an agent-based in-

formation discovery and retrieval system that adopts

broker agents to perform the syntactic and seman-

tic matchmaking. The broker agent matches agents

that require services with the agents that can provide

such services. In InfoSleuth, the service capabilities

is written in LDL++ (Chimenti et al., 1990), a logical

deduction language. RETSINA (Sycara et al., 1999)

is a multiagent system for dynamic service match-

making on the Web. The authors distinguished three

kinds of agents in Cyberspace: service provider, ser-

vice requester, and middle agent. An appropriate ser-

vice provider is matched to a requester through the

middle agent. A language is designed for the descrip-

tion of agents capabilities. In contrast, our matchmak-

ing between services and resources is based on an ap-

proach where providers of services and resources can

express their constraints and requirements. In addi-

tion, we propose a multi-criteria utility function for

selecting optimal resources for particular services.

The techniques presented in this paper have been

implemented in Self-Serv system (Sheng, 2006) as an

extension to Web services development. In particular,

UDDI is used as the service and resource repository.

We deﬁned an XML schema using RDF for resource

description. The HP Jena Toolkit 1.6.1

is used to ma-

http://jena.sourceforge.net/.

nipulate RDF documents. WSDL is used to specify

Web services. Since WSDL focuses on how to invoke

a Web service, some of the attributes (e.g., stationary

or mobile service) in our approach are not supported.

To overcome this limitation, such attributes are spec-

iﬁed as tModels. The keys of these tModels are in-

cluded into the

categoryBag

of the tModel of a Web

service. Finally, µCode 1.03

is used to implement

mobile agents for service invocation at service hosts

as well as results collection.

Our ongoing work includes the performance study

of the proposed techniques on service migration. We

are also planning to examine the support of dynamic

information of resources and services that changes

over the time such as amount of free memory.

REFERENCES

Acharya, A., Ranganathan, M., and Saltz, J. (1997). Suma-

tra: A Language for Resource-Aware Mobile Pro-

grams. Mobile Object Systems: Towards the Pro-

grammable Internet, pages 111–130.

Alonso, G., Casati, F., Kuno, H., and Machiraju, V. (2004).

Web Services Concepts, Architectures and Applica-

tions. Springer Verlag.

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

Self-Serv Environment for Web Services Composi-

tion. IEEE Internet Computing, 7(1):40–48.

Casati, F. and Shan, M.-C. (2001). Dynamic and Adap-

tive Composition of E-Services. Information Systems,

26(3):143–162.

Chen, Y.-F. R. and Petrie, C. (2003). Ubiquitous Mobile

Computing. IEEE Internet Computing, 7(2):16–17.

Chimenti, D., Gamboa, R., Krishnamurthy, R., Naqvi,

S. A., Tsur, S., and Zaniolo, C. (1990). The LDL Sys-

tem Prototype. IEEE Transactions on Software Engi-

neering, 2(1):76–90.

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):29–34.

http://mucode.sourceforge.net/.

A NOVEL APPROACH FOR ROBUST WEB SERVICES PROVISIONING

127

Fuggetta, A., Picco, G. P., and Vigna, G. (1998). Under-

standing Code Mobility. IEEE Transactions on Soft-

ware Engineering, 24(5):342–361.

Ingham, D. B., Shrivastava, S. K., and Panzieri, F. (2000).

Constructing Dependable Web Services. IEEE Inter-

net Computing, 4(1):25–33.

Ishikawa, F., Yoshioka, N., Tahara, Y., and Honiden, S.

(2004). Toward Synthesis of Web Services and Mo-

bile Agents. In Proc. of AAMAS’2004 Workshop

on Web Services and Agent-based Engineering (WS-

ABE2004), New York, USA.

Iwasa et. al., K. Web Service Reliability Speciﬁcation.

http://www.oasis-open.org/specs/index.php

Keidl, M., Seltzsam, S., and Kemper, A. (2003). Reliable

Web Service Execution and Deployment in Dynamic

Environments. In Proc. of the 4th VLDB Workshop on

Technologies for E-Services (VLDB-TES03), Berlin,

Germany.

Liu, P. and Lewis, M. J. (2005). Mobile Code Enabled Web

Services. In Proc. of IEEE International Conference

on Web Services (ICWS’05), Orlando FL, USA.

Nodine, M. H., Ngu, A. H. H., Cassandra, A. R., and

Bohrer, W. (2003). Scalable Semantic Broker-

ing over Dynamic Heterogeneous Data Sources in

InfoSleuth

. IEEE Transactions on Knowledge and

Data Engineering, 15(5):1082–1098.

Sheng, Q. Z. (2006). Composite Web Services Provisioning

in Dynamic Environments. PhD thesis, The University

of New South Wales, Sydney, NSW, Australia.

Sycara, K., Klusch, M., Widoff, S., and Lu, J. (1999). Dy-

namic Service Matchmaking Among Agents in Open

Information Environments. ACM SIGMOD Record,

28(1):47–53.

ICEIS 2007 - International Conference on Enterprise Information Systems

128