Web Service Composition
Adrian Popa, Dragos Rogojan
Abstract. The number of products and services available over the Internet
increases dramatically during the last years and it is already beyond the human
ability to analyze and combine them efficiently. In this work, we address the
problem of the composition of web services. Composite web services can be
composed from multiple component web services given a workflow
specification. We introduce Web Services and Web Service orchestration.
Keywords: Web service, composition, integration, workflow, Web
engineering, knowledge representation, semantic web, ontology.
1 Introduction
The growing trend in software architecture is to build platform-independent software
components, called Web services that are available in the distributed environment of
the Internet. Applications are to be assembled from a set of appropriate Web services
and no longer be written manually. Seamless composition of Web services has
enormous potential in streamlining business to-business or enterprise application
integration.
1.1 Service-Oriented Architecture
Service-Oriented Architecture (SOA) is an architectural style whose goal is to achieve
loose coupling among interacting software entities, in order to facilitate the
integration of software components into distributed applications. A service is defined
as a piece of work performed by a service provider for the benefit of a service
consumer, where service provider and service consumer are roles played by software
entities.
Loose coupling is obtained by limiting the size and complexity of the service
interfaces, which should only encode generic semantics. Therefore, all application-
specific semantics have to be encoded in descriptive messages. Second, in order to
ensure interoperability, the messages have to be written in an open standard format
that is understood by all parties, generally XML.
Moreover, the message structure should be extensible to guarantee evolvability and
an SOA must provide a discovery mechanism that enables services to be discovered,
bound and interactively accessed.

2 Adrian Popa, Dragos Rogojan
1.2 Web Services
Web Services is a collection of SOA implementation technologies based on open
standard and interfaces, including XML, SOAP, WSDL, and UDDI. It is generally
accepted that Web Services are an SOA implementation that exchange XML
messages over an internet based transport protocol such as HTTP.
SOAP is a lightweight XML-based information exchange protocol for Web
Services. A SOAP message envelope describes what is in a message and how to
process it. The SOAP encoding defines a set of rules for mapping programmatic types
to XML. WSDL is an XML-based language for defining Web Services interfaces that
describe them and specify how to access them. UDDI is an XML-based protocol for
registering Web service descriptions, discover and retrieve them.
1.3 Service Composition
Web services aim at being building blocks for applications. Composite web services
can be composed from multiple component web services given a workflow
specification. The web service composition process typically relies on a centralized
engine that coordinates the composed services according to the workflow
specification. This type of service composition is also referred to as service
orchestration.
A service composition that involves multiple parties that collaborate to achieve a
common goal is referred to as a service choreography. Web service composition
languages provide a clear separation between the process logic and the Web services
invoked. Business processes can themselves be exposed as Web service, enabling
recursive composition.
Web service composition languages need to maintain state across Web Service
components and manage exceptions and transactional integrity. However, current
orchestration languages suffer from the lack of support for the distribution of the
orchestration logic. Work on decentralizing the orchestration of composite web
services demonstrated significant performance improvements in terms of increased
throughput, scalability and response time, especially when asynchronous messaging is
used.
Moreover, business process languages target long term web service orchestrations.
Some service collaborations only make sense in a particular context, and have a short
life cycle. There is therefore a need for the dynamic deployment and refinement of
short term orchestration mechanisms. To achieve dynamic workflow specifications,
the structure of the workflow should be cleanly separated from the workflow
interaction specification.
Finally, the hierarchical modularization of the composition specification does not
allow the encapsulation of some aspects of the orchestration such as exception
handling, authentication or business rules.

