You are on page 1of 11

A BPEL Engine and Editor for the .

NET framework
Matthew Buckle1, Charlie Abela1, Matthew Montebello1
Department of Computer Science and AI, University of Malta,,

Abstract. In today's world of extreme competition, information exchange and

efficient communication is the need of the day. This need for information
exchange brings in another need, that which makes information selectively
visible, and its visibility to be changed on the fly. Web Services are a new
breed of web application and play a central role in the WWW, providing the
above-mentioned requirements. The composition of these services enables
application integration within and across organizational boundaries. The
Business Process Execution Language (BPEL) is intended to enable portable
business process definitions for WSDL based services. In this paper we
describe the work done on a BPEL execution engine and editor developed for
the .NET framework. We also describe how a graphical representation based on
UML activity diagrams was used to visualise service compositions and how this
can be adopted as the underlying model for Semantic Web service descriptions
such as OWL-S.

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. Nowadays, web services can communicate with each
other, advertise themselves, be discovered and invoked using industry - wide
specifications. 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
When viewed as a stand-alone entity, web services provide the required
computation for some specific service by hiding any technical details from the client
and allow its use over different systems. Substantial progress has already been
achieved to enable rich, flexible and dynamic interoperation of highly distributed and
heterogeneous web services. A number of process composition languages have
already been developed to cater for the need of integrating different web services.
Languages such as XLANG[2], WSFL[3], WSCI[4], OWL-S[5] and BPEL[1] are
compared and contrasted in [12]
The Business Process Execution Language for Web Services (BPEL for short) is
the result of the merge of WSFL from IBM and XLANG from Microsoft. BPEL4WS
provides a balance between both WSFL (support for graph oriented processes) and

XLANG (structural constructs for processes) into a package that supports the
implementation of any kind of business process, together with composition of existing
web services. BPEL is an XML based scripting language intended to enable portable
business process definitions for WSDL[6] based business processes. An engine for
this scripting language already exists and runs over a Java enabled web server.
In this paper we provide an alternative BPEL engine that runs over the .NET
framework, in which processes comprising the composition of existing web services
can be created, deployed and used by customers as a new web service. In order to
facilitate the use of this language, a visual editor is also being developed so as to
allow the user to:
Create a BPEL process without exposing details of the markup used by
the language.
Use some standard diagramming technique to specify composition of
existing web services for the process being created.
Have the specified process diagram automatically generating the
corresponding markup for the language.
Edit the generated markup if more expressiveness to the process needs to
be added.

Most of the effort was dedicated to the development of the engine, however,
keeping a balance between the load of work required to implement the editor. The
Engine provides the underlying platform that allows the execution of BPEL
processes. This consists of an API that implements the constructs provided by the
BPEL specification. Together with other components, the engine allows the users to
create, verify and deploy new web services. The figure below gives an overview of
the runtime environment for BPEL processes.

Service 1

Set of WSDL files of
external Web


WSDL(Service 1)
. 2
Service n

WSDL(Service 2)

BPEL process file

Fig. 1. Runtime environment overview

BPEL Engine

BPEL process
(composition of
Web Services )

The Visual editor, as the name denotes, allows the inexperienced user to easily
create and edit BPEL processes through the use of UML[7] activity diagrams. The
editor generates the corresponding BPEL markup from the given diagram. Users can
also view the generated syntax at any point of the construction of the diagram, given
that the provided diagram has a valid context.
The idea of mapping UML activity diagrams to BPEL originated from the work
done by James Scicluna [10]. His thesis consisted of a tool that would allow
inexperienced users to easily create an OWL-S description of a web service.
Specifically, the tool consisted of a visual composer that allows the user to build a
process ontology through the use of a standard diagramming technique, namely UML
activity diagrams.
The main reason of creating a BPEL editor that uses UML activity diagrams to
build a process visually is that of having an underlying framework that implicitly
provides a mapping between BPEL and OWL-S constructs. The aim is to show that
these markup languages can be, perhaps in the near future, combined to have a
language that provides both a potential expressiveness with regards to service
composition together with a means of semantically describing the process and
allowing dynamic discovery of other processes.

The engine provides the run-time environment for BPEL processes. This consists
of a library that implements the constructs that are required to describe a process, as
specified by the BPEL 1.1 specification. The library is based on a factorymechanism, exposing only an interface of each class representing a construct and
hiding any other underlying technical details. This is similar to the way BPWS4J
allows the creation of BPEL processes.
A process is then created through a BPEL source file and its WSDL description,
together with any additional WSDL documents of any partner services that the
process might use throughout its execution. These files are fed to the Deployer
component that validates the syntax of the provided files, generates a respective
process out of the API and makes the process available to its clients in the form of a
SOAP web service. The processes are stored as object data files on disk and are
loaded once upon startup of the engine and are kept in memory throughout the
engines lifetime.
After deployment, a process is ready to serve its clients. However, the process by
itself is not actually a web service. Technically speaking, the only web service is the
engine. It is the only entity that handles all the incoming messages from the clients.
The engine, together with the ProcessManager component, examines the messages
received from the clients and routes them to a new or an existing instance of a
process, depending on the message context. Thus, the engine upon receiving a
message from a client physically starts a process. Creation of the process can be done
either manually (i.e. self coding the markup for the process) or through the use of the
Visual Editor provided in this project.

