Spotlight
Current Solutions for
Web Service Composition
I
n service-oriented computing (SOC), develop-
ers use services as fundamental elements in
their application-development processes. Ser-
vices are platform- and network-independent
operations that clients or other services invoke. To
operate in an SOC environment, services must
overtly define their properties in a standard,
machine-readable format. SOC thus offers three
native capabilities: description, discovery, and
communication.
1
Web services are a typical SOC
example: developers implement SOC native capa-
bilities using Web Services Description Language
(for description), Universal Description, Discov-
ery, and Integration (for discovery), and SOAP (for
communication).
2
To create applications, SOC developers use ser-
vice composition, which they introduce on top of
SOC’s native capabilities. Developers and users can
then solve complex problems by combining avail-
able basic services and ordering them to best suit
their problem requirements. Service composition
accelerates rapid application development, service
reuse, and complex service consummation. Cur-
rently, however, service composition isn’t stan-
dardized, nor does it include definitions of the key
requirements that every composition approach
must satisfy (such as scalability, dependability, and
correctness). If the SOC paradigm is to succeed and
become the dominant architecture of future dis-
tributed systems, we must provide a stable and
dependable service composition solution.
Here, we offer a survey of existing proposals for
Web service composition, and compare them with
respect to four key requirements, which we discuss
in the next section. By offering this overview and
systematization of key properties, as well as a con-
structive critique of existing approaches, we hope to
help service-composition designers and developers
focus their efforts and deliver more usable and
durable solutions, while also addressing the tech-
nology’s critical needs.
Service
Composition Requirements
The complexities of distributed systems and
increasing trust barriers have influenced SOC evo-
lution at the hardware, operating system, and
application layers. Although modern operating sys-
tems can also be seen as sets of collaborating ser-
vices, in this survey, we focus on the application
layer. From the developer’s perspective, service
composition offers reuse possibilities. From the
user’s perspective, it offers seamless access to a
variety of complex services.
Service composition requirements differ from
those of mainstream component-based software
development. In place of access to documentation
or code (either source or binary), SOC application
developers and users have access only to WSDL’s
rudimentary functional descriptions. Services exe-
cute in different containers, separated by firewalls
and other trust barriers. A composition mechanism
IEEE INTERNET COMPUTING 1089-7801/04/$20.00 © 2004 IEEE Published by the IEEE Computer Society NOVEMBER • DECEMBER 2004 51
Web service composition lets developers create applications on top of service-
oriented computing’s native description, discovery, and communication
capabilities. Such applications are rapidly deployable and offer developers reuse
possibilities and users seamless access to a variety of complex services. There are
many existing approaches to service composition, ranging from abstract methods
to those aiming to be industry standards. The authors describe four key issues for
Web service composition.
Editor: Siobhán Clarke • siobhan.clarke@cs.tcd.ie
Nikola Milanovic and Miroslaw Malek • Humboldt University, Berlin
must therefore satisfy several requirements: con-
nectivity, nonfunctional quality-of-service prop-
erties, correctness, and scalability.
Every composition approach must guarantee
connectivity. With reliable connectivity, we can
determine which services are composed and reason
about the input and output messages. Because Web
services are based on message passing, however,
developers must also address nonfunctional QoS
properties, such as timeliness, security, and depend-
ability. Composition correctness requires verifica-
tion of the composed service’s properties, such as
security or dependability. Finally, because compli-
cated business transactions are likely to involve
multiple services in a complex invocation chain,
composition frameworks must scale with the num-
ber of composed services.
We can illustrate the need for such require-
ments with two examples. First, suppose we have a
trusted and an untrusted service, where the service
architecture defines trust. What happens when we
compose these services in sequence? Is this com-
position trusted, untrusted, or something in
between? It’s crucial that we know whether our
application is secure and dependable. And what
happens when we compose two trusted services?
Do we assume that the composition of trusted ser-
vices will also be trusted?
Another example that demonstrates the need for
nonfunctional properties is a composition’s timeli-
ness. Suppose we have a simple handshaking
example with two partner services, in which one
wants to invoke a method on the other. The client
service expects to be notified when it can apply
(invoke a method), while the provider service
expects to be notified that the client wants to uti-
lize its service. Unless its developers understand
such requirements in advance, the composition will
not produce useful or expected results.
Web Service
Composition Approaches
Once Web services’ native capabilities were fully
developed, service composition approaches began
emerging. Because the first-generation composi-
tion languages — IBM’s Web Service Flow Lan-
guage (WSFL) and BEA Systems’ Web Services
Choreography Interface (WSCI) — were incompat-
ible, researchers developed second-generation lan-
guages, such as the Business Process Execution
Language for Web Services (BPEL4WS, or BPEL for
short), which combines WSFL and WSCI with
Microsoft’s XLANG specification. Nonetheless, the
Web Services Architecture Stack still lacks a
process-layer standard for aggregation, choreog-
raphy, and composition (www.w3.org/2002/ws).
Here, we examine several of the proposals for Web
services composition, comparing how they meet
requirements for connectivity, nonfunctional prop-
erties, correctness, and scalability.
BPEL
BPEL (www.ibm.com/developerworks/library/
ws-bpel) is an XML language that supports process-
oriented service composition.
3
Developed by BEA,
IBM, Microsoft, SAP, and Siebel, BPEL is currently
being standardized by the Organization for the
Advancement of Structured Information Standards
(www.oasis-open.org). (Sun Microsystems recently
joined the OASIS technical committee as well.)
BPEL composition interacts with a Web services’
subset to achieve a given a task. In BPEL, the com-
position result is called a process, participating ser-
vices are partners, and message exchange or inter-
mediate result transformation is called an activity.
A process thus consists of a set of activities. A
process interacts with external partner services
through a WSDL interface.
To define a process, we use
• a BPEL source file (.bpel), which describes
activities;
• a process interface (.wsdl), which describes
ports of a composed service; and
• an optional deployment descriptor (.xml), which
contains the partner services’ physical locations
(a partner service’s implementation and loca-
tion can be changed without modifying the
source file).
BPEL has several element groups, but the basic
ones are
• process initiation: <process>
• definition of services participating in compo-
sition: <partnerLink>
• synchronous and asynchronous calls:
<invoke>, <invoke>... <receive>
• intermediate variables and results manipula-
tion: <variable>, <assign>, <copy>
• error handling: <scope>, <faultHandlers>
• sequential and parallel execution:
<sequence>, <flow>
• logic control: <switch>
As an example, we’ll model the composition of
52 NOVEMBER • DECEMBER 2004 www.computer.org/internet/ IEEE INTERNET COMPUTING
Spotlight
three services. Service A is called synchronously
and starts a process. Two asynchronous services,
B and C, are then called in parallel using Service
A’s output as their input. The process waits for
their completion and then makes a decision based
on the results. The stripped BPEL code for this
composition follows (for clarity, we’ve omitted
much of the code and assumed that all services
offer only one operation at one port):
<process name=“test”>
<partnerLinks>
<partnerLink name=“client”/>
<partnerLink name=“serviceA”/>
<partnerLink name=“serviceB”/>
<partnerLink name=“serviceC”/>
</partnerLinks>
<variables>
<variable name=“processInput”/>
<variable name=“AInput”/>
<variable name=“AOutput”/>
<variable name=“BCInput”/>
<variable name=“BOutput”/>
<variable name=“COutput”/>
<variable name=“processOutput”/>
<variable name=“AError”/>
</variables>
<sequence>
<receive name=“receiveInput” vari-
able=“input”/>
<assign><copy>
<from variable=“processInput”/>
<to variable=“AInput”/>
</copy></assign>
<scope>
<faultHandlers>
<catch faultName=“faultA” fault-
Variable=“AError”/>
</faultHandlers>
<sequence>
<invoke name=“invokeA” partner-
Link=“serviceA”
inputVariable=“AInput” output-
Variable=“AOutput”/>
</sequence>
</scope>
<assign><copy>
<from variable=“AOutput”/>
<to variable=“BCInput”/>
</copy></assign>
<flow>
<sequence>
<invoke name=“invokeB” partner-
Link=“serviceB”
inputVariable=“BCInput”/>
<receive name=“receive_invokeB”
partnerLink=“serviceB”
variable=“BOutput”/>
</sequence>
<sequence>
<invoke name=“invokeC” partner-
Link=“serviceC”
inputVariable=“BCInput”/>
<receive name=“receive_invokeC”
partnerLink=“serviceC”
variable=“COutput”/>
</sequence>
</flow>
<switch><case>
<!— assign value to processOutput —>
</case></switch>
<invoke name=“reply”
partnerLink=“client”
inputVariable=“processOutput”/>
</sequence>
</process>
Researchers recently released BPELJ (www
-106.ibm.com/developerworks/webservices/library/
ws-bpelj/), a combination of BPEL and Java that
lets developers include Java code inside BPEL
code. Developers can thus use Java “snippets” to
perform intermediate transformations such as
value calculations within documents; document
construction and deconstruction using informa-
tion from other documents and variables; and
value calculations for flow controls. They can
also perform side-effects without creating sepa-
rate Web services. A snippet can assume it’s run-
ning inside a J2EE container. It has access to all
variables and partner links that are in its loca-
tion’s scope. We can use a snippet, for example,
to write the <switch> construct omitted from the
previous example:
<bpelj:snippet>
<bpelj:code>
if (OutputB > OutputC)
processOutput = outputB;
else
processOutput = outputC;
</bpelj:code>
</bpelj:snippet>
Developers can use BPEL with two other
specifications:
IEEE INTERNET COMPUTING www.computer.org/internet/ NOVEMBER • DECEMBER 2004 53
Web Services Composition
• Web Services-Coordination (www-106.ibm.
com/developerworks/library/ws-coor/) coordi-
nates Web services’ actions when a consistent
agreement must be reached on the service
activities’ outcome.
• Web Services-Transaction (www-106.ibm.
com/developerworks/library/ws-transpec/)
defines Web services’ transactional behavior.
There are several BPEL orchestration server imple-
mentations for both J2EE and .NET platforms,
including IBM WebSphere (www-306.ibm.com/
software/info1/websphere), Oracle BPEL Process
Manager (formerly Collaxa BPEL Server; see www.
oracle.com/technology/products/ias/bpel/), Mic-
rosoft BizTalk 2004 (www.microsoft.com/biztalk),
OpenStorm ChoreoServer (www.openstorm.com),
and Active BPEL (www.activebpel.org).
Semantic Web (OWL-S)
The Semantic Web vision is to make Web resources
accessible by content as well as by keywords. Web
services play an important role in this: users and
software agents should be able to discover, com-
pose, and invoke content using complex services.
The DARPA Agent Markup Language (DAML)
extends XML and the Resource Description Frame-
work (RDF) to provide a set of constructs for cre-
ating machine-readable ontologies and markup
information. The DAML program’s Semantic Web
contribution is the Web Ontology Language for
Services (www.daml.org/services). OWL-S (previ-
ously known as DAML-S) is a services ontology
that enables automatic service discovery, invoca-
tion, composition, interoperation, and execution
monitoring.
4
OWL-S models services using a three-part
ontology:
• a service profile describes what the service
requires from users and what it gives them;
• a service model specifies how the service works;
and
• a service grounding gives information on how
to use the service.
The process model is a service model subclass that
describes a service in terms of inputs, outputs, pre-
conditions, postconditions, and — if necessary —
its own subprocesses. In the process model, we can
describe composite processes and their dependen-
cies and interactions. OWL-S distinguishes three
types of processes: atomic, which have no sub-
processes; simple, which are not directly invoca-
ble and are used as an abstraction element for
either atomic or composite processes; and com-
posite, which consist of subprocesses. Constituent
processes are specified using flow-control con-
structs: sequence, split, split+join,
unordered, choice, if-then-else, iterate, and
repeat-until.
OWL-S would orchestrate the previous section’s
example as follows (again, using only the most
important commands):
<daml:Class rdf:ID=“test”>
<daml:subClassOf
rdf:resource=“Process.CompositeProcess”/>
<daml:subClassOf>
<daml:Restriction>
<daml:onProperty
rdf:resource=“Process#composedOf”/>
<daml:toClass>
<daml:Class>
<daml:intersectionOf rdf:parse-
Type=“daml:collection”>
<daml:Class
rdf:about=“process:Sequence”>
<daml:Restriction>
<daml:onProperty
rdf:resource=“Process#components”/>
<daml:toClass>
<daml:Class>
<process:listOfInstancesOf
rdf:parseType=“daml:col-
lection”>
<daml:Class rdf:about=“#ser-
viceA”/>
<daml:Class
rdf:about=“process:Split”>
<daml:Restriction>
<daml:onProperty
rdf:resource=“Process#components”/>
<daml:toClass>
<daml:Class>
<process:listOfInstancesOf
rdf:parseType=“daml:col-
lection”>
<daml:Class
rdf:about=“#serviceB”/>
<daml:Class
rdf:about=“#serviceC”/>
</process:listOfInstance-
sOf>
</daml:Class>
. . .
54 NOVEMBER • DECEMBER 2004 www.computer.org/internet/ IEEE INTERNET COMPUTING
Spotlight
Researchers have proposed methods for transfer-
ring OWL-S descriptions to Prolog
5
and Petri-net-
based notation
6
to further analyze verification. In
the Prolog approach, the developer manually
translates an OWL-S description to Prolog, which
makes it possible to find an adequate plan for
composing Web services for a target description.
That is, for a given pool of available Web services,
it’s possible to use logical inference rules to auto-
mate service allocation for the required task. In the
Petri-net approach, an OWL-S description is auto-
matically translated into Petri nets. Developers use
this representation to automate tasks such as sim-
ulation, validation, verification, composition, and
performance analysis.
Web Components
The Web component approach treats services as
components in order to support basic software-
development principles such as reuse, specializa-
tion, and extension.
7
The main idea is to encapsu-
late composite-logic information inside a class
definition, which represents a Web component. A
Web component’s public interface can then be
published and used for discovery and reuse.
Composition logic comprises composition type
and message dependency. Composition type can
take two forms:
• Order determines whether a component can
execute constituent services sequentially or in
parallel.
• Alternative execution indicates whether a com-
ponent can invoke alternative services until
one succeeds.
Message dependency defines input and output
message mapping. There are three types of
dependency:
• Synthesis generates a composed service’s out-
put message by combining the output messages
of constituent services.
• Decomposition binds the composed service’s
input messages into the input messages of con-
stituent services.
• Message mapping allows custom mapping
between constituent services’ inputs and out-
puts.
The Web component approach supports several
basic composition constructs: sequential,
sequential alternative, parallel with result syn-
chronization, and parallel alternative. They are
augmented with condition and while-do con-
structs. A Web component class definition for
our example is
class BC is paraWithSyn{
public Msg BCInput, BCOutput;
public operation(Msg)->Msg;
private void compose(B.operation,
C.operation);
private void
messageDecomposition(BCInput, BInput,
CInput);
private void messageSynthesis(BOutput,
COutput, BCOutput);
}
class test us sequ {
public Msg processInput, processOut-
put;
public operation(Msg)->Msg;
private void compose(A.operation,
BC.operation);
private void messageDecomposition(pro-
cessInput, AInput);
private void messageSynthesis(proces-
sOutput, BCOutput);
private void messageMapping(AOutput,
BCInput);
}
We can specify a Web component in two isomor-
phic forms: a class definition and an XML specifi-
cation described in Service Composition Specifica-
tion Language. The SCSL specification consists of
the composite service’s interface and the composi-
tion logic. Composition logic is specified as follows
in SCSL for the class test (defined above):
<construct>
<composition type=“sequ”>
<activity name=“A”>
<input message=“AInput”/>
<output message=“AOutput”/>
<performedBy serviceProvider=“A”/>
</activity>
<activity name=“BC”>
<input message=“BCInput”/>
<output message=“BCOutput”/>
<performedBy serviceProvider=“BC”/>
</activity>
<messageHandling>
<messageDecomposition>
IEEE INTERNET COMPUTING www.computer.org/internet/ NOVEMBER • DECEMBER 2004 55
Web Services Composition