Web Service Composition 3
2 Web Service Composition Standards
A Web Service can represent a unit of business logic that an organization exposes to
other organizations on the World Wide Web. The recent efforts of the industry to
agree on a common definition for Web Services resulted in the Web Services (WS)
standard that governs how one defines, advertises and uses Web Services.
Composition of primitive Web Services into complex ones presents the next challenge
for the industry. Existing proposals for languages for service composition (also called
choreography of Web services) typically come from the business process modeling
community and often lack foundations in theoretical computer science and
possibilities to address composition from a more general perspective than business
process applications only.
2.1 BPEL4WS
The Business Process Execution Language for Web Services (BPEL4WS) is a
language to specify business processes and business interaction protocols. It
superseded XLANG and WSFL as a standard for web services flow specification. The
model and XML-based grammar provided by BPEL 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 and systematic way of
dealing with exceptional conditions.
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.
The services (described as partners in BPEL spec) that the proces invoke/reply
using basic activity are represented using their WSDL description. An executable
process itself can be a Web service by itself and the interface of that process can be
represented using WSDL.
2.2 BPML
BPML provides an abstract model and grammar for expressing abstract and
executable business processes. Using BPML, enterprise processes, complex web
services and multi-party collaborations can be defined. A process in BPML is a
composition of activities that perform specific functions.
The process directs the execution of these activities. It can also be a part of
composition by defining it as a part of its parent process or by invoking from another
process. Each activity (both simple and complex) in the process has a context, which
defines common behavior for all activities executing in that context. Hence a process

4 Adrian Popa, Dragos Rogojan
can be defined as a type of complex activity that defines its own context for
execution.
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. It also suggests standardizing BPML documents
by using RDF for semantic meta-data, XHTML and Dublin Core metadata to improve
human readability and application processability.
2.3 BPSS
ebXML is a global electronic business standard envisioned to define a XML based
framework that will allow businesses to find each other and conduct business using
well-defined messages and standard business processes. ebXML Business Process
Specification Schema is a standard for representing models for collaborating e-
business public processes.
Using XML syntax the parties involved in a collaboration can model and agree on
the relevant business process. ebXML BPSS standard can be used to configure the
business systems to support the commercial collaboration. Hence this specification
determines the actual exchange (identified as patterns) of business documents and
business signals between the partners.
A library of process templates can be created using BPSS definitions and to support
a business process template a user can extract information from the corresponding
BPSS and configure his runtime system by agreeing on a pattern and a role that
collaborates through a set of choreographed transactions by exchanging Business
Documents.
However there is no explicit support for describing how data flows between
transactions, but there is explicit support for specifying quality-of-service semantics
for transactions such as authentication, acknowledgements, non-repudiation, and
timeouts.
2.4 DAML-S
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. It defines an upper ontology appropriate for declaring and describing
services by using a set of basic classes and properties.
In DAML-S, each service can be viewed as a process and its Process Model is used
to control the interactions with the service. Using the processOntologys sub-
ontologies, ProcessOntology and ProcessControlOntology, it aims to capture the

Web Service Composition 5
details of the web service operation. The ProcessOntology describes the inputs,
outputs, preconditions, effects, and component subprocesses of the service.
ProcessControlOntology is used to monitor the execution of a service. However,
current version of DAML-S does not define the ProcessControlOntology. DAML-S
also categorizes three types of processes. The first type is atomic processes which do
not have any subprocesses and can be executed in a single step.
The second type is simple processes which are not invocable as they are used as
abstraction for representing atomic or composite processes to use them. Composite
processes are of third type which are decomposable into sub-processes. The
composite process uses lot of control constructs to specify how inputs are accepted
and outputs are returned by subprocesses.
2.5 WSCI
The Web Service Choreography Interface (WSCI) is a XML-based language for
description of the observable behavior of a Web service in a message exchange in the
context of a collaborative business process or workflows. It defines the flow of
messages exchanged by a stateful Web service describing its observable behavior.
By specifying the temporal and logical dependencies among the message exchange
it is used to describe a service in such a way that other web services can
unambiguously interact with it conforming to the intended collaboration. Though it
provides a message-oriented view of the process, it does not define the internal
behavior of the web service or the process.
It complements the static interface details provided by the WSDL file by describing
the way operations are choreographed and its properties. This is achieved by using the
dynamic interface provided by WSCI through which the inter-relationship between
different operations in the context of a particular operational scenario. The stateless
message exchange specification in a WSDL file is thus augmented with message
choreography and stateful message exchange.
Extensibility feature of WSCI suggests using RDF to annotate a WSCI interface
definition with additional semantics.
2.6 WSCL
Web Services Conversation Language allows defining the external visible behavior of
the services by specifying the business level conversations and public processes
supported by a web services.
The conversations are defined using XML syntax and the WSCL document also
specifies XML documents that are exchanged as a part of conversation and the order
in which they are exchanged. WSCL provides a minimal set of concepts necessary for
specifying the conversations.
The specification states that typically the conversation is provided from the
perspective of the service provider, which can also be used to determine the
conversation from the perspective of the user. Though the conversation is defined
from the service provider's perspective it separates the conversational logic from the
application logic or the implementation aspects of the service.