The user sends requests over HTTP, since the system acts as a single web service
by itself. These are evaluated by checking the requested process ID, locating the
actual process from the deployed process cache and finally executing it, sending any
replies back to the user.
Process Descriptor Files

User Interaction




HTTP request for process


HTTP request for process




Process ID



HTTP response for process



Deployed Process

HTTP response for process


Fig. 2. Engines General Architecture

The visual editor serves as a tool that helps in the creation of BPEL processes,
allow inexperienced users to define processes using a standard diagramming
technique, namely UML activity diagrams, thus without the need of knowing the
underlying markup comprised by the language.
The user can visually drop different UML components onto a drawing canvas and
combine them in different ways to generate a corresponding BPEL process. Through
these diagrams, the editor automatically generates the markup for the specified
process, provided that the diagram is valid in its context. The user can then view, at
any point of the construction of the diagram, the code generated for the process. It
was thus necessary mapping the implemented BPEL constructs to a respective UML
activity diagram.
An activity in BPEL provides a particular action that is carried out by the process
at some point in time. It is clear that such a construct can be associated to an Action
icon in UML activity diagrams. Such BPEL constructs that were mapped to the
Action icon include the Receive, Invoke, Reply, Assign, Throw, Empty and Terminate
The Sequence activity in BPEL is implicitly obtained when two or more activities
are connected to each other with a control flow icon. The figure below shows how a
Sequence activity can be represented as a UML activity diagram.

Activity 1


Activity 2

Fig. 3. BPEL activity as a UML action

Fig. 4. A BPEL Sequence

Concurrency in BPEL is provided by the Flow construct. The corresponding UML

activity diagram that represents a set of activities executing concurrently, is the fork
transition. By definition, a Flow activity stops executing when all of its enclosing
activities have each finished their execution. This can be viewed as an implicit join
condition applied on each activity enclosed in the Flow activity. A corresponding
representation in UML activity diagrams, of such a scenario, can be provided by the
use of the fork + join icons.

Activity 1

Activity 2

Activity 3

Fig. 5. A UML action representation of a BPEL Flow Activity

The Switch activity in BPEL provides a mechanism similar to that of a nested IfThen-Else activity in many common programming languages. Such a structure can be
represented in UML activity diagrams using the decision and merge icons. The use of
a merge icon is necessary because the UML 2.0 specification states that no action can
have more than one control flow entering/exiting it. The merge icon signifies the end
of the if-then-else construct. However, these only represent a single if-then-else
construct. In order to model the Switch activity in UML, it was necessary nesting
multiple decision and merge icons respectively, which would eventually be
representing a nested If-Then-Else construct, hence the Switch activity.

Activity 1

Activity 2

Activity 3

Activity 4

Fig. 6. A UML action representation of a BPEL Switch Activity

The While construct in BPEL, is used to iteratively execute an activity and its
possible sub-activities. As described previously, the UML 2.0 specification states that
no multiple control flow can be converged to a single action. This might seem as a
problem when considering a way to represent a looping construct, like the While
activity, in UML activity diagrams. However, this can be overcome by placing a
merge icon exactly before a decision icon. A diagram is shown below.


Fig. 7. A UML action representation of a BPEL While activity

The screenshot below shows a simple representation of a tested process, namely

the Marketplace process. The idea behind this process is that of showing a small
buyer-seller scenario in the form of a web service that keeps a stateful conversation
between the two parties. The process concurrently enables two receive activities, one
for the buyer and one for the seller respectively. In such a way, the process can be
instantiated by any party. The conversation between the two parties becomes stateful
only if the item in context is equal. The process then performs some logic to check

whether the buyers offer is less than or equal to the sellers asking price. A reply is
sent to both parties, indicating the outcome of the deal.

Fig 8: BPEL Visual Editor

Time constraints were very tight and in order to obtain the best possible results it
was opted to have the most important constructs of the language implemented first,
since the project was not only focused in developing an engine that supports the
language, but also an editor that would allow users to easily generate the markup for
the language. Thus a balance between both major parts had to be established,
restricting the runtime API to provide only the most necessary constructs in
describing a process. The API was tested using different examples that are provided
with IBMs BPWS4J[8] engine, including the Marketplace example presented in
the Visual Editor section, which proved to work well for all of the implemented

