Web Service Composition in UML
David Skogan, Roy Grønmo, Ida Solheim
SINTEF Information and Communication Technology, P.O.Box 124 Blindern, N-0314 Oslo, Norway
{david.skogan | roy.gronmo | ida.solheim}@sintef.no
Abstract
As the number of available web services is steadily
increasing, there is a growing interest for reusing basic
web services in new, composite web services. Several
organizations have proposed composition languages
(BPML, BPMN, BPEL4WS, BPSS, WSCI), but no winner
has been declared so far. This paper proposes a method
that uses UML Activity models to design web service
compositions, and OMG's Model Driven Architecture
(MDA) to generate executable specifications in different
composition languages. The method utilizes standard
UML constructs with a minimal set of extensions for web
services. An important step in the method is the
transformation of WSDL descriptions into UML. This
information is used to complete the composition models.
Another key aspect of the method is its independence of
the web service composition language. The user can thus
select his preferred composition language – and
execution engine – for realizing the composite web
service. Currently, the method has been implemented to
support two executable composition languages BPEL4WS
and WorkSCo, with corresponding execution engines.
WorkSco is a web service enabled workflow composition
language. The method is illustrated with an example from
a crisis management scenario.
1. Introduction
In the area of web service composition there is a need
for methods and techniques for federating basic web
services into composite web services in a more adaptable
manner than traditional programming. We will use the
term web service composition even though several other
terms used in the literature, e.g. web services
orchestration and choreography [1], business process
modeling or workflow modeling.
Many languages for web service compositions have
been proposed the past few years: BPML, WSCI, BPMN,
BPEL4WS, BPSS and XPDL to name but a few.
Unfortunately, no common standard has been agreed
upon. However, the main idea is that an execution engine
can be configured by a composition specification. The
benefit of such an approach is that the developer can
change the composition if new requirements or changes in
the basic web services occur, and then just execute the
specification.
Most of the proposed composition languages are
based on XML. An XML-based representation has its
advantages as a universal representation and exchange
format, but it can be difficult to understand and to write
for non-XML experts. A standard graphical modeling
language should be employed in combination with an
XML-based representation. Candidates for such a
language are BPMN or, as investigated in this paper, the
Unified Modeling Language (UML).
The leading organization for object-oriented
programming, the Object Management Group (OMG),
has defined the Unified Modeling Language (UML), a
standard graphical language for expressing system
development models. OMG also promotes a model-driven
architecture (MDA) approach towards analysis, design
and implementation. In model-driven development,
models are used to describe business concerns, user
requirements, information structures, components and
component interactions. These models govern the system
development in that they can be transformed into
executable code.
The work described in this paper adopts the MDA
strategy for web service compositions. We propose a
method, a UML profile and transformation rules that can
be used to produce UML models of web service
compositions that are executable. The central question
addressed is whether the UML can be used as an
integration platform for modeling executable web service
compositions. This implies the following requirements for
the resulting UML models:
1. They are sufficiently expressive for web service
composition;
2. They can be transformed to directly executable
composition specifications; and
3. They are independent of the executable
composition languages.
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE
A composition specification is directly executable if it
can be run by an execution engine. Hence, the UML
models produced will be indirectly executable if they can
be transformed to an executable composition
specification. We also define that a UML model is
independent of the executable composition language if
the same model can be transformed to more than one
executable composition language. The motivation is that
one does not want to be tied to a particular composition
language or execution engine, especially when there are
many competing standards. We have implemented
transformation rules that can transform the UML models
into two different executable composition languages. This
is done in the open-source UML Model Transformation
Tool (UMT) [2]. Hence, new composition languages or
changes to an existing language can be accommodated by
developing new transformation rules or by changing the
existing ones.
The paper is structured as follows. Section 2 describes
related work; Section 3 describes requirements for a web
service composition language; Section 4 gives an
overview of the method; Section 5 describes how the
method is applied on an emergency management
scenario; The UML profile and transformation rules are
given in Sections 6 and 7; Section 8 evaluates the
approach; and finally Section 9 concludes the paper.
2. Related Work
An objective in web service composition is to provide
a method for creating executable compositions. The basic
idea is that the composition can be expressed in a
composition language in the form of a model that can be
run by an execution engine. The first step to get started is
thus to select an existing execution engine with a
corresponding composition language. Unfortunately, this
is not as simple as it sounds. Many composition
languages have been proposed by different vendors. They
have varying properties, and their corresponding
execution engines are still at a prototype stage. Even if
execution engines are in their infancy, they have some
clear advantages compared to manual implementations,
e.g. they provide support for monitoring, persistence,
routing, and logging as well as a fault tolerant
environment. Advances in web service compositions are
done by two different communities: the Business Process
Management (BPM) community and the Workflow
community.
The BPM community has mainly focused on web
service technology and has come up with a multitude of
web service composition standards. The Business Process
Model Language [3] and the Business Process Model
Notation [4] are supported by the Business Process
Management Initiative (BPMI). Microsoft and IBM are
backing the Business Process Execution Language for
Web Services [5]. BPML and BPEL4WS are quite similar
[6] and are now being merged in OASIS. UN/CEFACT
promotes the Business Process Specification Schema [7].
Other proposals are HP's Web Service Conversation
Language (WSCL) [8] and SAP/Intalio/Sun/BEA's Web
Service Choreography Interface (WSCI) [9]. Of the above
proposals only the BPEL4WS is accompanied with
execution engines. Current implementations are IBM's
BPWS4J, Collaxa's BPEL Server, and Open Storm's
ChoreoServer.
The Workflow community has focused on established
technology which now is extended with web service
capabilities. They also support different forms of
composition languages. The Workflow Management
Coalition (WfMC) provides a specification for
interchange of composition models called the XML
Process Definition Language [10]. A number of
commercial execution engines are available, but their
support for XPDL and for invoking web services varies.
However, a strong candidate is the open-source WorkSCo
(Workflow with Separation of Concern) engine developed
by INESC-ID [11]. It has recently been extended with
web service capabilities and has an XML-based
composition language.
The various approaches to web service composition
have been investigated and criticized by several
stakeholders and research groups. Aalst [12] argues that
the current composition languages are not mature enough
to be applied. The question, what can be used instead, that
protects us from the shifting language situation, can be
answered by the UML for EDOC profile [13]. Here UML
activity models are recommended for composition
modeling. Dumas and Hofstede [14] have analyzed UML
activity models against the control flow patterns
identified by Aalst et al. [15], and have found that UML
can be used to express most of the patterns. Gardner [16]
describes a BPEL4WS-oriented UML profile that proves
that UML can be used to model and generate BPEL4WS.
See also White [17], which has done a comparison of
BPMN and UML.
Web services are usually described in the Web
Service Description Language (WSDL). We have in
previous work [18] shown that WSDL descriptions can be
generated from UML models, and that the reverse process
(UML reengineering from WSDL) is also feasible and
useful. Now, a reasonable continuation is to use UML
activity models for composition modeling. Thöne et al.
[19] shows how UML activity models can be transformed
into a proprietary execution language. In this work we
continue the work on web service composition presented
by Grønmo and Solheim [20].
To summarize, there are many composition language
proposals. None of them are mature enough to be used as
a de-facto web service composition standard. Therefore
we introduce a web service composition language in
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE
UML which can be transformed into several execution
languages. None of the previous UML composition
modeling efforts has been proven to be independent of
execution language.
3. Web Service Composition Requirements
This section proposes a minimal set of requirements
for web service composition. The five basic control flow
patterns described by Aalst in [12] shall be supported.
These control flow patterns, which are supported by most
composition languages, are called sequence, parallel split,
synchronization, exclusive choice and simple merge.
Sequence gives the ability to execute activities in order,
one after the other. Parallel split is used for execution of
two or more execution paths in simultaneous threads.
Synchronization joins two or more parallel execution
paths by waiting for all these paths to finish before flow
continues. Exclusive choice is used when one wants to
continue the execution flow in only one path among two
ore more alternatives. Simple merge will only wait for the
first out of many execution paths to finish, before flow
continues.
Two additional control flow patterns, Discriminator
and Selector (both described by Hamadi et al. in [21]), are
considered important for web service composition and
shall also be supported. Discriminator is useful when
there are two or more web services that may perform the
same task. Execution is started in parallel, the answer
from the first one to finish is used and the rest of the
answers are ignored. This is particularly important when
composing web services, since some of the services may
temporarily be unreachable due to network or server
problems. Selector is a pattern that can choose among a
set of services performing the same task. Which service to
execute depends on the selection criteria, which may be
applied in both design-time and run-time. Further details
on how to use quality-of-service parameters to realize the
Selector pattern, are given by Zeng et al. in [22].
Adaptable web service compositions are achieved by
using the Discriminator and Selector pattern.
Another requirement is the capability to provide
enough information to execute both web services and
non-web services (e.g. Java object).
When reusing third-party web services, the input and
output parameter types are given. In order to use the
output from one web service as input to another web
service, it is often necessary to perform a data
transformation. A simple data transformation is to copy
one part of the source object into another part of the target
object. In less trivial cases, information from two or more
source objects must be gathered and processed in order to
produce a new object.
4. Web Service Composition Method
The guiding principle for this method is to use UML
to model service compositions, and from the UML
models, to automatically generate the execution code and
WSDL specifications. Since existing web services are
needed in compositions, their WSDL specifications
should be reengineered into UML models for subsequent
integration in new, composite service models. Thence,
UML is used as the integration platform, independently of
the selected execution engine.
Before delving into the method design, it may be
useful to explain some central concepts. A web service
typically consists of several operations, as illustrated by
the UML class model in the left-hand side of Figure 1.
Each operation can have its internal behavior expressed in
a UML activity model, as depicted in the right-hand side
of Figure 1. The activity model prescribes how to
implement the operation, namely by a structured set of
activities called a composition, which defines the control
flow of the activities and how the objects flow among the
activities. An activity corresponds to the invocation of a
web service operation or an internal procedure. Each
activity has input and output parameters, which may be
Activities of operation2
Web service A
operation1()
operation2()
operation3()
Figure 1: Service and operations
data objects or messages. A composite web service has
one or more operations which invoke other (basic) web
services.
The web service composition method is described
below and illustrated in Figure 2. Steps 1—4 refer to the
corresponding compartments of the figure.
Step 1: The goal of the first step is to create a
preliminary model of the new web service, and identify
candidate web services for the activities in the
compositions. The preliminary model consists of two
submodels, i.e. the interface of the web service and the
compositions of each of the operations of the service. The
interface model shall describe the operations signatures of
the web service in the form of a UML class diagram. The
compositions suggest how the new operations should be
composed, by means of a UML activity model. The
composition model is a functional decomposition of the
main task identified by the operation. The resulting
composition model consists of smaller, manageable
services that are more likely to be found as existing web
services than the more complex service operation. QoS
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE
Step 1
UML model of
new service
interface
Transform
WDSL to UML
UML model of
new service
interface
UML models of
basic services
Sketch of
operation
to be
composed
Search and
discover
Step 4
Step 3
Step 2
Model new
composition,
adding details
found in WSDL
Transform
UML model
to WSDL
Transform
UML model to
XML document
Executable
spec. (XML)
WSDL spec. of
new service
Publish
Input
Use as
input to
Web service
registry
Web service
registry
Extract
WSDL
service
spec.
Deploy
Output
Detailed service
composition
Execution
engine
Deploy
Internet
server
Web
service
consumers
Figure 2: Method overview
requirements, such as execution time, cost and quality of
result, may be part of this composition model [23]. This
preliminary model is the basis for searching registries
(e.g. UDDI) for candidate web services. Ideally, the
searching tool considers the QoS requirements so that
only appropriate services are returned. Web services are
identified by their names and textual descriptions in the
registry, but their operation signatures are described in
WSDL. The modeler need to assess the candidates and
select the basic services to be used in the new
composition. He/she will then extract their WSDL
specifications which are used in the next step.
Step 2: The goal of the second step is to model the
details of the compositions in UML activity models. The
starting point is the result from step 1 – the WSDL
descriptions of the candidate services. The modeler
transforms the WSDL specifications to UML to identify
the actual operations to use. A suggested approach for this
automatic transformation is described by Grønmo et al. in
[18]. Information from the WSDL models, which
includes operation signatures with input and output
messages, should be reused and provided as tagged values
according to the UML profile (Section 6), in the activity
model. Appropriate control flows are modeled. Data
flows and associated data transformations are then added
to link the different activities together. The data
transformations are necessary when the output of one web
service does not match the input of the next web service.
It may become necessary to iterate step 2 several times to
obtain an adequate service composition.
Step 3: The goal of the third step is to configure the
execution engine to run the new operation. The engine
runs according to an executable specification. This
specification should align totally with the activity model
resulting from step 2. Therefore, the modeler transforms
the activity model to an XML document serving as input
to the execution engine. This transformation is done
automatically by a transformation tool such as the one
described in section 7.
Step 4: In this step, the modeler makes the new
service ready for deployment. Firstly, the interface model
of the new, composite service must be completed. Then,
the corresponding WSDL specification is automatically
generated [18]. Lastly, when the new service has been
published in an appropriate registry, it can be discovered
and used by web service consumers.
5. A Worked Example
This section presents an example of web service
composition in UML, according to the method described
above. The case is an emergency situation [24] caused by
an explosion in a chemical factory, with subsequent
leakage of poisonous gas. In order to make efficient
evacuation plans, the crisis management needs a forecast
of the gas plume dispersion. Hence a web service need to
be designed which calculates the plume and displays it on
a map. The design and implementation of this service
should of course be done before the need arises,
supplying the service ready at hand when needed.
First, the modeler has to design the new web service's
interface including its operations' signatures. The UML
class diagram in Figure 3 depicts the web service with the
one operation needed in the example. The createGas-
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE
GasDispersionWebService
+createGasDispersionMap( plantID : string, emissionRate : float ) : imageMap
Figure 4: A web service interface model
DispersionMap operation takes a plant ID and an
emission rate as input, and returns a raster image
depicting the gas plume on a map.
The next thing to do is to sketch the operation's
activities in a UML activity model, see Figure 4. This can
be done by creating a functional decomposition of the
operation. In order to create a gas dispersion map, one
first needs to know the location of the factory (Get Plant
Location). Then the weather at this location should be
found (Get Weather). The next activity is the Calculate
Gas Dispersion Plume activity. It takes the gas emission
rate, the wind direction and wind strength, and the
location of the plant as input and calculates a plume
Get Plant Location
Get Weather
Calculate Gas Dispersion Plume
Create Gas Dispersion Map
Figure 3: A preliminary composition
polygon. Finally the Create Gas Dispersion Map portrays
the plume polygon on top of a background map and
returns the map image.
With this preliminary activity model in mind, the
modeler searches web service registries for existing web
services that can perform the operations modeled in by
the different activities. Each registered service has a
textual presentation, and an associated WDSL
specification. On the basis of the textual description, the
modeler decides whether the service is a good candidate.
If so, he/she extracts its WDSL description to use in the
next step. (This ends step 1 of the method.)
When using UML as integration platform, all models
have to be expressed in UML. So, the modeler transforms
the WDSL descriptions of basic services into UML class
models using UMT [2] to inspect their operation names,
signatures and message types. An example of a web
service which provides weather information is portrayed
in Figure 5. The service is provided by CapeScience and
it provides a number of operations. The getWind
operation is a candidate for solving the Get Weather
activity. Two levels of details are shown in the figure.
The AirportWeather class shows the operations with
traditional operation signatures. WSDL requires that an
operation takes only one input message and returns one
output message. Hence the figure shows the input and
output messages for the getWind operation, called
getWind and getWindResponse. Notice that the semantics
of the getWind operation can be difficult to understand.
The arg0 input parameter requires a 4 character
international airport code.
Now, the modeler can start designing the real
composition, doing as follows: (1) For each activity in the
activity model select candidate web services and decide
on the basic operation, transfer its name and I/O
parameters to a web service call activity in the activity
model. Relevant WDSL information will then appear as
stereotypes and tagged values in the activity model, and
the input and output messages will appear as data objects.
If more than one web service can perform the operation in
an activity this should be modeled as alternative service
providers. (2) For the activities where no relevant web
services are found design and implement appropriate
operations and establish it either in a new web service, or
as a procedure internal to the composition. (3) The
discovered web services will often differ slightly from the
planned service with respect to the input and output data
objects. In order to be used in the composition so that the
output produced from one service can be consumed by
the next service, it is necessary to define a number of data
mappings.
The composition modeling may require several
iterations, where new activities are identified. Figure 6
shows the complete activity model, with all I/O and
WSDL details added for both existing and new service
operations. Some details are removed from the figure.
Notice that the final model has several new activities
compared to the preliminary model. The first activity now
is a web service call activity which returns the
coordinates of the plant based on the plant ID. The Get
Nearest Airport activity is new. This because no service
<<BusinessService>>
AirportWeather
+getHumidity()
+getLocation()
+getPressure()
+getSkyConditions()
+getSummary()
+getTemperature()
+getVisibility()
+getWind( arg0 : string ) : string
getWind
+arg0 : string
getWindResponse
+return : string
Figure 5: UML model generated from WSDL
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE
was found that could return the weather at an arbitrary
location. However a service that gave the weather at
airports around the world, given the international airport
code as input, was found. Thus we needed an activity that
could give us the nearest airport. Two such services were
implemented: one provided by e-blana that gave the
nearest airport based on the plant ID, and one provided by
Ionicsoft that returned the nearest airport based on the
plant's location. The two services are modeled as
alternative service providers using the discriminator
pattern. Hence the services are invoked in parallel and the
first value returned is used in the next activity. A possible
extension of this selection algorithm is to define QoS
selection criterias in the model that can be used by a
broker in run-time to select the “best” service [22].
Unfortunately the weather service from CapeScience did
leakageDetails : LeakageInformation
<<transformation>>
plantId = plantID;
<<transformation>>
PlantID = plantID;
XCooriate := 0;
YCooriate := 0;
plantID : GetPlantLocationSoapIn
<<WebServiceCall>>
Get Plant Location
{provider=e-blana,
wsdl=http://acegis.e-blana.com/PreEmergencyPlanService/PreEmergencyPlanService.asmx?WSDL,
operation=GetPlantLocation,
service=PreEmergencyPlanService,
portType=PreEmergencyPlanServiceSoap}
coordinates : GetPlantLocationSoapOut
pp : point_and_plantId
<<transformation>>
point.x = xCoordinate
point.y = yCoordinate
<<AlternativeServiceProviders>>
Get Nearest Airport
<<WebServiceCall>>
LocateNearestAirport
{provider=e-blana}
<<transformation>>
emissionRate = emissionRate;
<<WebServiceCall>>
GetNearestAirportCode
{provider=IONIC}
airportCode1 : airportCode
airportCodeInfo : getWind
<<WebServiceCall>>
Get Wind Information
{provider=CapeScience,
operation=getWind}
<<transformation>>
origin = point;
<<ImediateStep>>
Parse the wind information
{domainObject=ParseWindInformation}
<<WebServiceCall>>
Calculate Gas Dispersion Plume
<<transformation>>
arg0 = icao;
windStr : getWindResponse
windInformation : windInformation
<<transformation>>
windSpeed = speed;
windDirection = toDirection;
plumeInfo : calculatePlumeRequest
plumeLayer : calculatePlumeResponse
<<WebServiceCall>>
Create Gas Dispersion Map
plume : createGasDispersionMapRequest
dispersionMap : createGasDispersionMapResponse
Figure 6: Complete composition
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE
<<transformation>>
plumeGML = calculatePlumeReturn;
not return a structured data type, but gave the information
in a natural language string. This forced us to implement
an activity to parse the weather string information. The
final two services were provided by Ionicsoft [25]. (This
ends step 2 of the method.)
The final activity model is shown in Figure 6. It is
complete with respect to data flow and web service
details. The tagged values of the activities indicate the
selected web service and operation. These values can be
imported directly from the reverse engineered UML
models of the services’ WSDL documents. The activity
model is transformed to an executable specification – an
XML document. This is done utilizing UMT [2]. (This
ends step 3 of the method.)
The new service is now ready to be published in an
appropriate registry, for the benefit of end users. Such
publication requires a WSDL description of the web
service. Therefore, the modeler completes the service
interface model and transforms it automatically to a
corresponding WSDL description. After being published,
the service may be invoked and run on the execution
engine for which it has been configured. The service can
finally be made available to web service consumers. (This
ends step 4.)
6. UML Profile
The UML profile is based on UML version 1.4
activity modeling. Some constructions are built-in, while
others are stereotype or tagged value extensions. This
profile is a minimal set of UML constructs to fulfill the
web service composition requirements.
The built-in support for object flow, and for the five
basic control patterns (sequence, fork, join, choice and
merge) are part of the profile. To represent a web service
operation, activities are stereotyped WebServiceCall. A
web service activity has a set of tagged values. The
provider of the web service is defined by the tagged value
provider. The URL to the WSDL file is registered in the
tagged value wsdl. The exact service operation to invoke
is given by the three tagged values service, portType and
operation. The registration of these tagged values is a
manual task that requires careful attention so that the
values become equivalent to those in the WSDL file and
the imported UML class model. A possible improvement
could be UML tool support for pick-and-choose the
appropriate values from the reverse-engineered WSDL
UML model. Also, the textual tagged values could be
links or references so as to ensure there is correspondence
with other UML elements, which is not supported by the
current UML version. Non-web-service activities that
invoke automatic operations are stereotyped as
ImmediateStep with a tagged value called domainObject
that indicates the internal operation to call.
Data transformations are handled by a note attached to
the object flow with stereotype transformation. The
expression in the note defines the transformation needed.
More complex data transformations can be modeled as
activities
stereotyped
DataTransformation.
The
stereotype AlternativeServiceProviders indicates a special
kind of control flow that is needed in the gas dispersion
case. There will be several sub activities inside an
AlternativeServiceProviders activity. It realize the
Discriminator pattern and/or the Selector pattern
described by Hamadi et al. in [21] to select among several
web services capable of performing the same task.
7. Transformation Rules
This section describes transformation rules from UML
activity models to the two composition languages,
WorkSCo [26] and BPEL4WS [5]. WorkSCo is a
traditional composition language which has been
extended to support web services. BPEL4WS is a
composition language focusing on web services. Both
these languages have their own execution engine. The
two composition languages provide slightly different
constructions for defining the structure of a composition.
BPEL4WS provides constructions for defining the
partners in a composition, and for receiving, invoking and
replying to web service calls. It has constructions for
assigning and manipulating variables to manage the data
flow, and for controlling the order in which the web
service invocations are done, i.e., in parallel or in
sequence. On the other hand, WorkSCo defines constructs
for structuring and invoking generic activities. A special
kind of activity is the invocation of a web service
operation. It further has constructs for organizing data
flow among activities and for controlling parallel and
sequential execution of activities.
The transformation rules are illustrated in Figure 7.
Due to limited space we will only provide an overview
and will not go into the details of the transformation rules.
The details are given by Grønmo et al. in [27]. The
middle part of the figure shows the last two activities of
the gas dispersion UML model, Calculate Gas Dispersion
Plume and Create Gas Dispersion Map. Arrows are
drawn from the UML model to the corresponding
WorkSCo document on the left side and to the
corresponding BPEL4WS document on the right side.
The XML instances are simplified for clarity by leaving
out a few elements and attributes as well as removing all
the XML namespace information.
The UML web service activity, Calculate Gas
Dispersion Plume, is mapped to a BPEL4WS invoke and
WorkSCo WebServiceProcedure. The activity will also
result in a BPEL4WS partnerLink. The activity has
plumeInfo as input data object and is transformed to
BPEL4WS inputVariable attribute of the corresponding
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE
WorkSCo
DL
fi
W
flow
plumeLayer : calculatePlumeResponse
Tra
nsfo
rma
tion
<<transformation>>
plumeGML = calculatePlumeReturn;
Tra
plume : createGasDispersionMapRequest
ns
f or
ma
tio
n
<<WebServiceCall>>
al
fin
t
ou
t
pu
<WebServiceProcedure id="step2"
name="Create Gas Dispersion Map"
operationName="createGasDispersionMap“…/>
low
ll
Ca
Web
Serv
ic
Sequ
ence
f
ce
rvi
Se
eb
<WebServiceProcedure id="step1"
name="Calculate Gas Dispersion Plume"
operationName="calculatePlume"
wsdlLocation="CalculateGasDispersionPlume.wsdl>
<Input message="calculatePlumeRequest"
name="plumeInfo"/>
<Output message="calculatePlumeResponse“
name="plumeLayer"/>
</WebServiceProcedure>
W
eCall
Sequ
e
t
<<WebServiceCall>>
Calculate Gas Dispersion Plume
{provider=IONIC,
wsdl=CalculateGasDispersionPlume.wsdl,
operation=calculatePlume,
service=CalculateGasDispersionPlumeService,
portType=CalculateGasDispersionPlume}
<SequenceProcedure>
nce
<Output
message="createGasDispersionMapResponse"
name="dispersionMap"/>
<DataLink sourceProcedure="step1"
targetProcedure="step2">
<Map sourceMessage="plumeLayer"
sourcePart="calculatePlumeReturn"
targetMessage="plume"
targetPart="plumeGML"/>
</DataLink>
le
ob
jec
eb
Se
r
WS
ta
da
Create Gas Dispersion Map
{provider=IONIC,
operation=createGasDispersionMap,
wsdl=CreateGasDispersionMap.wsdl,
service=CreateGasDispersionMapService,
portType=CreateGasDispersionMap}
ct
ta obje
tput da
final ou
t
jec
ob
<partnerLinks>
<partnerLink
name="IONIC-calculatePlume" .../>
<partnerLink
name="IONICcreateGasDispersionMap".../>
</partnerLinks>
<variables>
<variable name="plumeLayer" .../>
<variable name="dispersionMap" .../>
<variable name="plumeInfo“
messageType="calculatePlumeRequest"/>
<variable name="plume" .../>
</variables>
<sequence>
<invoke partner="IONIC-calculatePlume"
portType="CalculateGasDispersionPlume"
operation="calculatePlume“
inputVariable="plumeInfo“
outputVariable="plumeLayer"/>
</invoke>
<assign>
<copy>
<from variable="plumeLayer“
part="calculatePlumeReturn"/>
<to variable="plume" part="plumeGML"/>
</copy>
</assign>
<invoke operation="createGasDispersionMap“
...</invoke>
<reply partner=“IONIC-reply"
portType="CalculateGasDispersionPlume"
operation="calculatePlume“
variable=“dispersionMap“/>
</sequence>
vic
eC
all
da
ta
<DataTypes
location="CalculateGasDispersionPlume.wsdl"/>
<DataTypes
location="CreateGasDispersionMap.wsdl"/>
</SequenceProcedure>
BPEL4WS 1.1
plumeInfo : calculatePlumeRequest
dispersionMap : createGasDispersionMapResponse
Figure 7: Conversion from UML to WorkSCo and BPEL4WS
invoke element. plumeInfo is also defined in BPEL4WS
as a variable. In WorkSCo plumeInfo needs only to be
defined as an Input part element of the corresponding
WebServiceProcedure. The output data object,
plumeLayer, becomes a BPEL4WS outputVariable and a
WorkSCo Output. The UML tagged value wsdl, which
refers to a WSDL file in the web service activity, is
defined as an external data type definition in WorkSCo by
the DataTypes element. Several tagged values of the
activity (service, portType and operation) refers to
definitions within the WSDL file and these are mapped to
equivalent attributes within the BPEL4WS invoke and
WorkSCo WebServiceCall.
The sequence flow between the two activities is
equivalent to BPEL4WS sequence and WorkSCo
SequenceProcedure. The data transformation, attached to
the object flow from plumeLayer to plume, results in
BPEL4WS assign and WorkSCo DataLink. Both these
constructions are capable of copying parts of the source
object into parts of the target object.
The complete web service composition represents a
new web service operation with its own input data objects
and output data object. The final output data object in the
figure is represented by the UML data object
dispersionMap. The corresponding constructions are
BPEL4WS reply and WorkSCo global Output. The
initial input of the composite web service operation is
mapped to BPEL4WS receive and WorkSCo global Input.
Figure 7 does not show the initial input since it only
shows the two final steps of the gas dispersion model.
All the transformation rules described above are
implemented within the open-source licensed UML
Model Transformation tool (UMT) [2]. XSLT is used as
the transformation language to transform from XMIbased [28] representation of the UML model into the
composition languages. An extract of the XSLT code is
shown in Figure 8 that generates BPEL4WS from a UML
web service activity. An XSLT template rule applies to all
UML activities. Within this template there are different
branches coded by xsl:when statements to implement
different transformation rules based on the activity
stereotype. In the branch for web service activity it is
checked if there are any transformations on the input data
specified in the UML model. If so, equivalent BPEL4WS
transformations are produced within the XSLT function
genDataTransformations. Then a BPEL4WS invoke
element is produced. The invoke will be assigned
inputVariable and outputVariable attributes by the XSLT
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE
<xsl:template match="Activity">
...
<xsl:when test="@stereoType = 'WebService' or @stereoType='WebServiceCall'">
<xsl:variable name="operation" select="taggedValue[@tag='operation']/@value"/>
<xsl:variable name="portType" select="taggedValue[@tag='portType']/@value"/>
<xsl:call-template name="genDataTransformations"/>
<!-- Output BPEL4WS invoke tag corresponding to a UML WebServiceCall Activity -->
<invoke portType="{$portType}" operation="{$operation}">
<!-- Setting inputVariable/outputVariable -->
<xsl:call-template name="inputOutputDataObjects"/>
</invoke>
</xsl:when>
...
</xsl:template>
Figure 8: XSLT extract transforming from UML to BPEL4WS
function inputOutputDataObjects. These attributes
correspond to input and output data objects specified in
the UML model.
Any UML activity model conforming to the UML
profile of this paper can be automatically transformed to a
WorkSCo document or a BPEL4WS document by UMT.
Such a document can then be used to configure the
corresponding execution engine.
8. Evaluation
We have developed and tested a method for designing
and deploying web service compositions. The goal of the
method is to design web service compositions in a
detailed UML activity model. The requirements for such
a UML model are that it is sufficiently expressive for web
service composition; that it can be transformed to an
executable composition specification; and that it is
independent of the executable composition language. The
method is supported by a UML profile and two set of
transformation rules for generating executable
compositions. In this section we first evaluate the UML
profile against the expressiveness requirement, and then
evaluate the transformation rules against the
transformation and independence requirements.
We claim that the UML profile fulfills the
expressiveness requirement because it is powerful enough
to satisfy the web service composition requirements
described in Section 3. The 5 basic patterns, sequence,
parallel split, synchronization, exclusive choice and
simple merge, are all supported by standard UML activity
constructs. The WebServiceCall activity is capable of
invoking an operation in a web service. The select and
discriminator patterns are supported by the AlternativeServiceProviders activity. Simple data transformations
are supported by transformation notes on the object flows
and more complex data transformations can be supported
by DataTransformation activities. Thus, UML models
that adhere to the UML profile and which are annotated
with correct WSDL information can therefore be said to
be sufficiently expressive.
Transformation rules have been designed and
implemented in UMT [2], which currently supports
generation of WorkSCo and BPEL4WS documents. Both
execution languages support the five basic control
patterns, object flow and simple data transformations.
However, none of the execution languages supports the
full concept of the AlternativeServiceProviders activity,
although the discriminator part of it has been
implemented by WorkSCo. BPEL4WS and WorkSCo
handle simple copying of parts from the source into parts
of the target as well as assigning fixed expressions. This
covers all the current needs in the gas dispersion case. To
handle more complex DataTransformation activities,
WorkSCo allows calls to transformation routines written
in Java, whereas BPEL4WS requires the same routine
wrapped and deployed as a separate web service.
The gas dispersion model has been executed
successfully in the WorkSCo engine. Unfortunately, we
were not able to run the BPEL4WS document on IBM's
BPWS4J engine. The engine validated the BPEL4WS
document, but ran into problems reading one of the
external WSDL files. Still, we claim that the
transformation rules can produce valid WorkSco and
BPEL4WS documents and that the generated WorkSCo
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE
document is executable. Whether the generated
BPEL4WS document is executable remains to be seen in
future work.
The gas dispersion model is independent of execution
language in that it can be transformed into two different
composition languages. It is expected that transformation
rules to other executable composition languages can be
developed if the need arises.
We also claim that the graphical UML models are
more readable than corresponding XML composition
languages. An important difference is the model's explicit
visualization of control and data flows; features which
must be inferred by referential identifiers in the XML
document.
Composable E-commerce and Geographic information
Services), http://www.acegis.net/.
We want to thank the reviewers for valuable and
comments.
References
[1]
[2]
[3]
[4]
9. Conclusion
[5]
This paper's main contribution is a UML-based
model-driven method for web service composition. It has
shown how composite web service models can be
transformed into executable models by the means of
model transformations. An important feature of the
method is the ability to import descriptions of existing
web services into UML diagrams by means of WSDL.
This feature allows the use of UML as a common
integration platform. Further, the paper presents a UML
profile and guidelines for modeling composite web
services in UML activity models.
By using the method on the gas dispersion case one
has proven its applicability to developing real-life web
service compositions. Our method also provides better
documentation of the composition in the form of
graphical models. The ability to generate executable
compositions from a graphical model represents a
valuable gain to the service developers, who otherwise
has to write a lot of low-level XML code.
Future improvements of the method may integrate
QoS and semantic issues. QoS requirements could be
attached to the composition as a whole. This requirement
may then be used in the discovery process to find a set of
services that all together satisfy the QoS requirement of
the complete composition [23]. Also a run-time QoS
broker may be used to optimize the predefined QoS
selection criterias. Together with ontologies and semantic
definitions attached to the WSDL-described web services
[29], it may allow for dynamic run-time choice of the
services to be invoked for fulfilling the whole web service
composition.
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
Acknowledgements
[17]
This work has been partially funded by the European
IST-2001-37724 project ACE-GIS: (Adaptable and
[18]
C.
Peltz,
"Web
Services
Orchestration
and
Choreography," in Computer, vol. 36, 2003, pp. 46-52.
SINTEF, "UML Model Transformation tool (UMT)," 0.8
ed: SINTEF ICT, 2004.
BPML, "Business Process Modeling Language (BPML),"
vol. 2004: Business Process Management Initiative
(BPMI), 2002.
BPMN, "Business Process Modeling Notation (BPMN),"
vol. 2004, Working Draft (1.0) ed: Busines Process
Management Initiative (BPMI), 2003.
BPEL4WS, "Business Process Execution Language for
Web Services Version 1.1," IBM developerWorks, 2003.
J. Mendling and M. Müller, "A Comparison of BPML and
BPEL4WS," presented at Berliner XML Tage 2003,
Berlin, 2003.
BPSS, "ebXML Business Process Specification Schema,"
vol. 2004, Version 1.01 ed: ebXML, 2001.
W3C, "Web Services Conversation Language," vol. 2004:
W3C Note, 2002.
W3C, "Web Service Coreography Interface (WSCI)," vol.
2003: W3C Note, 2002.
XPDL, "XML Process Definition Language (XPDL),"
vol. 2004, Version 1.0 - Final Draft ed: Workflow
Management Coalition (WfMC), 2002.
S. Fernandes, J. Cachopo, and A. Rito-Silva, "Suporting
Evolution in Workflow Definition Languages," presented
at 30th Conference on Current trends in Theory and
Practice of Computer Science (SOFSEM 2004), Merin,
Czech Republic, 2004.
W. M. P. v. d. Aalst, "Don't go with the flow: Web
Services composition standards exposed," in IEEE
Intelligent Systems, vol. 18, 2003, pp. 72-76.
OMG, "UML Profile for Enterprise Distributed Object
Computing Specification," vol. 2004, ptc/02-02-05 ed:
Object Management Group, 2002.
M. Dumas and A. H. M. t. Hofstede, "UML Activity
Diagrams as a Workflow Specification Language,"
presented at UML 2001 - The Unified Modeling
Language, Modeling Languages, Concepts, and Tools, 4th
International Conference, Toronto, Ontario, Canada, 2001.
W. M. P. v. d. Aalst, A. H. M. t. Hofstede, B.
Kipuszewski, and A. P. Barros, "Workflow Patterns,"
Distributed and Parallel Databases, vol. 14, pp. 5-51,
2003.
T. Gardner, "UML Modelling of Automated Business
Processes with a Mapping to BPEL4WS," presented at
17th European Conference on Object-Oriented
Programming (ECOOP), Darmstadt, Germany, 2003.
S. A. White, "Process Modeling Notations and Workflow
Patterns," in The Workflow Handbook 2004, L. Fischer,
Ed.: Future Strategies Inc., 2004.
R. Grønmo, D. Skogan, I. Solheim, and J. Oldevik,
"Model-driven Web Services Development," presented at
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
The 2004 IEEE International Conference on eTechnology, e-Commerce and e-Service (EEE-04),,
Taipei, Taiwan, 2004.
S. Thöne, R. Depke, and G. Engels, "Process-Oriented,
Flexible Composition of Web Services with UML,"
presented at Int. Workshop on Conceptual Modeling
Approaches for e-Business: A Web Service Perspective
(eCOMO 2002), Tampere, Finland, 2002.
R. Grønmo and I. Solheim, "Towards Modeling Web
Service Composition in UML," presented at The 2nd
International Workshop on Web Services: Modeling,
Architecture and Infrastructure (WSMAI-2004), Porto,
Portugal, 2004.
R. Hamadi and B. Benatallah, "A Petri Net-based Model
for Web Service Composition," presented at Database
Technologies 2003, 14th Australian Database Conference
(ADC 2003), Adelaide, South Australia, 2003.
L. Zeng, B. Benatallah, M. Dumas, J. Kalagnanam, and Q.
Z. Sheng, "Quality Driven Web Services Composition,"
presented at World Wide Web Conference (WWW2003)),
Budapest, Hungary, 2003.
M. C. Jaeger, G. Rojec-Goldman, and G. Muehl, "QoS
Aggregation for Web Service Composition using
Workflow Patterns," presented at The 8th International
IEEE Enterprise Distributed Object Computing
Conference (EDOC 2004), Monterey, California, 2004.
I. Walsh, P. McCarthy, and J. Shields, "e-Emergency Pilot
Demonstrator," e-blana, Deliverable IST-2001-37724
ACE-GIS D1.2b, November 2003.
S. Rondal, "Updated GI Services with Composition
Support," Ionicsoft, Deliverable IST-2001-37724 ACEGIS D2.2, November 2003.
A. Rito-Silva, S. Fernandes, J. Martins, and D. Domingos,
"Micro-workflow component framework supporting
service composition," INESC-ID, Deliverable IST-200137724 ACE-GIS D4.2, November 2003.
R. Grønmo and D. Skogan, "Model-driven Service
Composition," SINTEF ICT, Deliverable IST-2001-37724
ACE-GIS D5.2, November 2004.
OMG, "XML Metadata Interchange (XMI) Version 1.2,"
Object Management Group OMG Document formal/0201-01, January 2002 2002.
F. Probst and M. Lutz, "Giving Meaning to GI Web
Service Descriptions", presented at The 2nd International
Workshop on Web Services: Modeling, Architecture and
Infrastructure (WSMAI-2004), Porto, Portugal, 2004.
Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004)
1541-7719/04 $20.00 © 2004 IEEE