6 Adrian Popa, Dragos Rogojan
3 Modeling a Composite Web Service
A business process typically involves multiple parties. Thus, multiple Web services
may be required to collaborate with each other to form a composite Web service. For
example, a travel booking Web service may include three sub-processes: flight
reservation, hotel reservation, and car reservation. These three sub-processes may
be performed by three individual Web services provided by corresponding service
providers. The travel booking Web service thus becomes a composite Web service
involving three collaborative Web services. The Business Process Execution
Language for Web Services (BPEL4WS) is such a flow representation developed to
facilitate coordination of Web services into a comprehensive business process.
3.1 BPEL Basic Structure: via an Example
A user sends a purchase order (PO) request to an online supplier, who identifies a
payment service provider to handle the payment transaction and a shipping service
provider to schedule the shipping, before returning to the user with a result including
a payment receipt and a shipping schedule. This business process can be modeled as a
composite Web service OrderService, as shown in Fig. 1. From a customer’s
perspective, he/she faces one single Web service OrderService. This composite Web
service invokes two self-contained Web services from corresponding service
providers: a payment Web service from a payment service provider and a shipping
Web service from a shipping service provider. In order to construct this composite
Web service, a business workflow needs to be identified.
Fig. 1. A simple composite Web service OrderServicde

Web Service Composition 7
Without losing generality, the workflow can be simplified in four steps. First, the
user submits a PO request to the supplier; second, the supplier submits a payment
request to a payment service provider and the latter responds to the supplier with a
payment receipt; third, the supplier submits a shipping request based on customers’
requirements to a shipping service provider and the latter responds to the supplier
with a shipping schedule; fourth, the supplier returns to the user the result including a
payment receipt and a shipping schedule. As shown in Fig. 1., steps 2 and 3 are
synchronous calls, meaning that the caller (i.e., supplier) waits for a response after
sending a request. This simple workflow forms a sequential procedure. In order to
create this business process in BPEL, a two-phase procedure should be followed: the
first is to create service descriptions; the second is to create business processes.
3.1.1 Create Service Descriptions
First, involved business parties as well as the messages to be exchanged and
manipulated should be formally defined. A business process in BPEL relies on WSDL
descriptions to refer to the message types, the operations, and the portTypes to which
these operations belong. Using the example shown in Fig. 1., descriptions are needed
for the payment service, the shipping service, and the exchanged message formats.
Since the payment service and the shipping service belong to different service
providers, they are defined by corresponding service providers’ WSDL definition
documents. To simplify the presentation, the related portType definitions for both
payment service and shipping service are shown in one place in Fig. 2..
Fig. 2. WSDL definition segments for required services
Figure 2. shows the related WSDL definitions for the supplier. The WSDL
document first defines the namespace of the document for later references:
“http://servicescomputing.org/xsd/po”. Six types of messages to be used by the
process are defined: PurchaseOrderMessage, ResultMessage, paymentRequest-