The visual editor is limited when it comes to direct markup editing. Features such
as automatic markup completion have been omitted from this part of the project, since
these require quite a substantial amount of time to be completed. Such features were
considered as enhancements to the tool that would not affect the validity of the work
done and as such had to be left out due to the tight time constraints faced during the
whole project. Another limitation is that only the constructs implemented in the
runtime API were mapped to UML activity diagrams. The rest of the BPEL
constructs are not currently supported by the editor, but can easily be added in the
future. The reason behind this omission is primarily the amount of time required for
their implementation. The editor was tested through a series of UML activity
diagrams comprised of various complex compositions. The result was that the
markup generated successfully in all test cases. Furthermore, the generated markup
was then verified both through the editor and the Deployer component of the engine.
In both cases, verification resulted to be positive and the Deployer also correctly
generated the respective process file.
Since a relationship between certain BPEL and OWL-S constructs has been
discovered throughout the work done in this project, the editor can be further
extended to generate both BPEL and OWL-S markup. The idea would be that of
having a general process editor that would cater for the generation of the markup of
both of these languages, having UML activity diagrams acting as the underlying
framework that allows a mapping between particular, common constructs of these two
languages. OWL-S version 1.1 provides a set of control constructs that can be used to
define composite processes, such as Sequence, Split, Split + Join, Unordered, Choice,
If-Then-Else, Repeat-While and Repeat-Until. Each of these mentioned constructs are
defined as sub-classes of the ControlConstruct class, each having its own properties
and restrictions.
As a practical example, let us take the Sequence construct from both languages.
The UML activity diagram is similar to the one described in Figure 4, whereby the
Sequence consists of a set of ActionState icons that are connected to each other in a
sequential order. A Sequence in OWL-S is defined as a list of ControlContructs to be
executed in the order in which they are defined. Similarly, the BPEL Sequence
activity consists of one or more other activities that are to be executed sequentially,
whereby an activity defines part of the behavior that is carried out by the service (e.g.
invoke another service, send a reply to the client). Similarly, other control constructs
from both languages can also be related to each other via other UML activity
diagrams. Specifically, the Flow construct in BPEL can be mapped to the Split +
Join activity in OWL-S using the Fork and Join icons, the If-Then-Else construct in
OWL-S can be mapped to the Switch construct in BPEL using the Decision and
Merge icons, and finally, the While construct in BPEL can be mapped to the RepeatWhile construct in OWL-S using a Merge icon before a Decision icon.
Although the mapping of certain control constructs to UML activity diagrams
provided a relationship between both of these languages, the idea does not provide a
direct mapping between each construct. Specifically, the Sequence construct in
OWL-S must consist of one or more other ControlConstructs, while the Sequence
construct in BPEL must consist of one or more other activities. Other differences
arise from the fact that certain constructs are present in one language and missing in

the other. Specifically, BPEL provides constructs, called activities, such as Receive,
Invoke, Reply, etc, which are used to define the behavior of the process, while OWL-S
does not currently define such constructs. However, the idea of using UML activity
diagrams as an underlying framework in order to provide the functionality required to
generate the markup for both languages can still be applied to the editor. The editor
would have to be extended in order to determine the validity of the process diagram in
the context of the chosen language to be generated.

Related Work
A tool that is available and that allows the creation and execution of BPEL
processes is the BPWS4J package. This package consists of an execution engine and
an editor that is implemented as an Eclipse plug-in and was developed by the
Component Systems Group at IBM TJ Watson Research Center. The engine is
completely implemented in Java and that runs in a servlet container over a Javaenabled web server. The editor can be used with Eclipse V2.0 or higher. Basically,
the editor allows the inexperienced user to easily create and modify BPEL files.
Specifically, it allows the user to:

View the source both as visual tree views and as XML format.
Handle the design of the process both top-down and bottom-up.
Validate the created process against specification requirements.

In contrast to the BPEL engine provided by IBM, the implemented runtime in this
project lacks some functionality, in that not all of the language constructs have been
implemented. BPWS4J currently supports the use of all BPEL constructs. On the
other hand, the editor implemented in this project, probably provides a better
approach in guiding the user to visually construct a process, than the editor that comes
with the BPWS4J package. The main reason behind this statement is that the editor
provided by the BPWS4J package simply represents a process through the use of a
Java Tree View control, while the editor provided by this project uses a standard
software diagramming technique, namely UML activity diagrams. Furthermore, the
use of this diagramming technique also revealed an implicit relationship between
BPEL and OWL-S, as explained earlier.
In [9] the authors discuss the issue of integrating semantic web technology into
web services, specifically building on the BPEL composition language to present
dynamic binding of web services together with interoperation and semantic
translation. It is argued that in order to achieve the long-term goal of seamless
interoperability, web services must embrace many of the representation and reasoning
ideas proposed by the semantic web services community. The idea proposed in this
paper is that of integrating semantic service description querying into the BPWS4J.
Since the current release of BPWS4J is not extensible, the idea proposed is that of
constructing a Semantic Discovery Service (SDS) that would sit between a BPEL
process and its collaborating partners. The intent is that of having the engine directly
routing requests to the SDS rather than to its previously selected partners. The SDS

