A three-level specification approach for an environment of software agents and Web services

Software Agents Research Group, College of Information Systems, Zayed University, Dubai, United Arab Emirates
Electronic Commerce Research and Applications (Impact Factor: 1.48). 09/2004; 3(3):214-231. DOI: 10.1016/j.elerap.2003.12.002
Source: DBLP
ABSTRACT
This paper presents an approach for the specification of a software agent-based and Web service-oriented environment. A software agent is an autonomous entity that acts on user’s behalf. Whereas a Web service is an accessible application that other applications and humans can discover and trigger. Users in collaboration with their agents compose Web services into high-level business processes denoted by composite services. The participation of Web services in a composite service is based on several selection criteria such as the execution cost of a Web service and the location of the resources on which a Web service will be performed. Prior to that selection, the specification approach puts forwards three levels: intrinsic, organizational/functional, and behavior. Besides the specification approach, the composition of Web services is illustrated in this paper with service chart diagrams.

Full-text

Available from: Zakaria Maamar
A three-level specification approach for an environment
of software agents and Web services
Zakaria Maamar
a,
*
, Quan Z. Sheng
b
, Boualem Benatallah
b
, Ghazi Al-Khatib
c
a
Software Agents Research Group, College of Information Systems, Zayed University, Dubai, United Arab Emirates
b
School of Computer Science and Engineering, The University of New South Wales, Sydney, Australia
c
Qatar College of Technology, Doha, Qatar
Received 22 April 2003; received in revised form 19 November 2003; accepted 3 December 2003
Available online 31 December 2003
Abstract
This paper presents an approach for the specification of a software agent-based and Web service-oriented envi-
ronment. A software agent is an autonomous entity that acts on userÕs behalf. Whereas a Web service is an accessible
application that other applications and humans can discover and trigger. Users in collaboration with their agents
compose Web services into high-level business processes denoted by composite services. The participation of Web
services in a composite service is based on several selection criteria such as the execution cost of a Web service and the
location of the resources on which a Web service will be performed. Prior to that selection, the specification approach
puts forwards three levels: intrinsic, organizational/functional, and behavior. Besides the specification approach, the
composition of Web services is illustrated in this paper with service chart diagrams.
2003 Elsevier B.V. All rights reserved.
Keywords: Web services; Software agents; Specification; Composition; Location
1. Introduction
Our long-term research objective is the de-
ployment of anytime, anywhere applications
through the design and development of environ-
ments for stationary and mobile users. To reach
this objective, we consider two major components
to constitute such environments: soft ware agents
and services. We decompose software agents into
two types [12]: stationary and mo bile. Further, we
decompose services into two types: Web services
[21] and Mobile services (M-services) [15].
With the rapid development of information
technologies, several businesses are deploying Web-
based applications for more automation, efficient
business processes, and global visibility. Web ser-
vices are among the technologies that help busi-
nesses in being more Web-oriented. A Web service
is an accessible application that other applications
and humans as well can discover and trigger [8].
*
Corresponding author. Tel.: +971-42082461; fax: +971-
42640854.
E-mail addresses: zakaria.maamar@zu.ac.ae (Z. Maamar),
qsheng@cse.unsw.edu.au (Q.Z. Sheng), boualem@cse.unsw.
edu.au (B. Benatallah), alkhatib@qu.edu.qa (G. Al-Khatib).
1567-4223/$ - see front matter 2003 Elsevier B.V. All rights reserved.
doi:10.1016/j.elerap.2003.12.002
Electronic Commerce Research and Applications 3 (2004) 214–231
www.elsevier.com/locate/ecra
Page 1
Various technologies are behind the success of Web
services including Web Services Description Lan-
guage (WSDL), Universal Descripti on, Discovery
and Integration (UDDI), and Simple Object Access
Protocol (SOAP) [9]. These technologies sup port
the definition of Web services, their advertisement,
and their binding for triggering purposes. Web
services have the capacity to be composed into high-
level business processes usually known as composite
services. For example, a vacation scenario calls for
the collaboration of at least four Web services:
flight reservation, hotel bookin g, attraction search,
and user notification. These Web services need to be
connected according to a certain flow of control .
Flight reservation is first completed, before hotel
booking and attraction search can be both initiated.
With the latest development in mobile and
wireless technologies, a new generation of Web
services are put forward on the market for the
benefit of persons who are usually on the move
(e.g., sales representatives). This kind of persons
rely on mobile devices such as cell-phones to con-
duct their day-to-day operations. M-services de-
note this type of Web services and are meant to be
either: (i) triggered remotely from mobile devices
for execution purposes, or (ii) wirelessly transferred
from provider sites to the mobile devices of users
on which their execution is carri ed out [15]. Any-
time, anywhere applications should support users
in satisfying their needs regardless of their location
and the type of devices (fixed or mobile) they use.
It is observed in [20,23] that composing multiple
services rather than accessing a single service is
essential. Searching for the relevant services, inte-
grating them into a composite servi ce, triggering
them, and monitoring their execution are among
the operations that users will be responsible. Most
of these operations are complex, although repeti-
tive with a large segment suitable to computer
assistance. Therefore, software agents are deemed
appropriate candidates to assist users in their op-
erations. For the needs of agentifying services, we
put forward two types of software agents; those
that act on behalf of users are called user-agents
and those that act on behalf of providers of ser-
vices are called provider-agents. Throughout this
paper, we argue that the integration of software
agents and services into the same environment
requires a specification approach that provides
assistance to designers. The specification is un-
dertaken at three levels: intrinsic, organizational/
functional, and behavior. Each level has a set of
properties that vary according to the component
(i.e., agent or service) to which the level is applied.
Agent: the intrinsic level has the properties that
identify an agent as an independent entity. The
organizational level has the properties that
identify an agent as an element of a community
of agents. Finally, the behavior level has the
properties that describe the react ions of an
agent to the interactions in which it participates.
Service: the intrinsic level has the properties
that identify a service as an independent entity.
The functional level has the properties that de-
scribe a service as a member of a composite ser-
vice. Finally, the behavior level has the
properties that describe the states of a service
when it is the subject of interactions between
agents.
In this paper, the following elements are dis-
cussed. What are the appropriate mechanisms for
specifying an environment of Web services? What
is the value-added of software agents to these
mechanisms? What are the selection criteria to in-
tegrate component services into composite ser-
vices? How to identify the resources on which the
component services will be performed? And finally,
how to validate the specification approach using
prototyping techniques? The remainder of this
paper is structured as follows. Section 2 overviews
some core concepts such as software agents and
service composition approaches. Section 3 presents
the three-level specification approach. Section 4
discusses the process of agentifying an environment
of Web services. Work in progress and related
work are respectively outlined in Sections 5 and 6.
Finally, Section 7 summarizes our contributions
and draws our conclusions.
2. Background
2.1. Software agents
A software agent is a piece of software that au-
tonomously acts to perform tasks on userÕs behalf
Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231 215
Page 2
[12]. Many software agents design is based on the
approach that the user only needs to specify a
high-level goal instead of issuing explicit instruc-
tions, leaving the how and when decisions to the
agent. A software agent has various features that
make it different from other traditional compo-
nents such as autonomy, goal-oriented, collabo-
rative, flexible, and mo bile.
2.2. Services
Regardless of its type (i.e., Web or mobile), a
service consists of operations to perform according
to a certain input and a certain chronology. Po-
tential users have to know how to request a service
for execution, but neither how to operate the ser-
vice nor how the service operates or is operated. In
this paper, C-service denotes a composite service,
whereas P-service denotes a primitive service that
is either a Web service or an M-service.
2.2.1. Web services
A Web service in [3] is an accessible application
that other applications and humans can discover
and trigger. Benatallah et al. associate three
properties with a Web service: (i) independent as
much as possible from specific platforms and
computing paradigms; (ii) developed particularly
for inter-organizational situations; and (iii) easily
composable, i.e., its composition with other Web
services does not require the development of
complex adapters.
2.2.2. M-services
Maamar and Mansour provide in [15] two
definitions for an M-service. The weak definition is
to remotely trigger a Web service from a mobile
device for execution. In that case, the Web service
acts as an M-service. The strong definition is to
transfer a Web service from its hosti ng site to a
mobile device where its processing takes place. In
that case, the Web service acts as an M-service that
is: (i) transportable through wireless networks; (ii)
composable with other M-services; (iii) adaptable
according to the computing features of mobile
devices; and (iv) runnable on mobile devices. In
this paper, we only consider the M-services that
comply with the weak definition.
Fig. 1 shows snapshots of a mobile service
running on a cell-phone. The service provides in-
formation to tourists visiting a city for instance
Dubai. Upon request of tourists, the service is
downloaded into their mobile devices.
2.2.3. C-service vs. P-service
A C-service aggregates multiple component P-
services. Since the M-services that we refer to in
this paper comply with the weak definition, the P-
services correspond only to Web services. Instead,
the C-services are made available to users for
triggering purposes in two different versions: Web
version for stationary users and M-version for
mobile users. As part of our work of specifying the
composition of services, we developed service chart
diagrams [14]. Details on these diagrams are given
below.
2.2.4. Service chart diagram
A service is expressed using a service chart di-
agram, which leverages the state chart diagram
1
of UML [11]. In a service chart diagram, the em-
phasize is on the context surrounding the execu-
tion of a service rather than only on the states that
a service takes (Fig. 2).
A service chart diagram wraps the states of a
service into four perspectives, besides the state
perspective that is in fact the state chart diagram of
the service. The flow perspective corresponds to the
execution chronology of a composite service (pre-
vious services/next services attributes M/O re-
spectively stands for Mandatory and Optional).
The business perspective identifies the organiza-
tions that are ready to provide a servi ce (business
attribute). The information perspective identifies
the data that are exchanged between services (data
from previous services/data for next services attri-
butes). Because of the type of services (i.e., man-
datory and optional), the information perspective
is tightly coupled to the flow perspective with re-
1
A state chart diagram is a graphical representation of a state
machine that visualizes how and under what circumstances a
modelled element (e.g., a class, a system, or a business process)
changes its states. Furthermore, a state chart diagram is used
for showing which actions are executed as a result of event
occurrence.
216 Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231
Page 3
gard to mandat ory data vs. optional data. Finally,
the performance perspective illustrates the ways a
service is invoked for execution whether remotely
or locally (performance type attribute, Fi g. 3, [13]
for more details on a serviceÕs invocation types).
2.3. Approaches of service composition
A composite service consists of component ser-
vices that are eithe r primitive or composite. We
outline below the approaches of service composi-
tion [5].
2.3.1. Proactive composition vs. reactive composi-
tion
Proactive composition is an off-line process
that gathers in advance the available component
Agent
2
Host
2
Service
Remote
invocation
Host
1
Host
2
Migration
Agent
1
Agent
1
Local
invocation
Service Invocation
(a) (b)
Agent
1
Host
1
Agent
2
Service
Fig. 3. Service invocation types: remote vs. local.
Fig. 1. Snapshots of tourist mobile-book.
Data from
previous services
Data to
next services
Perfor. type
(local
or remote)
2
3
Previous
services (M/O)
Next
services (M/O)
Business1
Service
Layers
in
State
1
State
2
B
State
j
E
State
3
out
Fig. 2. Service chart diagram.
Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231 217
Page 4
services to constitute a composite service. This
means that the composite services are pre-com-
piled and ready to be executed upon usersÕ re-
quests. In a proactive composition, the component
services are usually stable and may even be run-
ning on resource-ri ch platforms. With regard to
reactive composition, it is the process of creating
composite services on-the-fly. A composite service
is devised on a request-basis from users. Because
of the on-the-fly property, a component manager
that ensures the identifi cation and coordination of
the component services is required. Despite a
‘‘certain’’ complexity of reactive composition, it
presents several advantag es such as the awareness
of the current status of the component services and
the possibility of optimizing certain runtime ar-
guments such as bandwidth use and data transfer
routes.
2.3.2. Mandatory composite service vs. optional
composite service
A mandatory composite service illustrates the
compulsory participation of all the component
services to the execution process. Because it is ex-
pected that the component services will be spread
across the network, the reliability of the execution
process of each component service affects the re-
liability of the whole composite service. On the
other hand, an optional composite service does not
necessarily requ ire the participation of all the
component services. Certain component services
can be skipped during the execution for various
reasons such as possibility of replacement or
non-availability.
We recall that a composite service consists of
several component services. Therefore, the process
model underlying a composite service is specified
as a state chart diagram whose: (i) states are as-
sociated with the service chart diagrams of the
component services, and (ii) transitions are la-
belled with events, conditions, and variable as-
signment operations. Fig. 4 illustrates the state
chart diagram of a composite service that inte-
grates the service chart diagrams of its component
services.
3. The three levels of the specification approach
3.1. Motivation
To satisfy usersÕ and businessesÕ needs, multiple
advanced components are put forward to devise
new types of applications. Moreover, the diffusion
of mobile telecommunications and mobile access
to the Web has widened the heterogeneity of client
devices. Devices span from traditional worksta-
tions and PCs, to laptops, personal digital assis-
tants and smart phones, with wired/wireless
continuous/intermittent connectivity.
With the latest progress in information tech-
nologies, needs of users are getting diverse and
complex. To satisfy these needs, advanced com-
ponents are required for developing a new type of
applications. In our work, we decided using soft-
ware agents and services. Agents are autonomous
entities that take initiatives in solving problems.
Whereas services are computing packages that are
intended to be composed and executed. The com-
position of services into high-level business pro-
cesses is complex. Indeed, this requires searching
for the relevant services, integrating them into a
composite service, triggering the services at the
right time and in the right order, and monitoring
the execution progress of the composite service for
exception handling. All these operations can be
outsourced to software agents. They have the ca-
pacities to handle them such as autonomy, mo-
bility, and collaboration. Putting services and
agents in the same environment indicates the im-
portance of having a specification approach
that we apply in two steps. In the first step, the
and
Service
1
Service chart
diagram
1
Service
2
Service chart
diagram
2
Service
3
Service chart
diagram
3
Fig. 4. State chart diagram of a composite service.
218 Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231
Page 5
specification approach is applied to agents and
services taken independently from each other.
Whereas in the second step, the specification ap-
proach is applied to agents and services taken in a
combined way.
3.2. Levels of the approach
The three levels of the specification approach
are as follows: intrinsic, organizational/functional,
and behavior. In what follows, the properties of
each level are described and afterwards illustrated
with examples.
3.2.1. Software agent
Table 1 summarizes the properties of the spec-
ification approach when applied to software
agents.
The intrinsic level consists of three properties:
identifier (identifies an agent with regard to a
certain Internet domain), role (lists the respon-
sibilities of an agent), and type (indicates if an
agent is of type provider or user).
The organizational level consists of two proper-
ties: visited domain, and not-visited domain.
When a service is locally triggered, this means
that the requesting agent is visiting the domain
of the requested agent of the service. The infor-
mation on that domain updates visited-domain
property. The opposite happens if a service is
remotely requested; not-visited-domain prop-
erty is updated.
The behavior level consists of one property:
state chart diagram (lists the states that an
agent takes when it interacts with its peers).
3.2.2. Service
Table 2 summarizes the properties of the spec-
ification approach when applied to services.
The intrinsic level consists of seven properties:
identifier (identifies a service with regard to all
the services offered to users), description (pro-
vides an overview of a service), type (indicates
if a service is of type composite or primitive), in-
put arguments (lists the number and type of ar-
guments that are submitted when a service is
triggered), output arguments (lists the number
and type of arguments that a service returns af-
ter processing), and cost (corresponds to the
charges of executing a service).
The functional level consis ts of the three proper-
ties: component link (only applie s to composite
services and identifies the component primi-
tive-services), mandatory causal link (identifies
the primitive services that are attached to a
primitive service; these primitive services have
to be added to the composite service in case
the primitive service participates in this compos-
ite service), and optional causal link (identifies
the primitive services that are attached to a
primitive service; these primitive services can
be added to the composite service in case the
component service participates in this composite
service.
2
The behavior level co nsists of one property:
state chart diagram (describes the states that a
service takes when the service is the subject of
conversation between agents).
3.2.3. Connection between agents and services
The connection occurs at the three levels
namely intrinsic, organizational/functional, and
behavior.
Table 2
Properties of the specification approach applied to services
Level Properties
Intrinsic Identifier, description, type, input
arguments, output arguments, cost
Functional Component link, mandatory causal
link, optional causal link
Behavior State chart diagram
Table 1
Properties of the specification approach applied to software
agents
Level Properties
Intrinsic Identifier, role, type
Organizational Visited domain, not-visited domain
Behavior State chart diagram
2
A person attending a conference in city X could be
interested in visiting the famous places of that city even if the
person did not explicitly mention his interest.
Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231 219
Page 6
Intrinsic level: An agent of type provider has to
know the services it offers. Thus, service prop-
erty, which refers to these services, is added to
the intrinsic level of the agent.
Organizational–functional level: To satisfy his
needs, a user triggers a composite service to be
assigned to an agent of type user. This agent
knows the primitive services of the composite
service using component link, mandatory causal
link, and optional causal link properties of the
functional level of the service. The agent has
to select the primitive services needed acco rding
to execution cost property. In addition, the
agent ha s two options to trigger a primitive ser-
vice: (i) locally within the same domain of the
primitive service, or (ii) remotely from a differ-
ent domain of the primitive service. The type
of invocation enables updating visited domain
and not-visited domain properties of the orga-
nizational level of the agent.
Behavior level: When agents initiate conversa-
tions with their peers, they take different states
based on the mess ages these agents submit and
receive. It may occur that within certain states,
the agents perform operations that initiate ser-
vices. Thus, services take appropriate states.
3.3. Application of the three levels
After presenting the three-level specification
approach, the current step consists of applying the
approach to vacation scenario. Four services are
required to handle this scenario. At present, the
focus is on the specification of each service. The
specification of agents happens once the agentifi-
cation of services is completed (Section 4).
The application of the specification approach to
vacation scenario occurs as follows (Fig. 5):
A designer devises a C-service to be denoted by
vacation C-service. The specification approach
assists the designer in his work.
The P-services that co nstitute vacation C-ser-
vice are: flight reservation, hotel booking,
attraction search, and user notification. These
P-services are listed in component link property
of the functional level of the service.
Based on mandatory causal link property of the
functional level of the service, driving time cal-
culation and car rental P-services have to be
added to vacation C-service (Fig. 5(a) ). The first
P-service checks the distance between the loca-
tion of the hotel and the locat ion of the main
attraction. If the distance is greater to a user-
defined limit, car rental P-service is triggered.
Based on optional causal link property of the
functional level of the service, historic details
P-service can be added to vacation C-service
(Fig. 5(b)). This P-service provides historic in-
formation on the city the user plans visiting.
This new P-service is triggered upon the userÕs
approval.
The application of service chart diagrams to
vacation C-service occurs as follows. For the sake
of space, only two primitive services are presented.
Flight reservation P-service (Fig. 6(a)): it is the
first P-service of vacation C-service to be trig-
gered. It is followed by hotel booking and at-
traction search P-services. These P-services
need for their processing departure date, return
date, and city of destination to be obtained
from flight reservation P-service. This latter P-
service takes stand by and execution states.
Flight
reservation
Driving time
calculation
Hotel
booking
Attraction
searching
Car
rental
User
notification
(a)
(a)
Historic
details
(b)
and xor
(1)
(1): /user's
approval
Mandatory
services
Optional
services
Basic
services
Fig. 5. Vacation composite-service.
220 Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231
Page 7
The businesses that will provide flight reserva-
tion P-service (?business attribute) and the invo-
cation way of flight reservation P-service
(?performance type attribute) are identified dur-
ing run-time.
Driving time calculation P-service (Fig. 6(b)): it
has been added to vacation C-service according
to causal link property of the functional level of
the service. Hotel booking and attraction search
P-services precede the execution of driving time
calculation P-service. In addition, this P-service
is followed either by car rental P-service or user
notification P-service. The decision is made
based on the distance that exists between the lo-
cation of the hotel and the location of the at-
traction. According to the distance, driving
time calculation P-service triggers the relevant
P-service. Car rental P-service needs the name
of the person for whom the lease of the car will
be made. User notification P-service needs the
hotel and attraction names so the user can be
informed about all these details. The businesses
that will provide driving time calculation P-ser-
vice (?business attribute) and the invocation
way of driving time calculation P-service (?per-
formance type attribute) are identified during
run-time.
4. Agentification of an environment of Web services
4.1. Architecture
For the agentification needs of an environment
of Web services, we deployed an agent-based multi-
domain architecture (Fig. 7). Domains are spread
across the network and administrators maintain
them. Two types of domain exist: user-domain and
provider-domain. We assume the existence of one
user-domain (despite the issue of bottleneck or a
single poin t-of-failure that both could be handled
with replication) and several pr ovider-domains.
Domains are computing platforms on which ser-
vices and agents can run. Users browse the list of
composite services from different devices whether
fixed or mobile.
The user-domain has a service-zone and a
working-zone. The service-zone has a list from
which composite services are managed using the
three-level specification approach. This list offers
composite Web services to users of fixed devices
and composite M-services to users of mobile de-
vices. The service-zone of the user-domain has a
bank from which user-agents are created. For their
installation, user-agents are located in the work-
ing-zone of the user-domain. User-agents can mi-
grate from one domain to another based on the
strategy of invoking services. For each composite
service that a user selects, a user-agent is associ-
ated with. We recall that only primitive Web ser-
vices participate in composite services.
A provider-domain consists of a working-zone
and several lists of primitive services. Each list is
reserved to a specific category such as finance,
education, and travel. The working-zones are de-
vised in a way to receive user-agents arriving from
the user-domain or from other provider-domains.
Within provider-domains, installation and control
procedures of user-agents are performed (these
procedures do not fall within this paperÕs scope).
Provider-agents handle the invocation requests
that user-agents submit to the primitive services. A
Null
Destination city
Departure date
Return date
?Performance
type
Null
Hotel booking
and
Attra. searching
?Business
(a) Flight reservation P-service
Stand by Execution
BE
Hotel location
and
Attra. location
Person name
xor
Hotel name
Attraction name
(b) Driving time calculation P-service
?Performance
type
Hotel booking
and
Attra. searching
?Business
Stand by Execution
BE
Car rental
xor
User notification
Fig. 6. Application of service chart diagram.
Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231 221
Page 8
user-agent submits a local requ est to a provider-
agent in case both agents are in the same provider-
domain. In case the user-agent and provider-agent
are in separate domains, the user-agent submits a
remote request to the provider-agent so , the
primitive service can be triggered.
4.2. Operation
The operation of the multi-domain architecture
consists of the specification of the composite ser-
vices and their deployment once users initiate
them. The specification of a composite service is
discussed in Section 3.3. This means that the
communities of component primitive-services of a
composite service are already known (details on
service communities are provided in [3]). Now, the
focus is on deploying the composite service in
terms of: (i) selecting the component services as
providers can have services in common, and (ii)
executing the component services selected as ser-
vices can be remotely or locally invoked. Users
browse the list of composite services from their
fixed or mobile devices. The deployment of a
composite service is not affected by the type of the
device from which it is triggered. The only differ-
ence occurs at the communication protocol (HTTP
vs. WAP) that connects users to the user-domain.
When a composite service is selected, the user
indicates his needs (e.g., city of destination, num-
ber of persons). This leads into the creation of a
user-agent to handle the satisfaction of the userÕs
request. Initially, the user-agent is in the working
zone of the user-domain. Then, the user-agent
starts identifying the component primitive-services
of the composite service. The user-agent relies on
component link property of the functional level
(Table 2). At this stage, the user-agent knows the
appropriate component primitive-services. Before
it interacts with the respective provider-agents of
these primitive services, the user-agent checks if
additional primitive services are not also required.
User-domain
Working-zone
List of
C-services
Bank of
user-agents
Service-zone
Provider-domain
1
Working-zone
Provider-domain
2
Working-zone
Migration
Remote interaction
Migration
Remote
interaction
User-agents
List
21
of P-services
List
11
of P-services
List
12
of P-services
Administrator
Provider-domain
3
Provider-domain
4
Provider-agent User-agent Network P: Primitive C: Composite
Administrator Administrator
Users
WA P
HTTP
Local
interaction
Fig. 7. Software agent-based multi-domain architecture.
222 Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231
Page 9
To this purpose, it checks mandatory causal link
and optional causal link properties (Table 2). The
primitive services that are identified in the man-
datory causal link property have to be attached to
the composite service. Regarding optional causal
link property, the user-agent may decide to pro-
vide additional details that were not mentioned in
the userÕs initial-request.
After the user-agent identifies the primitive
services that have to be and can be attached to a
composite service, it starts implementing the
composite service by interacting with their pro-
vider-agents. The user-agent either migrates to a
provider-domain in which it locally requests the
execution of a primitive service. Or, the user-agent
remotely requests the execution of a primitive
service from the domain (either a user-domain or a
different provider-domain) in which it currently
resides. Once all the primitive services are exe-
cuted, the user-agent returns details to the user.
For the primitive services that were included ac-
cording to optional causal link property, the user-
agent checks whether the user is interested in
getting extra information. The user may be in-
formed about the charges related to the new
primitive services.
4.3. Getting Web services ready
For a composite service, preparing the compo-
nent primitive-services for composition and exe-
cution relies on two selection criteria: execution
cost and location of computin g hosts (a computing
host corresponds to a provider-agent). Executi on
cost criterion is directly related to a primitive
service. Whereas the location of computing host
criterion aims at gathering in the same provider-
domain the maximum number of primitive services
for execution, privilegi ng local interactions over
remote interactions. This means redu cing: (i) the
number of remote interactions between domains,
(ii) the number of migrations of user-agents to
provider-domains, and (iii) the number of remote
data exchanges between domains.
The identification of the provider-domai ns and
their computing host is based on an Algorithm
that is given in Fig. 8. First, the domain of where a
service is currently being executed is considered
(set A in Fig. 8, line 03). By selecting this domain,
remote data exchanges between services are avoi-
ded. Next, the domain of where the user-agent
currently resides is considered (set B in Fig. 8, line
04). By selecting this domain, local invocations of
Fig. 8. Algorithm for selecting provider-agents.
Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231 223
Page 10
services as well as local data exchanges between
services are enabled. In case none of the afore-
mentioned cases happen, any domain is considered
(set C in Fig. 8, line 05).
4.3.1. Definitions
A user-agent expects to: (i) associate each
primitive service with a provider-agent and (ii)
define the strategy of invoking the primitive servi ce.
We assume a C-service CS of n P-services, CS ¼
fp:s
1
; p:s
2
; ...; p:s
n
g. The specification of CS cor-
responds to the set f< p:s
1
; pro:agt
1
; type >; <
p:s
2
; pro:agt
2
; type >; ...;< p:s
n
; pro:agt
n
; type >g
where
S
n
i¼1
p:s
i
¼ CS and for each < p :s
i
;
pro:agt
i
; type >
ði1;nÞ
the P-service p:s
i
is provided
by the provider-agent pro.agt
i
and invoked ac-
cording to remote or local type. The number of
provider-agents that contribute to the provisioning
of CS is not necessarily equal to the number of P-
services that are involved in a composite service.
Certain provider-agents may contribute with more
than one P-service (e.g., < p:s
1
; pro:agt
1
; type > and
< p:s
2
; pro:agt
1
; type >).
Given a P-service, its execution cost is decom-
posed into two parts:
Remote cost of a P-service includes: (i) the cost of
establishing a communication link between the
domain in which the user-agent is now located
and the provider-domain of the provider-agent
of the P-service, plus (ii) the cost of performing
the P-service, plus (iii) the cost of sending back
the results from the provider-domain of the pro-
vider-agent to the domain of the user-agent.
Local cost of a P-service includes: (i) the cost of
moving the user-agent from the domain in
which it now resides to the provider-domain
of the provider-agent of the P-service, plus (ii)
the cost of performing the P-service.
4.3.2. Preparation
The preparation of the primitive services for
composition is divided into two phases. Phase 1
consists of searching for the provider-agents that
have the P-services. Because provider-agents can
have P-services in common, Phase 2 consists of
selecting a particular provider-agent based on the
criteria of execution cost and location of comput-
ing hosts.
In Phase 1, the identification of the provider-
agents is based on the business perspective of the
service chart diagram (Fig. 2). For each P-serv ice
p:s
i
, potential provider-agents are identified. This is
similar to < p:s
i
; PRO:AGT
i
; type > where PRO:
AGT
i
¼fpro:agt
1
; ...; pro:agt
m
g is the list of pro-
vider-agents that have the P-service p:s
i
in com-
mon, for example < p:s
1
; PRO:AGT
1
; type >, where
PRO:AGT
1
¼fpro:agt
1
; pro:agt
2
; pro:agt
3
g.
In Phase 2, because provider-agents can have P-
services in common, the association of a P-service
with a specific provider-agent ha s to be completed.
In addition, because of the location criterion the P-
services are treated one at a time. The definition of
< p:s
i
; pro:agt
i
; type > is broken down into two
sub-phases.
In Phase 2.1, the P-service p:s
i ði¼1Þ
of CS is
considered. At this level, only the execution-cost
selection-criterion is considered (location criterion
does not hold). From each provider-agent of
PRO:AGT
i ði¼1Þ
that offers the P-service p: s
i ði¼1Þ
,
the user-agent receives the execution cost for re-
mote and local invocation types (Eq. (1)).
User-agent :
p:s
i ði¼1Þ
pro:agt
1
: ðremoteCostðp:s
1
i
Þ; localCostðp:s
1
i
ÞÞ
.
.
.
pro:agt
k
: ðremoteCostðp:s
k
i
Þ; localCostðp:s
k
i
ÞÞ
8
>
>
>
>
<
>
>
>
>
:
ð1Þ
For each offer that a provider-agent pro:agt
k
submits to the user-agent, the user-agent selects
the minimum cost between the two types of invo-
cation (minðremoteCostðp:s
k
i
Þ; localCostðp:s
k
i
ÞÞ).
Afterwards, the user-agent selects for the P-service
p:s
i ði¼1Þ
the minimum cost among all the offers of
the provider-agents. For example, the user-agent
sets < p:s
1
; pro:agt
2
; remote >: pro.agt
2
provides
p:s
1
and p:s
1
is remotely invoked. Because of the
remote invocation, the user-agent and pro :agt
2
will
definitely be in two different domains.
In Phase 2.2, the user-agent continues with the
remaining P-services p:s
i
; ði ¼ 2; ...; nÞ also one at
a time. Now, the two selection criteria are simul-
taneously considered. It should be noted that the
location criterion is privileged over the execution
224 Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231
Page 11
cost criterion due to the aforementioned benefits.
Considering the location criterion, the provider-
agent that is associated with a P-service p:s
i ði2;nÞ
depends on the provider-agent that has been se-
lected to offer the predecessor P-service p:s
i1
. The
user-agent proceeds according to the algorithm of
Fig. 8 (in the algori thm, < p:s
i1
; pro:agt
i1
;
localjremote > is assumed). When the user-agent
finishes working on a P-service p:s
i
, its provider-
agent and invocation strategy of that P-service are
known. The purpose of the algorithm is to gener-
ate a short list of provider-agents with whom the
user-agent will interact about their services. This
short list ranks the domains in which the provider-
agents and user-agen t reside (A, B, and C sets, lines
08–12).
4.3.3. Execution
When all the P-services of a C-service are
identified, the user-agent starts invoking these P-
services through their provider-agent. For illus-
tration, the following C-service is used CS ¼
f< p:s
1
; pro:agt
1
; local >; < p:s
2
; pro:agt
2
; local >;
< p:s
3
; pro:agt
3
; remote >g. Initially, the user-
agent is in the user-domain, pro.agt
1
and pro.agt
2
are both in provider-domain
1
, and pro.agt
3
is in
provider-domain
3
. Since p:s
1
is going to be locally
executed, the user-agent migrates from the user-
domain to provider-domain
1
. Once the execution
of p:s
1
is completed, the user-agent locally executes
p:s
2
. Because pro.agt
2
is within the same domain as
pro.agt
1
, this shows an implementation of the lo-
cation criterion. This also shows that the transfer
of data from p:s
1
to p:s
2
if both are interdependent
is locally done, which avoids dealing with net-
work-connection failures. Finally, from provider-
domain
1
the user-agent submits a remot e request
to pro.agt
3
so p:s
3
can be executed. The transfer of
data from p :s
2
to p:s
3
if both are interdependent is
remotely done, which means the importance of
being aware of network-connection failures.
5. Work in-progress
Several aspects are under development in the
agent-based multi-domain architecture of Fig. 7.
In this paper, we discuss three of them namely
interleaving Web services composition and execu-
tion, reliabil ity of composite services execution,
and prototype implementation.
5.1. Interleaving Web services composition and
execution
It is shown in Section 4.3 that the deployment
of a composite service is sequential and demands
from the user-agent: (i) to process all the provider-
agentsÕ offers about the primitive services, (ii) to
constitute the composite service, and finally (iii) to
execute the composite service. It would be more
appropriate if the compo sition and execution of
services could be interleaved [18]. The user-agent
has to delegate a part of its work (either compo-
sition or execution) to a third party. To this end, a
delegate-agent is concurrently created to the user-
agent deploymen t. While the user-agent is re-
motely interacting with provider-agents or visiting
domains of provider-agents, the delegate-agent is
preparing the component services for execution on
behalf of the user-agent, and submitting the details
on what the user-agent has to carry out. These
details concern the provider-agents of the compo-
nent services and the invocation types of these
component services. While the delegate-agent is
working on the P-service p:s
i
, the user-agent is
executing the P-service p:s
i1
. Therefore, the
delegate-agent is always one-step ahead of the
user-agent. User-agent and delegate-agent com-
municate in two ways: locally when both agents
are in the user-domain and remotely when the
delegate-agent is in the user-domain and the user-
agent is in one of the provider-domains visiting
their provider-agents.
Fig. 9 illustrates the way user-agent and dele-
gate-agent implement the interleaving of Web
services composition and exec ution. We assume
a C-service CS ¼f< p:s
1
; ?pro:agt; ?typ e >; < p:s
2
;
?pro:agt; ?type >g. First of all, the delegate-agent
starts working on p:s
1
for execution. Based on the
offers it receives from provider-agents, the dele-
gate-agent establishes for p:s
1
what follows: local
execution in provider-domain
1
of pro.agt
1
(< p:s
1
; pro:agt
1
; local >). Therefore, the delegate-
agent asks the user-agent to migrate to prov ider-
domain
1
. Before it moves, the user-agent resides in
Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231 225
Page 12
the user-domain. While the user-agent is getting
ready for migration, the delegate-agent starts the
preparation of p:s
2
. After performing all the nec-
essary operations, the delegate-ag ent establishes
for p:s
2
what follows: local execution in provider-
domain
2
of pro.agt
2
(< p:s
2
; pro:agt
2
; remote >).
The details on p :s
2
are transferred to the user-agent
that is now located in provider-domain
1
. After the
user-agent finishes the execution of p:s
1
, it moves
to provider-domain
2
to locally interact with
pro.agt
2
.
5.2. Reliability of composite services execution
The reliability of a Web service is defined as the
probability that a request submitted to a Web
service is correctly responded within the maximum
expended time frame [24]. This time frame is
mostly published as part of the Web service de-
scription. Reliability is a technical measure that
depends on hardware and/or software configura-
tion of Web services and on network connections
between requestors and service providers. The re-
liability value can be computed from historical
data about past invocations using for example the
number of times that a Web service has been
successfully delivered within the maximum ex-
pected time frame, with regard to the total number
of invocations.
Because reliability deals with service execution
failures, backup approaches are deemed appro-
priate. A Web service cannot be executed for
multiple reasons: network connection problems,
service disconnected for maintenance, service
overloaded, just to cite a few. In the following, we
present the way reliability is integrated into the
operation of the multi-domain architecture of
Fig. 7.
Interleaving Web services composition and
execution has called for two types of agents: us-
er-agent and delegate-agent. Initially, the dele-
gate-agent associ ates a Web service with a
provider-agent and submits that information to
the user-agent that must be running either in the
user-domain or in one of the multiple provider-
domains. The selected provider-agent is part of a
pool of potential provider-agents (PRO:AGT
i
)
that have a Web service in common. Before the
delegate-agent starts working on the next com-
ponent services, it stores the information about
the pool of provider-agents (for example the ‘‘x’’
best ranked provider-agents from sets A, B, and
C of PRO.AGT
i
, x <¼ðkPRO:AGT
i
k1Þ) for a
later use. If the user-agent faces any difficulties in
the execution of a service, it immediately contacts
the delegate-agent which is always located in the
user-domain. Because the delegate-agent is now
working on the preparation of the remaining
Provider-domain
2
Working-zone
Provider-domain
1
Working-zone
User-agentUser-agent
Provider-agent
1
(p.s
1
)Provider-agent
2
(p.s
2
)
(2)
Migration
User-domain
Delegate-agent User-agent
(1)
Interaction
(3) Interaction
(3')
details
submission
(4)
Migration
(5) Interaction
Fig. 9. Interleaving service composition and execution.
226 Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231
Page 13
component services, it stops its preparation work
and browses the stored pool of provider-agents
for the service in trouble. The objective is to
identify a new provider-agent,
3
inform the user-
agent about this provider-agent, and finally store
the newly updated pool of potenti al provider-
agents. Information on a pool of potential pro-
vider-agents are not deleted until the delegat e-
agent receives a notification message from the
user-agent that the execution of a service has
been successfully completed. During that confir-
mation exchange, the delegate-agent submits to
the user-agent the details on the next service to
execute.
5.3. Implementation of prototype
We overview the status of the prototype im-
plementation. The prototype architecture consists
of a service composition environment and a pool of
services and agents. All these components are being
implemented in Java, whereas services communi-
cate through XML documents.
5.3.1. Service composition environment
The service composition environment consists
of a set of integrated tools that allow service pro-
viders and users to create and execute services.
WSDL is used to specify Web services and UDDI
is used as a service repository. Since WSDL fo-
cuses on how to invoke a Web service, some of the
attributes proposed in our approach are not sup-
ported by WSDL (e.g., service domain). To over-
Fig. 10. Web services composition.
3
The delegate-agent may request new offers from the
provider-agents that are stored in the pool.
Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231 227
Page 14
come this limitation, such attributes are specified
as tModels. Each tModel represents the specifica-
tion of one attribute. The keys of these tModels
are included into the categoryBag of the tMo-
del of a Web service.
The service builder assists providers in defining
new services and editing existing ones as well. A
service de finition is edited through a visual inter-
face (Fig. 10), and translated into an XML docu-
ment for further processing. The service builder
offers an editor for describing a service chart dia-
gram of a component service participating in a
composite service (an extension of our previous
work in [19]). It also provides means to describe
the properties of states (e.g., state ID, state name,
component service operation) and transitions (e.g.,
ECA rules).
5.3.2. Pre-built agents
For any user (resp., service) wishing to partici-
pate in our platf orm, the user (resp., the adminis-
trator of the service) needs to download and install
a set of pre-built agents, namely user agent (resp.,
provider-agent). The functionalities of the provider
agents are realized by a class called serviceWrap-
per, whic h provides methods for receiving, pro-
cessing, generating and sending control-flow
notifications, service invocation, and service com-
pletion messages.
User agents are mobile agents implemented
using Aglet [1]. IBMÕs Aglets Softw are Develop-
ment Kit V2 is used for implementing Aglets. The
only infrastr ucture required to install and config-
ure these agents are Java, Tahiti (a tiny Aglet
server program) and an XML parser. The func-
tionalities of user agents are realized by a class
called userAgent . Upon the initialization of the
userAgent,adelegateAgent is created and in-
stalled in the user domain, which is responsible for:
(i) preparing the execution plan of each compo-
nent of a composite service; and (ii) submitting
details on the execution plan to userAgent.
The userAgent is a static Aglet. When a ser-
vice needs to be locally invoked, userAgent
creates a slave called userAgentSlave, and passes
the destination (e.g., service host) to the user-
AgentSlave. userAgentSlave is the labor
Aglet that actually goes to the service site. Upon
Fig. 11. Service execution using user agent.
228 Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231
Page 15
arrival at the service site, doJob method of the
userAgentSlave is called, which performs the
real work that we assign to the slave (i.e., invoke
the service). Depending on the invocation type
(i.e., locally or remotely) of next service, user-
AgentSlave either migrates to the site of the
service or sends a request message for invocation
needs. When all the component services are in-
voked, the userA gentSlave returns to the user-
domain, callBack method of the master Aglet
userAgent is activated. The results are passed
as an argument of the callBack method. The
userAgent Aglet then extracts and passes the
results to the user. Fig. 11 shows the screenshot for
service execution using user agent. The Aglet
viewer window displays and controls the Aglets.
When the button Dispatch is clicked, a slave
agent is created for the userAgent and migrates
to the destination for the execution of services. The
results are returned to the userAgent and dis-
played in the Aglet viewer window. The detailed
results can be obtained by simply clicking on the
result message (e.g., carRental in the figu re).
6. Related work
Several research projects have studied Web ser-
vices composition [2]. With the progress of wireless
technologies and handheld devices, mobile services
are attracting the attention of both academia and
industry [4,7,17]. As example, the MObile Team-
work Infrastructure for Organization Networking
(MOTION) addresses the mobile teamwork re-
quirements of organizations in their daily business
[10]. MOTION provides support to mobile team-
work such as locating distributed business docu-
ments and expertise through peer-to-peer searches,
advanced subscription and notification, commu-
nity building, and mobile information sharing and
access.
The importance of enhancing agents with mo-
bility mechanisms has been pointed out in [22].
Wang worked on a system that allows the dispatch
of multiple mobile agents in parallel when visiting
e-shops. The mobile agent approach is suitable for
deploying parallel processes over distributed
sites on the Internet. The tasks to undertake are
decomposed and encapsulated into multiple mo-
bile agents. In the framework that Wang suggests,
a mobile agent service provider is proposed as an
execution environment for mobile agents [22]. This
environment is similar to the working zone of the
multi-domain architecture where creation, instal-
lation, verification, and performance operations
are conducted.
Chakraborty et al. [6] have introduced a reac-
tive service composition architecture for pervasive
computing environments. The architecture con-
sists of five layers: network, service discovery,
service composition, service execution, and appli-
cation. W hile reviewing Chakraborty et al.Õs work,
we were interested in the service execution layer.
During the execution of services, this layer might
want to optimize the bandwidth required to
transfer data over the wireless links between ser-
vices and hence, execute the services in an order
that minimizes the bandwidth utilization. This
optimization approach is similar to the location
criterion that we introduced. With that criteri on,
we reduced the number of remote interactions
between domains, the number of migrations of the
user-agent to domains, and the number of data
transfer between domains.
Another relevant work to the location criterion
is presented in [16]. Because it will be challenging
to create services that can execute well on the large
variety of devices (problems of diversity and re-
source constraints), Messer et al. [16] suggest to
transparently offload portions of a service code
from resource-constrained devices to nearby serv-
ers. Code offloading requires partitioning strate-
gies. If two components interact frequently (e.g.,
because of many method invocations), then a
partitioning strategy should suggest placing these
components together on one machine; splitting
them ac ross the network could severely affect
performance. The aforementioned partitioning
strategy has similarities with the location of com-
puting hosts criterion. This criterion promotes the
use of local interactions between services as well as
between agents . In [16], the selection of the same
host may cause an overloading for that hos t. In
this paper, this situation is avoided for two main
reasons. First, the work is done at the level of
domains of computing hosts rather than at the
Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231 229
Page 16
level of computing hosts. Second, the location
criterion helps in finding domains (Fig. 8). When a
domain is considered, traditional selection crite-
rion (such as execution cost and execution time)
are applied to identify the best computing hosts
and thus, the best providers of services.
7. Conclusion
In this paper, we presented a specification ap-
proach for Web services composition and deploy-
ment. The app roach has been featured by the use
of different types of software agents and three
levels of specifica tion. The levels were denoted by
intrinsic, organizational/functional, and behavior,
and illustrated with a running scenario. Because of
the complexity of Web services composition and
deployment, it has been suggested to associate
users with software agents and associate compo-
nent services with service chart diagrams. A service
chart diagram represents a service from five per-
spectives: state, flow, business, information, and
performance.
In this paper, the composition and deployment
of Web services have been handled by a two-phase
process. The first phase has consisted of identify-
ing the provider s that offer the Web services that
participate in composite services. The second
phase has consisted of selecting specific providers
according to two criteria: execution co st, and lo-
cation of computing hosts. Location criterion has
been privileged over the first criterion, enabli ng for
instance to a void cross-network traffic.
Our ongoing work includes the assessment of
the performance and scalab ility of the proposed
agent-based multi-domain architecture. We also
plan to focus on interleaving Web services com-
position and execution. It was shown from the
basic example of Fig. 9 that interleaving presents
benefits when it comes to considering the context
in which Web services evolve.
Acknowledgements
The authors would like to thank the referees
for their valuable comments and suggestions of
improvements. The authors also acknowledge the
implementation work of Aysha Alsayed Alma-
rzouqi, Alex Yue-Fai Tang, Eileen Oi-Yan Mak,
and Nathan Wo ng. The third authorÕs work was in
part supported by an Australian Research Council
(ARC) Discovery grant #DP0211207.
References
[1] Aglet. http://www.trl.ibm.com/aglets/, Visited September
2003.
[2] B. Benatallah, F. Casati (Guest Editors), Special issue on
Web services, Distributed Parallel Databases 12 (2–3)
(2002).
[3] B. Benatallah, Q.Z. Sheng, M. Dumas, The self-serv
environment for web services composition, IEEE Internet
Computing 7 (1) (2003).
[4] G. Caire, N. Lhuillier, G. Rimassa, A communication
protocol for agents on handheld devices, in: Proceedings of
the First International Workshop on Ubiquitous Agents
on Embedded, Wearable, and Mobile Devices held in
conjunction with the First International Joint Conference
on Autonomous Agents and Multi-Agent Systems (AA-
MASÕ2002), Bologna, Italy, 2002.
[5] D. Chakraborty, A. Joshi, Dynamic service composition:
State-of-the-art and research directions, Technical report,
TR-CS-01-19, Department of Computer Science and Elec-
trical Engineering, University of Maryland, Baltimore
County, MD, USA, 2001.
[6] D. Chakraborty, F. Perich, A. Joshi, T. Finin, Y. Yesha, A
reactive service composition architecture for pervasive
computing environments, in: Proceedings of the Seventh
Personal Wireless Communcations Conference
(PCWÕ2002), Singapore, 2002.
[7] I. Chisalita, N. Shahmehri, Issues in image utilization with
mobile e-services, in: Proceedings of the 10th IEEE
International Workshops on Enabling Technologies: In-
frastructure for Collaborative Enterprises (WETICEÕ2001),
Cambridge, MA, USA, 2001.
[8] J.Y. Chung, K.J. Lin, R.G. Mathieu, Web services
computing: advancing software interoperability, IEEE
Computer 36 (10) (2003).
[9] F. Curbera, R. Khalaf, N. Mukhi, S. Tai, S. Weerawarana,
The next step in web services, Commun. ACM 46 (10)
(2003).
[10] P. Fenkam, E. Kirda, S. Dustdar, H. Gall, G. Reif,
Evaluation of a publish/subscribe system for collaborative
and mobile working, in: Proceedings of the 10th IEEE
International Workshops on Enabling Technologies: In-
frastructure for Collaborative Enterprises (WETICEÕ2002),
Pittsburgh, Pennsylvania, USA, 2002.
[11] D. Harel, A. Naamad, The STATEMATE semantics of
statecharts, ACM Trans. Software Eng. Methodol. 5 (4)
(1996).
230 Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231
Page 17
[12] N. Jennings, K. Sycara, M. Wooldridge, A roadmap of
agent research and development, Autonomous Agents
Multi-Agent Systems 1 (1) (1998).
[13] Z. Maamar, Moving code (Servlet Strategy) vs. inviting
code (Applet Strategy) which strategy to suggest to
software agents?, in: Proceedings of the Third International
Conference on Enterprise Information Systems
(ICEISÕ2001), Setubal, Portugal, 2001.
[14] Z. Maamar, B. Benatallah, W. Mansoor, Service chart
diagrams description and application, in: Proceedings of
the 12th International World Wide Web Conference
(WWWÕ2003), Budapest, Hungary, 2003.
[15] Z. Maamar, W. Mansoor, Design and development of a
software agent-based and mobile service-oriented environ-
ment, e-Service J. 2 (3) (2003).
[16] A. Messer, I. Greenberg, P. Bernadat, D. Milojicic, D.
Chen, T.J. Giuli, X. Gu, Towards a distributed platform
for resource-constrained devices, in: Proceedings of the
22nd IEEE International Conference on Distributed Com-
puting Systems (ICDCSÕ2002), Vienna, Austria, 2002.
[17] D. Milojicic, A. Messer, P. Bernadat, I. Greenberg, G. Fu,
O. Spinczyk, D. Beuche, W. Schroder-Preikschart, WÕs–
pervasive services infrastructure, Technical Report HPL-
2001-87, HHP Laboratories, Palo Alto, CA, USA, 2001.
[18] M. Paolucci, O. Shehory, K. Sycara, Interleaving Planning
and Execution in a Multiagent Team Planning Environment,
Technical report, CMU-RI-TR-00-01, The Robotics Insti-
tute, Carnegie Mellon University, Pittsburgh, USA, 2000.
[19] Q.Z. Sheng, B. Benatallah, M. Dumas, E. Mak, SELF-
SERV: a platform for rapid composition of web services in
a peer-to-peer environment, in: Proceedings of the 28th
Very Large DataBase Conference (VLDBÕ2002), Hong
Kong, China, 2002.
[20] M.P. Singh, The pragmatic web, IEEE Internet Comput. 6
(3) (2002).
[21] A. Tsalgatidou, T. Pilioura, An overview of standards and
related technology in web services, Distributed Parallel
Databases 12 (2–3) (2002) 135–162.
[22] Y. Wang, Dispatching multiple mobile agents in parallel
for visiting e-shops, in: Proccedings of the Third Interna-
tional Conference on Mobile Data Management
(MDMÕ2002), Singapore, 2002.
[23] J. Yang, M. Papazoglou, W.-J. van den Heuvel, Tackling
the challenges of service composition in e-marketplace, in:
Proceedings of the 12th International Workshop on
Research Issues on Data Engineering: Engineering E-
Commerce/E-Business Systems (RIDE-2ECÕ2002) in Con-
junction with ICDEÕ02, San Jose, USA, 2002.
[24] L. Zeng, B. Benatallah, M. Dumas, J. Kalagnanam, Q.Z.
Sheng, Quality driven Web service composition, in: Pro-
ceedings of the 12th International World Wide Web
Conference (WWWÕ2003), Budapest, Hungary, 2003.
Z. Maamar et al. / Electronic Commerce Research and Applications 3 (2004) 214–231 231
Page 18
  • Source
    • "SOA is a general framework for developing and deploying distributed applications in heterogeneous environments using web services technology (Verheecke et al., 2006). Web services and SOA research examines such issues as web service specification and description languages and standards, such as BP execution language BPEL (Kloppmann et al., 2004; van der Aalst and Bisgaard Lassen, 2008), web service discovery and selection (Maamar et al., 2004), web service performance monitoring (McGregor and Schiefer, 2004), and approaches to web service generation (Baghdadi, 2005). Web services can be used by different BPs and in varying combination; hence they allow for dynamically adjustable BP, providing a technological platform for organizational agility. "
    [Show abstract] [Hide abstract] ABSTRACT: Purpose – The paper aims to provide a comprehensive overview of business processes (BPs) literature by identifying and discussing key BP-related research themes and suggesting directions for future research. Design/methodology/approach – Latent semantic analysis was used to analyze the abstracts of academic articles related to BP. Over 2,700 articles that use the term “business process (BP)” in their title, abstract or keywords were identified through electronic journals database EBSCOHost and examined. Findings – The results clearly indicate growing interest in BP research during the past 20 years. The key research themes can be classified into core and associated BP research. Core BP research deals with four cornerstones of BP change: BP design, information technology, BP implementation, and ongoing BP management. The associated BP research lies on the intersection of BP and other research areas such as total quality management, supply chain management, e-commerce, etc. Research limitations/implications – There is a need to focus future research efforts on understanding the inter-relationships among the four identified cornerstones of BP change. There is also a need for more inter-disciplinary BP research and integration of BP-related organizational practices. Originality/value – The review offers a cross-disciplinary perspective on BP research. The proposed framework can be used to identify directions for future research and practice.
    Full-text · Article · Jul 2010 · Business Process Management Journal
  • Source
    • "In the same way, [2] proposed an approach to build policy rules knowledge, by using OWL, DAML-S, RuleML and RDF in Web service composition. Some studies have specialized in topics such as the availability and reliability enhancement of Web services compositions, or concentrated on the execution of Web services, such as availability [10], service selection [11], and even the verification of Web services [5]. From these studies, the research issues of Web service composition are summarized below: 1. "
    [Show abstract] [Hide abstract] ABSTRACT: Web services are being adopted, more and more, as a viable means of accessing Web-based applications, and can be viewed as a technology based on maximal decoupling (and thus maximal reusability), available over an existing economic infrastructure (the Internet). This powerful concept is gradually taking root, because of the convergence of business and government efforts in making the Web the choice for all types of activities. Web services are self-contained, self-describing, modular applications that can be published, located and invoked across the web, offering a Web-native XML based solution. Thus, Web services can tackle the challenge of heterogeneous sources, creating interoperability. Currently, services composition is basically created through a predefined workflow or business logic model. Using the UML state chart analysis tool, the abstract specification and context-oriented approach can be attended to, or it can be incorporated with ontology, in a semantic way. These studies have specialized in the availability and reliability enhancement of Web services compositions and have concentrated on the execution of Web services, focusing on availability, and service selection, and even the verification of Web services. However, a problem exists in the current distribution process of Web services compositions: the general analysis and selection of services can be overly complex and un-systemic. There is a need to manage composite Web services, based on these emerging technologies, but the research related to ranking candidate services and selection of optimization strategies is sparse. Nothing has yet been published, that considers the constraints of non-functional service properties. In this paper, a novel approach is proposed. This present an approach to Web services composition; then practical implementation is illustrated; a case study, composing Web services for a collaborative design project is illustrated finally.
    Preview · Article ·
  • [Show abstract] [Hide abstract] ABSTRACT: Tracking the execution of composite Web services to identify and adjust their specification according to the current features of the environment is a challenging issue. The concept of views, as a dynamic snapshot over this specification according to a given context, is proposed in this paper. A view is used as a support means for tracking the execution progress of composite Web services and deploying the corrective measures in case of non-compliance with users' requirements. Our contributions are a definition of what a view means in the context of Web services composition, an approach for specifying user context and its respective view, and mechanisms for extracting and visualizing views over specifications of composite services.
    No preview · Conference Paper · Dec 2005
Show more