8 Adrian Popa, Dragos Rogojan
Message, paymentResponseMessage, shippingRequestMessage, and shipping-
ResponseMessage. Three portTypes (purchseOrderPT, shippingPT, and paymentPT)
each contains a request-response operation: submitPurchaseOrder, shipping, and
payment, respectively. (shippingPT and paymentPT are defined in Fig. 2.) In this
example, the composite order service includes three synchronous communications:
one between the customer and the supplier; one between the supplier and the payment
service provider; one between the supplier and the shipping service provider.
Notice that no binding information is defined in the WSDL document. This BPEL
process is defined “in the abstract”, meaning that it only references the portTypes of
the involved services without their deployments. In this way, the related business
process definitions can be reused for multiple deployments of compatible services.
3.1.2 Create Business Processes
After service definitions are created, it is ready for business processes to be designed
in BPEL. Using the definitions of the portTypes, operations, and message types, the
process can be elaborated as shown in Fig. 3. In the first step, the customer calls the
submitPO operation with a message PurchaseOrderMessage; in the second step, the
supplier calls the submitPayment operation with a message paymentRequestMessage
and receives a message paymentResponseMessage; in the third step, the supplier calls
the submitShipping operation with a message shippingRequestMessage and receives a
message shippingResponseMessage; in the fourth step, the supplier returns to the
customer a message ResultMessage.
Fig. 3. Elaborated OrderService business process.

Web Service Composition 9
3.2 Creating Semantic Service Descriptions
DAML-S partitions a semantic description of a web service into three components:
the service profile, process model and grounding. The ServiceProfile describes what
the service does by specifying the input and output types, preconditions and effects.
The Process Model describes how the service works; each service is either an
AtomicProcess that is executed directly or a CompositeProcess that is a combination
of other subprocesses.
The Grounding contains the details of how an agent can access a service by
specifying a communications protocol, parameters to be used in the protocol and the
serialization techniques to be employed for the communication. The similarities
between DAML-S and other technologies may be expressed as follows: The profile
description has a similar functionality of the yellow pages in UDDI, the process
model is similar to the business process model in BPEL4WS and grounding is just a
mapping from DAML-S to WSDL. The main contribution of DAML-S is the ability
to express the entities using the concepts defined in Semantic Web ontologies which
provide expressive constructs that are suitable for the automatic discovery and
composition of services.
DAML-S service descriptions are made to link to other ontologies that describe
particular service types and their features. For example, an ontology can be written in
OWL that is specialized for the description of sensors. This ontology contains a top
level class Sensor to de ne the sensor concept. Sensor has subclasses such as
AcousticSensor and InfraRedSensor. In the semantics of OWL, subclasses inherit the
properties of superclass and may extend these attributes with additional ones. The
profile description of DAML-S services has a hierarchy as well. For example, the
service provided by an AcousticSensor constitutes a subclass of a Sensor service. A
profile hierarchy ontology describes this relationship and this information can be used
for filtering the services that can be composed together. Each service type has non-
functional attributes specific to that type. These attributes are defined via the
extensible service parameter mechanism in DAML-Sand are primarily used to relate
the service to the its associated sensor.
4 Dependability Requirements
Composite Web services have high dependability requirements that call for dedicated
fault tolerance mechanisms due to both the specifics of the Web services architecture
and limitations of the Internet, which is not a reliable media. The autonomy of
component Web services raises challenging issues in specifying composition
processes and in particular exceptional behaviours of composite services when
dealing with faults. These faults include but are not limited to faults occuring at the
level of the Web services, which may be notified by error messages faults at the
underlying platform and faults due to online upgrades of service components and / or
of their interfaces.