then locates appropriate service partners and serves as a dynamic proxy between the
engine and the discovered partners.
The LTSA-WS/BPEL4WS [13] plug-in is an Eclipse plug-in that extends on the
Labeled Transition System Analyzer (LTSA) tool. LTSA is a tool that provides a
means to construct and analyze complex models of finite state process specifications.
This plug-in allows the user to express a BPEL process in the form of a Finite State
Process (FSP) diagram [11]. In contrast to our tool, BPEL constructs have been
mapped to a respective FSP, rather than to a corresponding UML activity diagram.
Furthermore, since LTSA provides a mechanism that models workflows prior to
implementation and deployment testing, value is added to the development of a BPEL
process since early verification of the process can be performed through such a
model. In contrast to our application, this tool provides a mechanism that would
output more robust processes due to the verification performed prior to their testing,
though they resort to BPWS4J engine for execution.
CaSheW-s [14] is an ongoing project concerning the composition of semantic Web
services via workflow-oriented orchestrations. The aim of the project is similar to the
one we described in this paper in that it aims to provide a generic process editor that is
based on an underlying model and which would support different service composition
languages such as OWL-S and WSMO (Web Service Modeling Ontology) [15]. The
work also aims at providing an orchestration engine based on Haskell and which is
able to execute any workflow whose semantics can be described by process calculus.

Future Work
We plan to extend the project primarily by implementing the rest of the constructs
of the language and extending the functionality of certain implemented constructs.
The first enhancement to be carried out for the editor is the support for all of the
constructs comprised by BPEL. The current implementation of the editor only
supports the constructs implemented in the runtime API. This would require more
work on the mapping between the rest of the constructs and corresponding UML
activity diagram. Another feature, which is planned to be added to the GUI of the
editor, is a mechanism that gives brief helping tips for the use of each component,
together with a drag-drop environment for the components. Together with these
features, we also intend to include a mechanism for auto-completion of markup, when
being manually coded by the user. We also plan to extend the tool with a verification
phase prior to the execution phase. Our verification will be based on FSAs and is
inspired by [16]. The engine requires the inclusion of a scheduling mechanism so that
the tool can handle in a more efficient way not just service orchestration but also
service choreography.

The prototype described in this paper is intended to serve as a package that
provides an alternative BPEL engine that runs over the .NET framework. We have

shown that new processes built from the composition of existing web services can be
created and deployed easily. In particular the editor allows inexperienced users to
easily create their own processes by hiding away the underlying complex markup of
the language. We have also shown that our idea of using an underlying model to be
able to work with OWL-S can also be extended to BPEL and is being adopted in other
research thus proving scalable.

1. Francisco Curbera, Yaron Goland, Johannes Klein, Frank Leymann, Dieter Roller, Satish
Thatte,SanjivaWeerawarana. Business Process Execution Language for Web Services,
Version 1.0, 2002.
2. Satish Thatte. XLANG: Web Services for Business Process Design, 2002.
3. Frank Leymann, IBM Software Group, Web Services Flow Language (WSFL) Version 1.0,
4. Intalio, Sun Microsystems, BEA Systems, SAP. Web Service Choreography Interface
(WSCI) 1.0 Specification, 2002.
5. OWL-S 1.1 Release.
6. Roberto Chinnic, Martin Gudgin,Jean-Jacques Moreau, Sanjiva Weerawarana, Web
Services Description Language (WSDL) Version 1.2, 2003.
7. UML Resource Page.
8. IBM.
9. Daniel J.Mandell, Sheila A. McIlraith, Adapting BPEL4WS for the Semantic Web: The
bottom-up approach to web service interoperation,
10. James Scicluna, Matthew Montebello, Charlie Abela, Visual Modeling of OWL-S
Services, submitted to the IADIS WWW conference, 2004
11. Howard Foster, Sebastian Uchitel, Jeff Magee. Model-based verification of web service
12. Charlie Abela, Monika Solanki, The Landscape of Markup Languages for Web Service
13. LTSA-WS/BPEL4WS plug-in,
14. Composition and Semantic enHancEment of Web-Services (CaSheW-s).
15. WSMO, Web Service Modeling Ontology,
16. Daniela Berardi, Fabio De Rosa, Luca De Santis, Massimo Mecelli, Finite State Automata
as Conceptual Model for E-Services