composition of web services and qos aspects€¦ · usually e-commerce application may need access...
TRANSCRIPT
Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol
Betreuung: Yuri Babich
Lehrstuhl für Informatik IV, RWTH Aachen
Composition of Web Services and QoS aspects
Seminar: Data Communication and
Distributed Systems
WS 2003/2004
Pavel Fedosseev Matrikelnummer: 244627
2
This work is aimed to give an overview in the field of Web services technology (WSDL, UDDI,
SOAP) in correlation with QoS aspects. A review of standards and approaches used in Web
Services composition is presented. In particular, it outlines the methods of declarative composition
in dynamic and Peer-To-Peer environment using statecharts as well as advantages of semantic
composition using DAML-S markup language and approaches of invoking Web Services using
Mobile Agents. The global planning approach used to optimally select component services during
execution of a composite service is described. The approach is explicitly based on Quality-of-
Service (QoS) characteristics of services and extends the standard basis of Web services
technologies.
1. INTRODUCTION .............................................................................................................3
1.1. Web services ................................................................................................................................3
1.2. Web services life cycle.................................................................................................................3
1.3. Web services enabling technologies...........................................................................................4
1.4. Discovery model ..........................................................................................................................5
2. WEB SERVICES COMPOSITION...................................................................................6
2.1. Motivation....................................................................................................................................6
2.2. Modeling composite Web Service using Statecharts ...............................................................7
2.3. Composing Web Services ...........................................................................................................8 2.3.1. Existing standards of flow specification for Web Services ...................................................8
2.3.2. Semantic Web and DAML-S .................................................................................................9
2.3.3. Declarative composition in dynamic and peer-to-peer environment ...................................10
2.3.4. Invoking Web Services using Mobile Agents......................................................................11
3. GLOBAL SELECTION APPROACH.............................................................................13
3.1. Execution paths and plans........................................................................................................13
3.2. Quality Criteria of Web Services.............................................................................................14
3.3. Selecting an Optimal Execution Plan ......................................................................................15
3.5. Linear Programming solution..................................................................................................17
3.6. Implementation assessment......................................................................................................19
4. CONCLUSION...............................................................................................................21
REFERENCES ..................................................................................................................22
Abstract
Table of Content
3
The Internet allows us to get information in easier, faster and more integrative way. Internet-users
get access to various information recourses. Long since we are able to obtain information about
prices and assortments of goods, actions and offers in the real world.
The Internet is no more just a simple store of information. Until recently, the Internet dealt with the
creation of E-Business and E-Commerce systems, and it was associated with web sites and
storefronts. Nowadays it became a provider of different kind of services, such as travel booking,
shopping and even ordering of food to the dinner. Home users as well as business companies could
access a numerous set of services via Internet.
With growth of Internet, services become more complex and versatile. Usually, application that
handles customer’s request has to perform a number of independent and special actions. The
simplest example is taken from Internet-shopping: before committing an order, it is worth checking
the presence of the good on the vendor’s stock. Usually E-Commerce application may need access
to many different systems, including remotely located, managed by another entity and etc.
Sometimes it becomes evident to companies that valuable information is locked away in standalone
systems that were not designed to exchange information with other systems. An important challenge
in E-commerce applications is interaction among autonomous, heterogeneous, and distributed
components it consists of [5]. In this aspect the standalone E-Business and E-Commerce systems
become no more sufficient. Web services is positioning as a new middleware aimed to solve this
problems.
1.1. Web services
Web services is a technology, which allows applications to communicate with each other in a
platform- and programming language-independent manner. According to definition of [13]: “A Web
Service is a software interface that describes a collection of operations that can be accessed
through standardized XML messaging over the network”. Web services technology involves a
family of XML-based protocols that extensively use XML to describe an operation to execute or
data to exchange with another Web service. A group of Web Services interacting together forms a
particular Web service application in a Service-Oriented Architecture (SOA) [13].
XML is successfully applied in the area of describing data in platform-independent manner for
exchange across systems. On conceptual level, we can look at Web services as units of work, each
handling a specific functional task. Besides, with universally defined interfaces and well-designed
tasks, it also becomes easier to reuse these tasks and applications they represent.
Main advantages of Web services are [8]: (i) independent as much as possible from specific
platforms and computing paradigms; (ii) developed mainly for inter-organizational situations rather
than for intra-organizational situations; and (iii) easily composable (i.e., composition of Web
services does not require the development of complex adapters).
Therefore, it allows us to consider Web services as future unified middleware that can be used to
dynamic service-oriented composition of applications built on different platforms, such as CORBA,
J2EE, .NET and so on.
1.2. Web services life cycle
The life cycle of activities related to Web Services is illustrated in Figure 1.1. According to [15],
these activities could include:
• Wrapping native services ensures that a service can be invoked by other
applications/machines regardless of its underlying data model, message format and
interaction protocol.
1. Introduction
4
• Service advertisement and/or
discovery: generating service
descriptions and publishing these
descriptions in registries for
subsequent discovery.
• Assembling composite services: identifying services to realize a given
composition, specifying their
interactions at a high level of
abstraction, and deriving external
descriptions and service level
agreements for the resulting
composite services.
• Executing composite services: enacting composite service specifications with respect to
execution models satisfying certain practical constraints, e.g. execution price, efficiency,
availability and other QoS metrics.
• Monitoring services: supervising composite service executions (e.g., logging service
invocations, state changes, and message exchanges) in order to detect contract violations,
measure performance and predict exceptions.
• Evolving services: adapting composite services to accommodate organizational changes, to
take advantage of new technological opportunities or to take into account feedback from
monitoring.
1.3. Web services enabling technologies
Web services technology bases on a family of related protocols to describe, deliver and interact with
services. Figure 1.2. shows the ordering of the protocols related to Web services and Web services
composition.
“SOAP (Simple Object Access Protocol) is an
XML based protocol for information exchange
designed to allow communication in a
decentralized, distributed environment…” [12].
There are three general parts: (1) an envelope that
defines a framework for describing what is in a
message and how to process it, (2) a set of
encoding rules for expressing instances of
application-defined datatypes, and (3) a
convention for representing remote procedure
calls and responses. SOAP can potentially be
built on top of any transport layer, e.g., an HTTP-
based infrastructure [12].
“WSDL (Web Services Description Language) is an XML format for describing network services
based on a standard messaging layer like SOAP. A WSDL description defines services as
collections of operations or ports, accessible over network...” [3]. In WSDL, the abstract definition
of operations and messages is separated from their concrete realization and data format. This allows
the reuse of abstract definitions: messages, which are abstract descriptions of the data, and port
types, which are abstract collections of operations. The concrete protocol and data format
specifications for a particular port type correspond to reusable binding. A port is defined by
associating a network address with a reusable binding, and a collection of ports defines a service
[3].
Monitoring Services
Wrapping Native Services
Evolving Services
Assembling Composite Services
Executing Services
Service Advertisement
Discovery
Fig. 1.1. Composite Service Life Cycle
Fig. 1.2. Web services protocol stack [3]
Transport layer: HTTP, SMTP, IIOP, etc
XML messaging layer: SOAP
Service description layer: WSDL
Web services composition:
BPEL4WS, WSFL, etc Publication and discovery: UDDI
5
UDDI (Universal Description Discovery & Integration) is the definition of a set of services
supporting the description and discovery of the web services, businesses, organizations, other web
services providers and the technical interfaces which may be used to access those services. UDDI is
a so-called “yellow pages” for web services [3].
The WS-Transaction and WS-Coordination protocols are designed to handle distributed
transactions. The Business Process Execution Language for Web Services (BPEL4WS) defines
workflow operations and serves to dynamic composition of Web Services. It will be discussed in
more detailed way in the section 2.3.1.
WS-Security is a family of protocols that cover authentication, authorization, federated security,
secure communications, and delivery. WS-Policy is another group of protocols that define the
policy rules behind how and when Web services can interact with each other, while WS-Trust
defines how trust models work between different services [3].
Figure 1.3 shows the Web services usage scenario and interaction of enabling technologies.
1.4. Discovery model
The Web Services architecture is based on the interactions among three roles (Fig. 1.4.): service
provider, service registry and service requestor. The interactions involve the publish, find and bind
operations. Together, these roles and operations act upon the Web services artifacts: the Web
service software module and its description. In a typical scenario, a service provider hosts a
network-accessible software module (an implementation of a Web service). The service provider
defines a service description for the Web service and publishes it to a service requestor or service
registry (also known as Service Broker). The service requestor uses a find operation to retrieve the
service description locally or from the service registry and uses the service description to bind with
the service provider and invoke or interact with the Web service implementation. Service provider
and requestor roles are logical constructs and service can exhibit characteristics of both [4].
Remote Web Service
Repository
Remote Web service
Remote Web service
Remote Web service
Service Requestor
Individual Service
Invocation
Composite Service
Execution
Publish Web
Services
WS Lookup
Invoke WS
Compose Abstract Process
Composite Web Service Lookup
Execute
Search
Invoke
Compose
Execute
(SOAP)
(SOAP)
(SOAP)
(WSDL)
(UDDI)
(BPEL4WS)
Fig. 1.3. Web Services usage scenario.
Service Registry
(SOAP)
(SOAP)
6
Researches presented in [4] shows that
current Web services publish and discovery
model (Fig. 1.4) is largely unregulated based
on UDDI registries. 48% of the production
UDDI registry has links that are unusable
since they contain missing, broken or
inaccurate information. Besides, this model
cannot provide a full answer to questions of
reliability and performance characteristics of
Web Services.
The [4] proposes to extend classical
discovery model to handle this issues. The
advantage of such an approach is that it can
co-exist with current UDDI registries.
In the proposed model [4], a Web service
provider needs to supply information about
the company, the functional aspects of the
provided service as requested by the current
UDDI registry, as well as to supply quality
of service information related to the proposed Web service. The claimed quality of service needs to
be certified and registered in the repository.
The Web service provider first claims its QoS to the Web service QoS certifier. The certifier checks
the claims and either certifies or down grade the claim. The outcome is sent back to the provider
with certification identification information. This information is also registered in Web Service
Registry. After the certifier issues the QoS certification, the supplier registers with the UDDI
registry with both functional description of the service and its associated certified quality of service
information. The UDDI registry communicates with the certifier to check the existence of the
certification. After successful checking, the registry then registers the service in its repository.
Service requestor searches the UDDI registry for a Web service with the required functionality as
usual; they can also add constraints to the search operation. One type of constraint is the required
quality of service. If there were multiple Web services in the UDDI registry with similar
functionalities, then the quality of service requirement would enforce a finer search. The search
would return a Web service that offers the required functionality with the desired set of quality of
service [4].
2.1. Motivation
The development of new services through the integration of existing ones has been widely
investigated as means to create and modernize business-to-business collaborations.
The service-oriented architecture (SOA), where individual Web services are federated into
composite Web services whose business logic is expressed as a process model, is emerging as a
promising approach to integrate business applications inside and outside of organizational
boundaries [2]. The Web services paradigm could be successfully applied to solve platform
interoperability problems faced by system integrators. The flexibility of this new component type
facilitates service composition using existing Web services, promoting component re-use and
distributed execution [4].
2. Web services composition
Classical Discovery Model
Bind
Publish
Fig. 1.4. Web Services discovery models
Web Service Requestor
Web Service Provider
Web Service Registry
Web Service QoS Certifier
Find
Verify QoS Certify QoS
Extended Discovery Model
7
Despite that the current Web services technologies, such as WSDL, UDDI, SOAP, enable
developing of composite Web Services, discovering of Web Services and uniting them into
composite process is tangled and complex task. There are different approaches in Web Service
composition [2], [7], [8].
The standards are not yet defined, although the overwhelming majority of existing ways of Web
Services composition is based on workflow languages [16]. The most known techniques of
representing workflow processes is Petri nets and statecharts diagrams.
This paper will give a short overview of modeling composite Web Service using statecharts.
The number of services providing a given functionality may be large and constantly changing and
here another problem arises, namely effective service selection. Due to growth of Web services
domain, approaches where the development of composite services requires the identification at
design-time of the exact services to be composed are becoming insufficient. The run-time selection
approach has been put forward in recent researches [1].
Besides, as it was mentioned in [4], Web services technology suffers from inadequate level of
integration of Quality-of-Services (QoS) metrics.
The rest of the paper is organized as follows: the way of applying statecharts to modeling integrated
Web Service is presented in the following section. Section 2.3 outlines the popular methods for
Web Service selection, composition and execution. Quality model is presented in chapter 3 as the
primary part of global selection approach.
2.2. Modeling composite Web Service using Statecharts
The operations of a composite service could be easily expressed using statecharts. Encoding the
flow of operation invocations as statecharts have several advantages. First, statecharts possess a
formal semantics, which is essential for analyzing composite service specifications. Next,
statecharts are becoming a standard process modeling language as they have been integrated into
the Unified Modeling Language (UML). Finally, statecharts offer most of the control-flow
constructs found in existing workflow specification languages (branching, concurrent threads,
structured loops) [2].
The Petri net is alternative and very powerful technique to capture the semantics of complex service
combinations. In both cases visual representations provide a high-level language, which allows
expressing and reasoning about concepts at their natural level of abstraction. Since Web service
behavior is basically a partially ordered set of operations, it is possible to map it into a Petri net,
where operations are modeled by transitions; the state of the service is modeled by places; and the
arrows between places and transitions are used to specify causal relations [17].
However Petri net-based approach is quite complex. Statecharts won recognition due to
combination of high level of expressiveness with relative simplicity and clearness. That is the
reason because statecharts became more natural and widely used technique for Web Services
modeling.
A statechart is made up of states and transitions. When a transition fires, its action part is executed
and its target state is entered. The event, condition, and action parts of a transition are optional. A
transition without an event is said to be triggerless. States can be basic or compound. A basic state
corresponds to the execution of a service, whether elementary or composite. Accordingly, each
basic state is labeled with an invocation to a service operation. When the state is entered, this
invocation is performed. The state is normally exited through one of its triggerless transitions when
the execution induced by this invocation is completed. If the state has outgoing transitions labeled
with events, an occurrence of any of these events causes the state to be exited and the ongoing
execution to be cancelled [18].
8
Compound states contain one or several entire statecharts within them. Compound states come in
two flavors: OR and AND states. An OR-state contains a single statechart, while an AND-state
contains several statecharts (separated by dashed lines) that are intended to be executed
concurrently. Each of these statecharts is called a concurrent region. When a compound state is
entered, its initial state(s) become(s) active. The execution of a compound state is completed when
it reaches (all) the final state(s). Accordingly, OR-states are used as a decomposition mechanism for
modularity purposes [18].
A simplified statechart specifying a “Travel Designer" composite Web Service is depicted in Figure
2.1. A search for attractions is performed in parallel with a flight and an accommodation booking.
After these searching and booking operations are completed, the distance from the hotel to the
accommodation is computed, and either a car or a bike rental service is invoked. If two transitions
origin from the same state (in this case the state “Router Planner”), they denote a conditional
branching, and the transitions should therefore be labeled with disjoint conditions.
2.3. Composing Web Services
2.3.1. Existing standards of flow specification for Web Services
There exist many ways of workflow description languages that vary in realization and functionality.
As result, the abundance of overlapping standards for workflow modelling is overwhelming. That
creates problems for Web services as coupling technology [3]. Recently Microsoft’s XLANG,
IBM’s WSFL were merged into unite standard, which is called BPEL4WS.
The Business Process Execution Language for Web Services (BPEL4WS) is a language, used to
specify business processes and business interaction protocols. It is originated from XLANG and
WSFL as a standard for web services flow specification. The model and XML-based syntax defines
the interactions between process and its partners that occur using Web services interfaces. It also
defines the states and logic of coordination between these interactions as well as provides a way of
handling exceptions [16].
The business interaction protocols are called abstract processes. They are used to specify public and
visible message exchange between different parties involved in a business protocol and they do not
reveal the internal behavior or the implementation of the involved parties. The executable processes
on the other hand are like workflow descriptions represented using basic and structured activities
specifying a pattern of execution of web services. The process model defined by BPEL is based on
the WSDL based service description model [9].
Unfortunately, there are many more standards that have been proposed in recent years except
BPEL4WS, WSFL, and XLANG. Thus, Sun, BEA, SAP, and Intalio have introduced another
standard of web services composition: WSCI (Web Service Choreography Interface).
Attraction Searching
Flight Ticket Booking
Hotel Reservation
Router Planner
Bike Rental
Car Rental
Legend: State AND-State Transition Initial State Final State
Fig. 2.1. Statechart of a composite service „Travel Designer“
9
The Web Service Choreography Interface (WSCI) is a XML-based language for description of
message exchange carried by Web Services using collaborative business process or workflows. It
defines the flow of messages exchanged by a stateful Web service. It is used to describe a service in
a way that other Web Services can interact with it over the message exchange by specifying the
temporal and logical dependencies. Although it provides a message-oriented view of the process, it
does not define the internal behavior of the web service or the process. It is complementary to the
static interface details provided by the WSDL file. This is achieved by the dynamic interface
provided by WSCI through which the inter-relationship between different operations. The stateless
message exchange specification in a WSDL file is thus enlarged with message choreography and
stateful message exchange [9].
Intalio also initiated the Business Process Management Initiative (BPMI.org), which developed the
BPML (Business Process Markup Language) that describes an abstract model and grammar for
expressing business processes. Using BPML, it is possible to define enterprise processes and
complex web services. A process in BPML is a composition of activities that perform specific
functions. The process directs the execution of these operations. It can be defined as a part its parent
process or by invoking from another process. Each activity (simple and complex) in the process has
a context, which defines common behavior for all activities executing in that context. Hence a
process can be defined as a type of complex activity. The BPML specification defines 17 activity
types, and three process types. The different process types are nested processes which are defined to
execute within a specific context and whose definitions are a part of context's definition, exception
processes to handle exceptional conditions in executing parent's process and compensation
processes to provide compensation logic for their parent processes. Each process definition may
specify any of the three ways of instantiating a process: in response to an input message, in response
to a raised signal, or invoked from an activity or schedule. BPML specifications support importing
and referencing service definitions given in WSDL [9].
OASIS and UN/CEFACT support ebXML (Electronic Business using eXtensible Markup
Language). Part of ebXML is BPSS (Business Process Schema Specification), yet another standard
having a similar scope as BPEL4WS, WSFL, XLANG, WSCI, and BPML.
It is also clear that far not all standards will be adopted by the workflow vendors. The problem of
export from one format to another either exists.
As a result, the world is confronted with too many standards that are mainly driven by concrete
products and/or commercial interests. Many of developers prefer to ignore standardization
proposals that are using not well-established process modeling techniques [3].
2.3.2. Semantic Web and DAML-S
“The Semantic Web is a vision: the idea of having data on the web defined and linked in a way, that
it can be used by machines - not just for display purposes, but for using it in various
applications...” [11].
Web services is seen as basic technology for Semantic Web, e.g. creating software will be just a
matter of finding the right components on the Web and a specification document linking to these
components. The new software is again just a resource available on the Web.
The realization of this innovative idea is not easy, because present standards (WSDL, UDDI,
BPEL4WS) cannot provide technically the required functionality for semantic search of
components. According to [14], a description language for B2B e-commerce flow description
should satisfy the following requirements:
• descriptions with high level of exibility and expressiveness. The ability to express semi-
structured data, as advert description of Web Services and B2B iterations description, is
required;
• descriptions need to share a common semantics and be able to use common vocabularies;
• descriptions should easily lend themselves to performing the operations described in the
negotiation and matchmaking sections such as, matching of advertisements with queries;
10
validation of negotiation proposals; checking of two negotiation proposals to determine if an
agreement can be made;
• descriptions should express restrictions and constraints.
The special markup language DAML-S is being designed to capture these requirements. DAML-S
is an initiative to provide an ontology markup language expressive enough to semantically represent
capabilities and properties of Web services. DAML-S is based on DAML+OIL and the aim is to
discover, invoke, compose, and monitor Web services. In DAML-S, each service can be viewed as
a process and its Process Model is used to control the interactions with the service [9].
DAML-S beneficially gives the following advantages in comparison with existing standards [10]:
• Automatic Web service discovery. Involves the automatic location of Web services that
provide a particular service and that adhere to requested constraints. Such information necessary
for Web service discovery is specified as computer-interpretable semantic markup at the service
registry or ontology-enhanced search engine could be used to locate the services automatically.
• Automatic Web service invocation. Involves the automatic execution of an identified Web
service by a computer program or agent. Execution of a Web service can be thought of as a
collection of function calls. DAML-S markup of Web services provides a declarative, computer-
interpretable API for executing these function calls. Automatic Web service composition and
interoperation. Involves the automatic selection, composition, and interoperation of Web
services to perform some task, given a high-level description of an objective. Software can be
written to manipulate these descriptions, together with a specification of the objectives of the
task, to achieve the task automatically.
• Automatic Web service execution monitoring for addressing quality of service issues. It could
be applied to processing of execution logs and specifying the description by analyzing former
service’s runs.
The possibility of integration DAML-S into Web services domain and making a new standard from
it is reserved by the fact that it is designed complimentary with WSDL and SOAP.
2.3.3. Declarative composition in dynamic and peer-to-peer environment
Declarative composition in dynamic and peer-to-peer environment illustrates an idea of selecting
component services by the composite service execution engine based on a set of criteria. Since the
number of services providing a given functionality may be large and constantly changing, the [1]
introduces a notion of service community. Taking this into account, a basic state of a statechart
describing a composite service can be labeled with an invocation to either of the following:
• An elementary Web service, i.e., a service that does not transparently rely on other Web
services.
• A composite Web service that aggregates several other services.
• A Web service community, i.e., a collection of Web services with a common functionality
although different non-functional properties (e.g., with different providers, different QoS
parameters, reputation, etc.)
The concept of Web service community addresses the issue of composing a large and changing
collection of Web services. Service communities provide descriptions of a desired functionality
without referring to any actual service (e.g., Aeroflot flight booking Web service).
The [1] considers following problems in service composition.
• Fast composition: The need for fast composition and deployment of Web Services requires a
high-level declarative service composition language.
• Scalable composition: The number of services to be integrated may be large. Web Services are
volatiles. Web services may need to be composed as part of a short-term partnership, and then
disbanded when the partnership is not longer profitable. This form of partnership does not
assume any a priori defined relationships between services. Thus, the integration of a large
number of dynamic Web Services requires scalable and flexible techniques.
11
• Distributed execution: The execution of a composite service in existing techniques is usually
centralized, whereas the participating services are distributed and autonomous. Problems like
scalability, availability and security exist on centralized approaches. Peer-to-Peer techniques are
attractive for executing services.
The most existing techniques implements local selection strategy, meaning that they assign a
component service to an individual task one at a time [2],[19]. As a result, these approaches are not
able to handle global user constraints and preferences. In order to overcome these limitations the
new global planning approach is introduced. In this approach, quality constraints and preferences
are assigned to composite services rather than to individual tasks within a composite service.
Service selection is then formulated as an optimization problem and a linear programming method
is used to compute optimal service execution plans for composite services [1].
This approach doesn’t require any additional functionality and agree with Web services protocol
stack capacities. It allows extending the current model by enabling selection of Web Services
considering not only functional but also the quality characteristics of elementary Web Services. The
detailed description is given in the section 3.
2.3.4. Invoking Web Services using Mobile Agents
In Agent Based approaches the accent is made on execution of composite Web Service in a
dynamic environment with help of Mobile Agents [7],[8].
In a dynamic environment, it is recommended to decompose the planning process into several steps,
each step to take care of a portion of the plan that is under development. When a portion of the plan
is finished, it is immediately submitted for execution [8].
A Mobile Agent (Software Agent) is a piece of software that acts autonomously to undertake tasks
on behalf of users [8]. The design of many agents is based on the approach that the user only needs
to specify a high-level goal instead of issuing explicit instructions, leaving the how and when
decisions to the agent. A Mobile Agent exhibits a number of features that make it different from
other traditional components including autonomy, goal-orientation, collaboration, exibility, self-
starting, temporal continuity, character, communication, adaptation, and mobility [8].
For the agentification of Web services an agent-based multi-domain architecture is used (Fig. 2.2)
[8]. Two types of domain exist: user-domain and provider-domain. Two types of agents are
considered in the agentification process of an environment of Web services:
• user-agent act on behalf of users
• provider-agent act on behalf of providers who manage Web services.
In Fig. 2.2, the user-domain has a service-zone and a working-zone. The service-zone has a
dedicated portal from which composite services are developed and deployed. In addition, the
service-zone has a pool from which user-agents are created. For their installation, user-agents are
initially located in the working-zone of the user-domain. User-agents are mobile and thus, have the
capacity to migrate from one domain to another. When a user selects a composite service, a user-
agent handles the performance of that composite service and decides which component services will
be included (based on execution cost and location of computing host). A provider-domain consists
of a working-zone and several portals of Web services. Each portal is reserved to a category of Web
services (e.g., travel, education). The working-zones are devised in a way to receive user-agents
arriving from the user-domain or from other provider-domains. Within these working zones,
installation procedures of user-agents and control procedures of their credentials are performed.
Portals of provider-domains are associated with provider-agents; they handle the invocation
requests that user-agents submit to the services. A user-agent submits a local request to a provider-
agent in case both agents reside in the same provider-domain. This means that the user-agent has
migrated to that provider-domain. The user-agent arrives either from the user-domain or from a
different 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 that service can be executed [8].
12
The [7] and the [8] use different criteria for selecting component Web Services into composite one.
The system described in [7] is based on the semantic service descriptions (DAML-S) that could be
extended by Semantic Search possibilities in the future.
The [8] considers two criteria, namely execution cost and location of computing host that actually
represents the number of component services that could be executed in the same domain (i.e.,
indirectly this affects execution time).
Thereis an introduction of a new architectural solution as Agent Middle Layer [7] that aims to
dynamic service composition and follows the principles:
• composite services are interpreted as tasks;
• Service Mediator is formed dynamically as the coalition of service providing agents
(SPAs) participating in the task execution;
• SPAs join task coalitions only for the time their service is required for the respective
task;
• SPAs are economically rational, autonomous and independent in taking their decisions;
• services are self-contained modular loosely coupled programs wrapped by SPAs.
Approaches of selection elementary Web Services using Mobile Agents become popular, since they
allow carrying out composition and execution of Web services in parallel. This is important for fast,
reliable, dynamic composition with exception handling during run-time. The technological bases
could differ, while the method discussed in [7] and in [8] deserves attention and has to be further
investigated by various researches.
Fig. 2.2. Agent-Based multi-domain architecture
Portal of composite services
Pool of user-agents
Working-zone User-agents
Administrator
Service-zone
User-domain
Working-zone
Provider-Agent
Working-zone
Administrator
Provider-domain2 Provider-domain1
Provider-domain4 Provider-domain3
Portal21 of Web Services
Portal11 of Web Services
Portal12 of Web Services
migration
remote
invocation
migration
local invocation
remote invocation
User-Agent Network
13
3.1. Execution paths and plans
Process of modeling composite Web Services closely correlates with notion of execution paths.
Execution path is a simply ordered sequence of task t1..tn, where ti is a direct successor of ti-1, i.e.
there is a sequence of adjacent transitions going from ti-1 to ti without traversing any other basic
state.
If ti is the initial state of an AND-state, then for every other concurrent region C inside this AND-
state, one of the initial states of C appears in [t1, ..., ti-1, ti+1, ..., tn]. In other words, when an AND-
state is entered, all its concurrent branches are executed [1].
Any acyclic statechart has a finite number of execution paths. Actually, if statechart is not acyclic
then “unfolding” technique must be applied. The method used to unfold the cycles of a statechart is
to examine the logs of past executions in order to determine the average number of times that each
cycle is taken. The states appearing between the beginning and the end of the cycle are then cloned
as many times as the cycle is taken in average.
Under the assumption that the underlying statechart is acyclic, it is possible to represent an
execution path of this statechart as a Directed Acyclic Graph (DAG) as follows [1]:
Definition 1 (DAG representation of an execution path): Given an execution path [t1, t2, .. tn] of a
statechart, the DAG representation of this execution path is a graph obtained as follows:
• The DAG has one node for each task t1, t2, .. tn.
• The DAG contains an edge from task ti to task tj iff tj is a direct successor of ti in the
statechart.
If a statechart diagram contains conditional
branching, it has multiple execution paths. Each
execution path represents a sequence of tasks to
complete a composite service execution. Figure
3.1 gives an example of a statechart's execution
paths.
On the Figure 3.1 the states [t1..t8] represent the
corresponding states of Fig 2.1.
As stated before, the basic states of a statechart
describing a composite service can be labeled
with invocations to communities. If this is the
case, actual Web services (i.e., members of
communities) need to be selected during the
execution of the composite service. The concept
of execution plan defined below captures the various ways of executing a given execution path.
Definition 2 (Execution plan): A set of pairs p = {<t1; si1>, < t2; si2>,..,<tn; sin>} is an execution
plan of an execution path We iff:
• {t1, t2, ... tN} is the set of tasks in We.
• For each 2-tuple < tj ; sij > in p, service sij is assigned the execution of task tj .
Following the concept of Web service community (where many services could be selected for one
task), to differentiate the members of a community during service selection, their non-functional
properties need to be considered.
For this purpose, the Web services quality model is constructed, based on a set of quality criteria
(i.e. non-functional properties) that are transversal to all Web services, as their pricing and
reliability.
3. Global Selection Approach
Execution Path 1 (We1)
Execution Path 2 (We2)
t1 t2
t3 t4
t5 t6
t7
t1 t2
t3 t4
t5 t8
t8
Fig. 3.1. DAG representation of the execution paths of the statechart of Figure 2.1.
14
However, the quality model is extensible, i.e. new criteria can be added without fundamentally
altering the service selection techniques. In particular, it is possible to extend the quality model by
integration Quality of Experience (QoE) and Quality of Business (QoBiz) metrics. Under the latter
are subsumed such metrics that express response times and availability of a service as experienced
by a customer (QoE) and metric expressed in terms of money, such as the average amount of money
received per executed transaction (QoBiz) [6].
The general distinctions between QoE and QoS metrics are that QoE metrics may have a subjective
element to it while QoS task measure do not, and QoE metrics may be influenced by any system
between the service provider and the customer, while task measure relates to the quality of the
considered system and service only. An example of such influence is the QoE of a web site, which
heavily depends on the ISP’s network conditions, the speed of the modem, etc. See the Table 3.1 for
examples [6].
3.2. Quality Criteria of Web Services
[1] proposes the following criteria for composing Web services: (1) execution price, (2) execution
duration, (3) reputation, (4) reliability and (5) availability of Web Service.
Suppose that N is a total number of tasks in the execution plan p of a composite Web Service.
Execution price
Web service providers set the execution price of an elementary qprice(s, t) as the amount of money
that a service requester has to pay for executing the task t.
Then execution price for composite Web Service with execution plan p Qprice(p) is a sum of every
service si's execution price qprice(si,ti) [1]
Qprice(p) = ∑=
N
i
iiprice tsq1
),(
Execution duration
The execution duration Qdu(p) of an execution plan p is computed using the Critical Path Algorithm
(CPA). Specifically, the CPA is applied to the execution path of execution plan p, seen as a project
digraph. The critical path of a project digraph is a path from the initial state to the final state, which
has the longest total sum of weights labeling its nodes, where the weights labeling the nodes
correspond to the maximum expected execution durations. A task that belongs to the critical path is
a critical task, while a service that belongs to the critical path is a critical service.
Figure 3.2 provides an example of critical path. In this example, the project digraph represents
execution path We1 and its execution plan p, where p={< t2; s23 >, < t3; s38 >, < t4; s45 >, < t5; s59>,
< t6; s62>}. Each task's execution duration is given in the project digraph. The execution duration
for elementary service qdu(s, t) is measured as delay between the moment when a request is sent and
Table 3.1. List of some quality metrics of different types
QoS: system QoS: task QoE QoBiz
availability
reliability
queue length
processing
capacity
bandwidth
error rate
throughput
capacity
headroom
memory capacity
up at arrival
successful completition
probability
waiting time
response time
achievable throughput
memory used for task
successful download
completion probability
end-to-end response time
perceived speed of
download
customer friendly site
transaction lost
dollars per transaction
revenue of web site
revenue per page
visiting robots costs
15
the moment when the results are received. The
execution duration is computed using the
expression:
qdu(s, t) = Tprocess(s, t) + Ttrans(s, t),
Tprocess(s, t) is taken from service description
and the transmission time Ttrans(s, t) is
estimated based on past executions of the
service operations [1].
So in general,
Qdu(p) = CPA(qdu(s1,t1), .., qdu(sN, tN))
Reputation The reputation of a service is a measure of its trustworthiness. It mainly depends on end user's
experiences of using the service. This is a so-called QoE metric and Qrep(p) of an composite service
is the average of each service si's reputation in the execution plan p [1]:
Qrep(p)= N
sqN
i
irep∑=1
)(
The qrep(si) is defined as the average ranking given to the service by end users [1].
Reliability The reliability Qrel(p) of a Web Service is a product of exp(qrel(si)*zi). Here, zi is equal to 1 if
service si is a critical service in the execution plan p, or 0 otherwise [1]:
Qrel(p) = iirel zsqN
i
e*)(
1
∏=
The reliability qrel(s) of an elementary service s is the probability that a request is correctly
responded within the maximum expected time frame (which is published in the Web service
description). The value of the reliability is computed from historical data about past invocations
considering the number of times that the service s has been successfully delivered within the
maximum expected time frame, and the total number of invocations [1].
Availability The availability Qav(p) of an execution plan p is a product of exp(qav(si)*zi) [1]:
Qav(p) = iiav zsqN
i
e)*(
1
∏=
The availability qav(s) of a service s is the probability that the service is accessible:
qav(s) = Ta(s)/θ
The Ta is the total amount of time (in seconds) in which service s is available during the last θ seconds (θ is a constant set by an administrator of the service community depending on type of service) [1].
Considering functions defined above, the quality vector of a composite service's execution plan is:
Q(p) = (Qprice(p);Qdu(p);Qav(p);Qrel(p);Qrep(p)) (1)
3.3. Selecting an Optimal Execution Plan
It was shown that statechart might have several execution paths as it has conditional branching (as
on Fig. 2.1). Execution path may have several execution plans as for each elementary task more
than one Web Service is available. The basic idea of global planning is the same as query
optimization in database management systems, i.e. several execution plans are identified and the
optimal plan is selected.
t1 t2
t3 t4
t5 t6 t8
Fig. 3.2. Critical path on We1 digraph
s38, 25 sec s45, 20 sec
s59, 2 sec
s62, 15 sec
s23, 20 sec
Legend: Critical Path Critical task
16
Assume that a statechart has n execution paths; so n optimal execution plans exist.
Due to possibility of conditional branching during run-time, the accurate execution path is not
known beforehand. Therefore, n optimal execution plans have to be aggregated into overall
execution plan that will be used to execute the whole statechart.
In example for “Travel Designer” statechart on Figure 2.1, there are two execution paths We1 and
We2 (Fig. 3.1.). Suppose, that optimal execution plans p1 and p2 for We1 and We2 are selected. The
following approach is used to aggregate multiple execution plans into an overall execution plan [1]:
1. Given a task ti, if ti only belongs to one execution path (e.g., Wej), then the global planner
selects Wej 's execution plan pj to execute the task ti. It is denoted as ti(pj).
For example, in trip planning statechart, task t7 (Car Rental) only belongs to execution path
We2, so We2's execution plan p2 is used to execute t7, i.e. t7(p2).
2. Given a task ti, if ti belongs to more than one execution paths (e.g., Wej, Wej+1, ..., Wem), then
there is a set of execution plans (i.e., pj, pj+1, ..., pm). In this case, the global planner needs to
select one of the execution plans from pj, pj+1, ..., pm. The selection can be done by
identifying the hot path for task ti.
Definition (hot path): The hot path of a task ti is the execution path that has been most frequently
used to execute task ti in the past.
Considering an example of “Travel Designer”, task t3 (Flight Ticket Booking) belongs to
both execution paths We1 and We2. Assuming that the statechart has been executed for 25
times, amongst them 20 times We1 was used; against 5 times of We2. This indicates that
execution path We1 has been more frequently used to execute task t3 and so We1 is the hot
path for t3. Thus, We1's execution plan p1 is used to execute t3, i.e. t3(p1).
Since system keeps composite service execution traces in an execution history [1], the identification
of hot path must be possible.
Since the approach of aggregating optimal execution plans into overall execution plan must be clear
now, computing the optimal execution plan for a certain execution path is left to show.
Now let’s consider an arbitrary execution path. Assume that for each task tj, there is a set of
candidate Web services Sj available. After optimization only one Web Service from Sj is selected to
execute the tj. The execution plan’s quality vector is computed based on each compound Web
service’s quality vector (1). The global selector generates a set of execution plans P:
P = {p1, p2, ..., pn}, (2)
where n is the number of execution plans. In order to find the optimal each execution plan's global
service quality vector needs to be computed. Once the quality vector (1) for each execution plan is
derived, we obtain a matrix Q by accumulating all the execution plans' quality vectors:
Q =
≡
5,4,3,2,1,
5,24,23,22,21,2
5,14,13,12,11,1
22222
11111
..........
..........
)()()()()(
..........
..........
)()()()()(
)()()()()(
nnnnnnrepnrelnavndunprice
reprelavduprice
reprelavduprice
QQQQQ
QQQQQ
QQQQQ
pQpQpQpQpQ
pQpQpQpQpQ
pQpQpQpQpQ
(3)
An additive weighting technique is used to select an optimal execution plan.
Some of the criteria are negative: the higher the value, the lower quality, for example execution
time and execution price. Others are positive criteria: the higher value, the higher quality. For
negative criteria values are scaled according to Equation 4.
Vij =
≠−
−−
otherwise
QQQQ
QQjj
jj
ijj
,1
0, minmax
minmax
max
j=1,2 (4)
17
For positive criteria, values are scaled according to Equation 5.
Vij =
≠−
−−
otherwise
QQQQ
QQjj
jj
jij
,1
0, minmax
minmax
min
j=3,4,5 (5)
In the above equations, max
jQ is maximal value of a quality criterion in matrix Q (3):
max
jQ = Max( Qi;j), 1 < i < n
min
jQ is minimal value of a quality criterion in matrix Q:
min
jQ = Min( Qi,j); 1 < i < n
In fact, computing max
jQ and min
jQ can be done without generating all possible execution plans. For
example, in order to compute the maximum execution price ( max
priceQ ) of all the execution plans, the
most expensive Web service for each task should be selected and sum up all these execution prices
to compute max
priceQ . In order to compute the minimum execution duration ( min
duQ ) of all the execution
plans, the Web service that has shortest execution duration for each task should be selected and use
CPA to compute min
duQ . The computation cost of max
jQ and min
jQ is polynomial [1].
Using (5) and with help of the following formula end users can give their preference to compute the
overall quality score for each execution plan:
Score(pi) = ∑=
5
1
, )*(j
jji WV , (6)
The Wj ∈ [0,1] and ∑=
5
1j
jW = 1. Wj represents the weight of each criterion. The global planner will
choose the execution plan pi which has the maximal value of Score(pi). If there are more than one
execution plans which have the same maximal value of Score(p), then an execution plan could be
selected from them randomly.
3.4. Linear Programming solution
The approach of selecting an optimal execution plan requires the generation of all possible
execution plans. Such an approach is impractical for large-scale composite services, where both the
number of tasks in the composite services and the number of candidate Web services in
communities are large. The method based on linear programming (LP) is used to allow selection of
the optimal execution plan without generating all possible plans [21].
“A Linear Programming problem comes to identifing an extreme (i.e., minimum or maximum) point
of a function f(x1,x2,..,xn), which furthermore satisfies a set of constraints, e.g., g(x1,x2,..,xn)>0.
Linear programming is the specialization of mathematical programming to the case where both,
function f (objective function) and the problem constraints are linear...” [21].
From an applications perspective, linear programming is an optimization tool. An important factor
for the applicability of the linear programming methodology, is the computational tractability of the
resulting analytical models. Under the advent of modern computing technology, this tractability
requirement translates to the existence of effective and efficient algorithmic procedures able to
provide a systematic and fast solution to these models [21].
There are three inputs in LP: variables, an objective function and constraints, where both the
objective function and constraints must be linear. The output of LP is the maximum (or minimum)
value of the objective function as well as the values of variables at this maximum or minimum point
[21].
18
In order to apply LP optimization technique to selection of an optimal execution plan, the objective
function is chosen as equatition (6) [1]:
( ))(max1
i
n
i
pScore=
(7)
Assume that A is the set of all tasks (i.e., basic states) of the statechart. For each task tj, there is a set
of Web services Sj that can be assigned to this task, but on the end, for each task tj, only one Web
service should be selected. Given that yij: (yij = 0 or 1) denotes the participation of Web service sij
in the selected plan.
This latter fact is captured by the following constraint [1]:
∑∈
∈∀=jSi
ij Ajy ,1 (8)
For example, there are 100 potential Web services that can execute task tj, since only one of them
will be selected to execute the task tj, then we have ∑=
100
1i
ijy = 1.
Assume that variable xj represents the earliest start time of task, variable τj represents the execution duration for task tj, and variable τij represents the execution duration for task tj by service sij. The notation tj → tk is used to denote that task tk is task tj's direct successor task. We have the following
constraints [1]:
Ajy j
Si
ijij
j
∈∀=∑∈
,ττ (9)
xk – (τj + xj) ≥ 0, ∀ tj→ tk, j,k ∈ A (10)
Qdu – (xj + τj) ≥ 0, ∀j ∈ A (11)
Constraint 9 indicates that the execution duration of a given task tj is equal to the execution duration
of one of the Web services in A. Constraint 10 captures the fact that if task tk is a direct successor of
task tj , the execution of task tk must start after task tj has been completed. Constraint 11 indicates
that the execution of a composite service is completed only when all its tasks are completed [1].
Assume that zij is an integer variable that has value 1 or 0: 1 indicates that Web service sij is a
critical service and 0 indicates otherwise. We have the following constraint on execution plan's
duration Qdu [1]:
Qdu = ∑∑∈ ∈Aj Si
ijij
j
zτ (12)
For execution price, assume that variable cij represents the execution price of Web service sij, then
we have the following constraint on total execution price of composition service [1]:
Qprice = ∑∑∈ ∈Aj Si
ijij
j
yc (13)
An alternative of constraint 13 is as follows:
∑∑∈ ∈Aj Si
ijij
j
yc ≤ B, B > 0, (13’)
where B is the budget constraint given by the user. This constraint indicates that the entire
composite service's execution price cannot be greater than B.
It is worth noticing that constraints on other criteria can be easily incorporated into LP if the
aggregation function is a linear function. For example, assume that variable rij represents the
reputation of Web service sij (another speaking qrep(sij)), we can have the following constraint on the
execution plan's reputation [1]:
19
Qrep = ∑∑∈ ∈Aj Si
ijij
j
yr (14)
Due to aggregation functions of availability and reliability are non-linear, it is needed to apply some
transformations first. It is possible to linearize them using a logarithm function as in [1]. Assume
that variable aij represents the reliability of Web Service sij (another speaking qrel(sij)). Since zij
indicates whether Web Service sij is a critical service or not, the reliability of execution plan is [1]:
Qrel = ( )∏ ∑∈ ∈
Aj Si
ij
za
j
ijij ye (15)
By applying the logarithm function ln, we obtain:
ln(Qrel) = ( )∑ ∑∈ ∈
Aj Si
ij
za
j
ijij yeln (16)
since we have a constraint (8) and, furthermore, yij = 1 if sij participates in task tj, and 0 otherwise,
then it is possible to transform the (16) to the following:
Q’rel = ∑∑
∈ ∈Aj Si
ijijij
j
yza )( (17)
Similarly, assuming that bij represents the availability of the Web Service sij, the following
constraint is introduced:
Q’av = ∑∑
∈ ∈Aj Si
ijijij
j
yzb )( , (18)
where Q’av = ln( Qav).
In the previous sections, it was assumed that the execution duration τij of Web services are
deterministic. In reality, the execution duration of a Web service sij may be uncertain. To address
this issue, it is advised to model each τij using a normal distribution [1]. Since (12) the total execution duration Qdu must follow a normal distribution whose deviation δdu is [1]:
δ2du =∑∑
∈ ∈Aj Si
ijij
j
z2δ (19)
So in order to consider the deviation of the total execution duration in the LP problem, we should
adopt the following objective function (adding Q0 criteria as δ2du):
Max
−−
+
−−
∑∑==
5
3minmax
min
,2
0minmax
,
max
**j
j
jj
jji
j
j
jj
jijW
QQW
QQ (20)
Q0 = δ2du and W0 ∈ [0,1] is the weight assigned to the deviation of the total execution duration.
Given the above inputs for the LP problem, the output of the LP solver will be a set of values for
variables yij , which indicates the selection or exclusion of Web services sij . The selected Web
services compose an optimal execution plan.
3.5. Implementation assessment
The proposed QoS-driven selection technique is implemented in the SELF-SERV prototype. The
prototype architecture (Figure 3.3) features an interface, a service manager and a pool of services.
Services communicate via Simple Object Access Protocol (SOAP) messages. The service manager
consists of four modules, namely [1]:
20
• service discovery engine,
• the service editor,
• the composite service orchestrater
• the global planner.
The service discovery engine facilitates the advertisement and location of services. It is
implemented using the Universal Description, Discovery and Integration (UDDI), the Web Service
Description Language (WSDL), and SOAP. The service editor provides facilities for defining new
services and editing existing ones. A service is edited through a visual interface, and translated into
an XML document for subsequent analysis and processing by the service orchestrater. The
orchestrater is responsible for scheduling, initiating, and monitoring the invocations to the tasks of a
composite service during its execution, and for routing events and data items between these
components [1].
Finally, global planner is the module that plans the execution of a composite service using the
global planning based approach. The global planner is implemented as a linear programming solver
based on IBM's Optimization Solutions and Library (OSL) [1].
The aim of the experiment was to investigate the system costs of executing composite services
using the LP-based global planning and local selection approaches. The experiment was done by
measuring: (i) computation cost (i.e., time used for selecting a Web service for each task of the
composite service); (ii) bandwidth cost (i.e., network bandwidth consumed between global planner
and Web services).
Results has shown that for both global and local selection approaches, the computation cost
increases when the number of tasks and the number of candidate Web services increases. As
expected, the computation cost of global planning approach is a little bit higher than that of local
selection approach. A composite service with 40 tasks spends: (i) 1.6 seconds for selecting Web
services in global planning approach, (ii) 0.7 seconds in local selection approach [1].
Similar observations are found regarding bandwidth cost. More specifically, for both approaches,
the linear increase of the number of tasks and the number of candidate Web services leads almost a
linear increase of bandwidth cost. The bandwidth cost in global planning is slightly higher than that
of local selection approach. For example, a composite service with 40 tasks consumes about 2080
KBytes of network bandwidth for selecting Web services in global planning approach, while it
consumes 1910 KBytes in local selection approach [1].
The overall results show that the proposed approach effectively selects high quality execution plans
(i.e., plans which have higher overall QoS). But the support for exception handling during
composite service executions is missing. For example, after an execution plan has been built and
while it is being executed, an exception may occur (e.g., unavailability of a component service). It
could be corrected by performing dynamic plan revision during composite service execution, as a
means to respond to runtime exceptions. An Agent Mediated Web Service execution can also
handle this problem.
Service Discovery Engine
Service Builder
Composite Service Orchestrator
Global Planner
Service Manager
User Interface
UDDI Registry
requests results
Service Advertisements Service Discovery
Fig. 3.3. SELF-SERV architecture [1]
21
Web services technology is becoming increasingly popular because of its potential in many areas. It
is a new type of components that can be invoked over the Internet. This presents a promising
solution for addressing platform interoperability problems faced by system integrators. The
flexibility of this new component type also facilitates service composition using existing Web
services, promoting component re-use which has been a dream for the software engineering
industry. Web services technology is now over two years old. Although it has a lot of potential, but
the adoption rate has been slow. According to Gartner research [4], Web services technology’s real
take up is by 2005. There are many factors that may contribute to this slow take up, such as
confusion in standardizing, perceived lack of security and transaction support. Although there are
emerging standards in these areas such as WS-Coordination, WS-Transaction, WS-Security etc., a
coherent picture with full support in all these areas is yet to be seen [20].
Dynamic selection of component services is an important issue in Web services composition. Web
service integration requires more complex functionality than SOAP, WSDL, and UDDI can
provide. The functionality includes transactions, workflow, negotiation, management, and security.
There are several efforts that aim at providing such functionality, for example, the recently released
Business Process Execution Language for Web Services (BPEL4WS), which represents the
merging of IBM's Web Services Flow Language (WSFL) and Microsoft’s XLANG, is positioned to
become the basis of a standard for Web service composition. These languages are based on
SOAP+WSDL+UDDI basic stack, are complex procedural languages, and very hard to implement
and deploy.
Because of its potential for service composition, agent research community has also explored it for
composing agent’s behaviors. The researches are carrying on in the field of invoking Web Services
using Mobile Agents. The first prototypes of such systems are already available [7].
There are also some proposals such as DAML-S, which is a part of DARPA Agent Markup
Language project that aims at realizing the Semantic Web concept. DAML-S has been adopted to
automatic service discovery, composition, execution and monitoring of Web services. However,
DAML-S is a complex procedural language for Web service composition.
Because Web services can be provided by third parties and invoked dynamically over the Internet,
their QoS can vary greatly. Therefore it is important to have a framework capturing the QoS
abilities of Web Services during finding/discovering the Web service as well as composing
integrated Web Service. The global selection approach enables us selecting Web Services by their
non-functional characteristics (QoS) in dynamic peer-to-peer environment.
There are many aspects of QoS important to Web services. The work has been started to organize
them into QoS categories [6]. Each category needs to have a set of quantifiable parameters or
measurements. Further research is needed in this area. The advantage of global selection approach
is that it correlates with Web services technology basis and could be easily extended to capture
other linear-expressed quality metrics (e.g. QoBiz and QoE).
4. Conclusion
22
[1] L. Zeng, B. Benatallah, M. Dumas, J. Kalagnanam, and Q. Z. Sheng. Quality Driven Web
Service Composition. In Proceedings of The Twelfth International World Wide Web
Conference (WWW'2003), Budapest, Hungary, 2003.
[2] B. Benatallah, M. Dumas, Q. Z. Sheng, and A. Ngu. Declarative Composition and Peer-to-
Peer Provisioning of Dynamic Web Services. In Proc. of ICDE'02, IEEE Computer Society,
pages 297{308, San Jose, 2002.
[3] W.M.P. van der Aalst. Don't go with the flow: Web services composition standards exposed
(2003). http://tmitwww.tm.tue.nl/staff/wvdaalst/Publications/publications.html
[4] Shupping Ran. A Model for Web Services Discovery With QoS ACM SIGecom Exchanges,
Volume 4, Issue 1, Spring 2003, Pages 1-10
[5] B. Medjahed, B. Benatallah, A. Bouguettaya, A. H. H. Ngu, A. K. Elmagarmid, Business-to-
business interactions: issues and enabling technologies. The VLDB Journal — The
International Journal on Very Large Data Bases, Volume 12 Issue 1
[6] A. van Moorsel. Metrics for the Internet Age: Quality of Experience and Quality of
Business. Technical Report HPL-2001-179, HP Labs, August 2001. Also published in 5th
Performability Workshop, September 2001, Erlangen, Germany.
[7] Vadim Ermolayev, Natalya Keberle, Sergey Plaksin, Towards Agent-Based Rational
Service Composition – RACING Approach. http://www.zsu.zp.ua/racing
[8] Zakaria Maamar, Quan Z. Sheng, Boualem Benatallah. Interleaving Web Services
Composition and Execution Using Software Agents and Delegation,
http://www.cse.unsw.edu.au/~qsheng/full-list.html
[9] Web Service Composition Standards,
http://lsdis.cs.uga.edu/proj/meteor/mwscf/standards.html
[10] Composition of Web Services: different approaches,
http://www.site.uottawa.ca/~omarquez/Documents/Web%20Services%20Composition%20a
proaches.ppt
[11] Introduction to Semantic Web, http://www.semanticweb.org/introduction.html
[12] SOAP, http://www.w3.org/TR/SOAP/
[13] IBM Web Services, http://www-106.ibm.com/developerworks/webservices/
[14] David Trastour. Claudio Bartolini. Chris Preist Semantic Web Support for the Business-to-
Business E-Commerce Lifecycle WWW2002, May 7-11, 2002, Honolulu, Hawaii, USA
[15] B. Benatallah, M. Dumas, M-C. Fauvet, F.A. Rabhi, Towards Patterns of Web Services
Composition. http://www.cse.unsw.edu.au/school/research/tr.html
[16] Petia Wohed, Wil M.P. van der Aalst, Marlon Dumas, Arthur H.M. ter Hofstede. Pattern
Based Analysis of BPEL4WS (2002).
http://tmitwww.tm.tue.nl/research/patterns/start_doc.htm
[17] Rachid Hamadi, Boualem Benatallah. A Petri Net-based Model for Web Service
Composition. ADC 2003: 191-200
[18] B. Benatallah, Q. Z. Sheng, and M. Dumas. The Self-Serv Environment for Web Services
Composition. IEEE Internet Computing, 7(1), January/February 2003.
[19] F. Casati, S. Ilnicki, L.-J. Jin, V. Krishnamoorthy and M.-C. Shan. eFlow: a Platform for
Developing and Managing Composite e-Services. Technical Report HPL-2000-36, HP
Laboratoris, Palo Alto, 2000.
[20] Web Services Coordination, http://www-106.ibm.com/developerworks/library/
[21] Linear Programming FAQ, http://www-unix.mcs.anl.gov/otc/Guide/faq/linear-
programming-faq.html
References