10 Adrian Popa, Dragos Rogojan
In general, the choice of fault tolerance techniques to be exploited for the
development of dependable systems depends very much on the fault assumptions and
on the systems characteristics and requirements. There are two main classes of error
recovery backward based on rolling system components back to the previous correct
state and forward error recovery which involves transforming the system components
into any correct state. The former uses either diversely implemented software or
simple retry; the latter is usually application specific and relies on an exception
handling mechanism. It is a widely accepted fact that the most beneficial way of
applying fault tolerance is by associating its measures with system structuring units as
this decreases system complexity and makes it easier for developers to apply fault
tolerance.
Structuring units applied for both building distributed systems and providing their
fault tolerance are well known they are distributed transactions and atomic actions.
Distributed transactions use backward error recovery as the main fault tolerance
measure in order to satisfy completely or partially the Acid properties. Atomic actions
allow programmers to apply both backward and forward error recovery.
The latter relies on coordinated handling of action exceptions that involves all
action participants. Backward error recovery has a limited applicability and in spite
of all its advantages, modern systems are increasingly relying on forward error
recovery, which uses appropriate exception handling techniques as a means
Examples of such applications are complex systems involving human beings.
Integrated Web services clearly fall into this category.
4.1 Backward Error Recovery for the Web
Transactions have been proven successful in enforcing dependability in closed
distributed systems and are extensively exploited for the implementation of primitive
non-composite Web services.
However transactions are not suited for making the composition of Web services
fault tolerant in general for at least two reasons:
- the management of transactions that are distributed over Web services requires
cooperation among the transactional supports of individual Web services which may
not be compliant with each other and may not be willing to do so given their intrinsic
autonomy and the fact that they span different administrative domains
- Locking resources until the termination of the embedding transaction is in general
not appropriate for Web services, still due to their autonomy, and also to the fact that
they potentially have a large number of concurrent clients that will not stand extensive
delays
Enhanced transactional models have been considered to alleviate the latter
shortcoming. In particular, the split model (also referred to as open-nested
transactions) where transactions may split into a number of concurrent sub
transactions that can commit independently allows reduction of the latency due to
locking. Typically, sub-transactions are matched to the transactions already supported
by Web services transactional booking offered by a service . Hence transactions
over composite services do not increase the access latency as offered by the individual
services. Enforcing the atomicity property over a transaction that has been split into a
number of sub-transactions then requires using compensation over committed sub-

Web Service Composition 11
transactions in the case of transaction abortion. However, to support this, Web
services should provide compensating operations for all the operations they offer.
Such an issue is in particular addressed by the BPEL and languages for specifying
composite services, which allow compensating operations associated with the
services operations to be defined.
4.2 Forward Error Recovery for the Web
Forward error recovery, using an exception handling mechanism is extensively
exploited in the specifications of composite Web services in order to handle error
occurrences. For instance, in BPEL, exception handlers, referred to as fault handlers,
can be associated to a possibly nested activity so that when an error occurs inside an
activity, its execution terminates and the corresponding exception handler is executed.
However, when an activity is defined as a concurrent process and at least one
embedded activity signals an exception, all the embedded activities are terminated as
soon as one signaled exception is caught, and only the handler for this specific
exception is executed.
Hence, error recovery actually accounts for a single exception and thus cannot
ensure recovery of a correct state. The only case where correct state recovery may be
ensured is when the effect of all the aborted activities are rolled back to a previous
state, which may not be supported in general, in the context of Web services. The
shortcoming of BPEL actually applies to all XML-based languages for Web services
composition that integrate support for specifying concurrent activities and exception
handling.
5 Conclusions
While a single Web Service can’t satisfy complex business needs, how to compose a
large granularity Web Service by small ones is an important issue at present.
However, the research of service composition focuses the selection of concrete
service on the basis of abstract service, and neglects abstract service modeling.
Among the most important expected benefits of a global service oriented
architecture leveraging web service standards is an increased level of automation in
the discovery, composition, verification, monitoring and recovery of services for the
realization of complex processes. Most existing works addressing this issue are based
on the Ontology Web Language for Services (OWL-S) and founded on description
logic. Because the discovery and composition tasks are designed to be fully
automatic, the solutions are limited to the realization of rather simple processes.

12 Adrian Popa, Dragos Rogojan
References
1. A. Walsh. UDDI, SOAP, and WSDL: The Web Services Specification Reference Book,
Prentice Hall, April 2002
2. Business Process Execution Language for Web Services Specification (BPEL4WS), BEA,
IBM, Microsoft, SAP AG and Siebel Systems.
3. High JR, Kinder S, Graham S (2005) IBM SOA foundation - architecture overview.
4. Stal M (2006) Using architectural patterns and blueprints for service-oriented architecture.
IEEE Software 23: 54 61
5. Web services architecture. http://www.w3.org/TR/ws-arch/
6. Web Services Description Language (WSDL). http://www.w3.org/TR/wsdl
7. SOAP specifications. http://www.w3.org/TR/soap/
9. XML. http://xml.coverpages.org/xml.html
10. XML Schema. http://www.w3.org/XML/Schema
11. OMG CORBA. http://www.corba.org/
12. UDDI. http://www.uddi.org/specification.html