Evaluation of the BPEL specification for business process composition by hpx14343


									                     Faculteit Ingenieurswetenschappen
                      Vakgroep Informatietechnologie
                    Voorzitter: Prof. Dr. Ir. P. LAGASSE

Evaluation of the BPEL specification for business
                     process composition


                          JORDI CLUA IBAÑEZ

                     Promotor: Prof. Dr. Ir. H. TROMP
           Scriptiebegeleider: Ir. D. MATTHYS and Ir. B. ADAMS

   Thesis submitted to obtain the academic degree of Computer Engineering.
                         Licentiaat in de Informatica

                         Academic year 2006-2007

       I would like to thank Professor Boullart for helping me when I had just arrived here.
Thanks also to Professor Tromp for letting me work in that thesis. Finally, I want to thank
to David Matthys and Bram Adams for his help, patience and advice.
I dedicate my thesis to all of them, to my family (specially my parents), to all my friends
who have encouraged me during all this time (specially Javier Cabezas for his uncountable
help) and to the people who have been living with me during this period (specially Clara)

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen
van de scriptie te kopiëren voor persoonlijk gebruik.
Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met
betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van
resultaten uit deze scriptie.”

                                                                          Jordi Clua Ibañez
                                                                                 June 2007
Evaluation of the BPEL specification for business
                     process composition
                          JORDI CLUA IBAÑEZ
   Thesis submitted to obtain the academic degree of Computer Engineering.
                         Licentiaat in de Informatica

                         Academic year 2006-2007
                     Promotor: Prof. Dr. Ir. H. TROMP
           Scriptiebegeleider: Ir. D. MATTHYS and Ir. B. ADAMS
                     Faculteit Ingenieurswetenschappen
                              Universiteit Gent
                      Vakgroep Informatietechnologie
                    Voorzitter: Prof. Dr. Ir. P. LAGASSE

       Web Services Description Language (WSDL) is an XML language for describing
the interface of web services. Universal Description, Discovery and Integration (UDDI) is a
web distributed directory which enables businesses to advertise themselves and discover
other services. Simple Object Access Protocol (SOAP) is a simple XML based protocol to
let applications exchange information over HTTP.

       These standards enable users to connect distributed web services in a platform
independent manner. However, none of them allows defining the business semantics of
combinations of web services. Web services are isolated and opaque. Breaking isolation
means connecting web services and specifying how collections of web services are jointly
used to realize more complex functionality. Breaking the opaqueness of web services also
means specifying constraints on how the operations of a collection of web services and
their joint behaviour can be used.

       A business process specifies the possible order of execution of operations from a
collection of web services, the data that is shared between these services, the partners that
are concerned and how they are involved in the business process and other issues involving
the participation of multiple services.

       Business Process Execution Language for Web Services (BPEL4WS or BPEL, in
short) allows specifying business processes and how they relate to web services. This
includes specifying how a business process makes use of web services to achieve its goals,
as well as specifying web services that are provided by a business process.

       This thesis gives a study of the WS-BPEL language and evaluates how it can be
used to compose business processes with the ActiveBPEL engine, by means of a case study
based on the Nephrology Department of Ghent University Hospital.
     Evaluation of the BPEL specification for business
                   process composition
                                                         Jordi Clua Ibañez

                           Supervisor(s): Professor Herman Tromp, David Matthys, Bram Adams

  Abstract: This article claims BPEL to be a solid solution for       Orchestration describes how Web services interact with each
web service composition. To prove this, we evaluate the             other through a message exchange flow. In orchestration, the
specification explaining the main features of the language and      overall process control is centered within one business partner.
assess its power by means of a case study.
  Keywords: BPEL,         web    services,   business    process,     Executable business processes specify the exact details of
orchestration…                                                      business processes and can be executed by a BPEL engine. In
                                                                    the majority of cases we will use BPEL to specify executable
                        I. INTRODUCTION                             processes.
   Standards like WSDL, UDDI and SOAP enable users to
connect distributed Web Services in a platform independent            Abstract business processes specify only the public message
manner. However, none of them allows defining the business          exchange between parties, without including the specific
semantics of combinations of web services.                          details of process flows. They are not executable and are
                                                                    rarely used.
    A business process specifies the possible order of
execution of operations from a collection of web services, the      B. Key features of BPEL:
data that is shared between these services, the partners that are       1) How does BPEL collaborate with Web Services
concerned and how they are involved in the business process           (WSDL)?
and other issues involving the participation of multiple
                                                                      The PartnerLink (See figure II.B) is a BPEL element. It is
                                                                    defined in the BPEL process file. It makes reference to a
   Business Process Execution Language For Web Services
                                                                      The PartnerLink is therefore dependent on the
(BPEL4WS or BPEL, in short) allows specifying business
                                                                    PartnerLinkType definition. In a BPEL process, interactions
processes and how they relate to web services.
                                                                    between business partners are defined by partner links. The
                                                                    definitions are abstract and do not contain any access
    In this thesis, we make an evaluation of the specification of
                                                                    information about actual running services.
this new language (BPEL) and assess the power of that by
means of case study.
                                                                      The PartnerLinkType is an abstract definition of a
                                                                    conversation between two services. A partnerLinkType
                     II. CONCEPTS OF BPEL                           characterizes this exchange by defining the roles played by
                                                                    each service and by specifying the portType provided by the
A. Main concepts of BPEL:                                           service to receive messages appropriate to the exchange.
      •    BPEL is built on top of Web Services                       The PartnerLinkType is a BPEL extension for WSDL. It is
           specifications.                                          defined in a WSDL file. It has no knowledge of PartnerLink,
      •    BPEL is an XML-based language.                           as it is upstream from the PartnerLink definitions.
      •    BPEL is a language for orchestration composing
           Web Services.
      •    BPEL provides support for both executable and
           abstract business processes.
      •    BPEL process is a Web Service in itself.

  Web Services are important to BPEL because they are the
input of the process but moreover also the output. BPEL,
which is expressed entirely in XML, follows the web service
model; which is why BPEL processes are implemented as web
services with a WSDL interface. Every BPEL process is
exposed as a Web service using WSDL.
                                                                                                                     Figure II.B
                                                                     During deployment of a process, each role defined in a
                                                                    partner link is assigned an endpoint reference. An endpoint
indicates a concrete location for accessing a Web service              Compensation handlers define a set of activities, which
using a specific protocol and data format. An endpoint               have to be executed when there is a problem in the process,
reference conveys the information needed to access a Web             to undo certain steps that have already been completed.
service endpoint. Using endpoint references in deployment              Fault handling in WS-BPEL is designed to catch the errors
enables the dynamic selection of a service partner.                  and decide what to do.
                                                                       Termination handlers provide the ability for scopes to
      2) How does BPEL handle the data?                              control the semantics of forced termination to some degree.
  Business processes model stateful interactions. The state            The event handler specifies what to do when certain events
involved consists of messages received and sent as well as           happen.
other relevant data such as time-out values.
  To maintain the state of a business process, BPEL uses state     C. What components does a BPEL implementation consist
variables, simply called variables. It also includes a lot of      of?
expressions to manage this data.                                     BPEL visual designer enables the development of BPEL
                                                                   processes in a graphical environment without having to write
      3) How does BPEL manage the data?                            BPEL code by hand.
  A BPEL process description defines a workflow consisting           BPEL server, of which the BPEL Engine is the main part.
of a sequence of events based on predefined conditions and         The core BPEL engine is the run-time environment where
embedded logic. Each step within a workflow is implemented         BPEL processes are deployed and executed.
through the use of a basic activity or a structured activity.        BPEL management console offers us a visualisation of
                                                                   process flows, debugging views for processes, management of
 Some activities are:                                              BPEL domains and their configuration, ...

 1.  The receive activity waits for a message from a partner.                            III. CASE STUDY
 2.  The invoke activity invokes a partner.                          To better understand and assess the power of BPEL, we
 3.  The reply activity sends an answer for a message              implemented a case study which relies on some other theses
     previously received with a receive activity.                  that were developed in the department.
 4. The wait activity is used to introduce a delay in the            The case study consists of the transfer of all the patients
     business process execution.                                   from one “Hospital” implemented by 4 web services based on
 5. An assign activity allows updating the state of a              Spring(deployed by Filip Blondeel), to another “Hospital”
     business process by copying data from one variable to         scaffolded as a Java and Ruby web services (authored by
     another.                                                      Joram Barrez).
 6. A throw activity is used by a business process to                In the case study, we have checked the applicability of the
     generate an internal fault explicitly.                        specification to create new business process.
 7. A sequence activity is a structured activity that enforces
     a sequential execution order on a collection of activities.                        IV. CONCLUSION
 8. A while activity iterates an activity while a certain
                                                                     WS-BPEL 2.0 (Business Process Execution Language for
     condition holds.
                                                                   Web Services) is a language for composing Web services and
 9. A flow activity enables concurrent execution of a set of
                                                                   to make formal specifications of automated business
 10. A pick activity awaits the occurrence of one event from
     a set of events and executes the associated activity to
                                                                     Simple Business Processes can be modelled easily with this
     that event.
                                                                   language, but (more complex) real world business processes
                                                                   bring out some shortcomings:
      4) Message Correlation
  In long-running business processes, it is necessary to route       1.   How to access local objects
messages to the correct process instance. BPEL reuses the            2.   How to communicate with other software
information that can be identified from the specifically marked      3.   The aspect of human-machine interaction
parts in incoming messages, such as order number or client id,       4.   Dealing with sub-processes
to route messages to existing instances of a business process.
This mechanism is known as correlation.                              WS-BPEL 2.0 was designed to be extensible. This
                                                                   characteristic helps to address those deficiencies and makes it
      5) How does BPEL do with errors?                             able to implement most kinds of business processes.
    Some important elements when we speak about errors are           Big companies are also pushing BPEL, so for that reason
  Compensation Handlers, Fault Handlers, Termination               and because with the proper extensions and the proper BPEL
  Handlers, Event Handlers and scope.                              visual designer you are able to compose all business process
    The concept of the scopes is very similar to structural        easily. I think that BPEL will remain the standard for web
  scopes in programming languages. That concept allows us to       services composition.
  split the process and introduces with exception faults the
  concept of ACID.
Table of Contents

1. Introduction ....................................................................................................... 1
   1.1. History of BPEL.............................................................................................................. 4
   1.2. Competitors of BPEL...................................................................................................... 5
   1.3. Why BPEL? .................................................................................................................... 7
   1.4. Thesis Plan ...................................................................................................................... 9
2. Concepts of BPEL........................................................................................... 10
   2.1. Service composition ...................................................................................................... 10
   2.2. An introduction to BPEL .............................................................................................. 12
   2.3. Key Features of BPEL 2.0 ............................................................................................ 15
      2.3.1. Process Life Cycle and process Types ................................................................... 15
      2.3.2. Partner Links and Communication......................................................................... 16
      2.3.3. Data Handling ........................................................................................................ 18
      2.3.4. Message Properties ................................................................................................ 21
      2.3.5. Message Correlation............................................................................................... 22
      2.3.6. Basic Activities ...................................................................................................... 23
      2.3.7. Structured Activities............................................................................................... 26
      2.3.8. Scopes and Handlers .............................................................................................. 29
      2.3.9. BPEL Abstract Process .......................................................................................... 35
   2.4. What components does a BPEL implementation consist of?........................................ 36
      2.4.1. Example Engines.................................................................................................... 38
3. Case Study Department Nephrology .............................................................. 39
   3.1. Engine Selection............................................................................................................ 39
      3.1.1 ActiveBPEL Engine ................................................................................................ 39
   3.2. Case Study..................................................................................................................... 42
   3.3. Pseudocode of case study.............................................................................................. 43
   3.4. Analysis of code of case study ...................................................................................... 44
4. Conclusion....................................................................................................... 48
5. Bibliography.................................................................................................... 52
APPENDIX A ..................................................................................................... 53
   A.1. Loan Approval Process ................................................................................................ 53

      A.1.1. Code of Loan Approval Process............................................................................ 54
      A.1.2. Code of Loan Approval WSDL ............................................................................ 57
   A.2. Scope Process............................................................................................................... 61
   A.2.1 Code of Scope Process ............................................................................................... 63
APPENDIX B ..................................................................................................... 66
   B.1. BPEL Code from the case study................................................................................... 66
APPENDIX C ..................................................................................................... 73
   C.1. Code of Java Web Service............................................................................................ 73
APPENDIX D ..................................................................................................... 77
   D.1. Code of Spring Web Service........................................................................................ 77
APPENDIX E...................................................................................................... 83
   E.1. Code from TransferPatients Web Service .................................................................... 83

1. Introduction

                 “A fundamental new rule for business is that the Internet changes everything."
                                                                                      Bill Gates

                                                     “The value of ideas lies in the using of it”
                                                                                Thomas Edison

       Business processes are usually of dynamic nature. Companies have to improve and
modify, act in an agile manner, optimize and adapt business processes to their customers, and
thus improve the responsiveness of the whole company. However, they also need to adapt to
the fast development of new technologies. The majority of enterprise information systems are
heterogeneous, containing a range of different systems, applications, technologies, and

       Integration of these technologies is crucial as only integrated information systems can
deliver business value, such as efficient decision-making support, instant access to
information, data integrity, along with decreased cost of software development and
maintenance. Only companies where applications can be quickly and efficiently adapted to
the changing business needs can stay competitive on the global market.

       To manage problems related to changing requirements, technology development, and
integration (companies spend over 75% of IT investment on it), different methods have been
proposed and used over time. Service Oriented Architecture (SOA) is the latest architectural
approach related to the integration, development, and maintenance of complex enterprise
information systems.

      “A paradigm for organizing and utilizing distributed capabilities that may be
      under the control of different ownership domains. It provides a uniform means to
      offer, discover, interact with and use capabilities to produce desired effects
      consistent with measurable preconditions and expectations.”

      By OASIS (Organization for the Advancement of Structured Information

      Although it is hard to find an exact definition, a SOA is generally regarded as having
the following basic characteristics:

      •       The basic building blocks of a SOA are services, which are loosely coupled and, as
              a consequence, distributed.
      •       Services are described in some sort of abstract interface language, and can be
              invoked without knowledge of the underlying implementation.
      •       Services can be dynamically discovered and used.
      •       A SOA supports integration, or composition, of services into business process.

          Web services are a concept that represents a realization of the abstract concept of
Service Oriented Architecture. Although web services are just one possible realization of a
SOA, the terms web services and SOA are often (incorrectly) used as synonyms.

      “A Web service is a software system designed to support interoperable machine-
      to-machine interaction over a network. It has an interface described in a
      machine-processable format (specifically WSDL).”

                                                By W3C (World Wide Web Consortium)

          Web services are the workers of the SOA paradigm. They provide the technological
foundation for achieving interoperability between applications using different software
platforms, operating systems, and programming languages. They are built on XML. While
XML is the de facto standard for data-level integration, web services are becoming the de
facto standard for service-level integration between and within enterprises.

          The fundamental specifications that web services are based on are:

          •    SOAP (Simple Object Access Protocol) is the basic messaging standard of web
               services for standard transport protocol

       •   WSDL (Web Services Description Language) is an interface description language
           for web services.
       •   UDDI (Universal Description, Discovery, and Integration) handles dynamic
           discovery of web services.

       Web services composition denotes development of
applications by composing web services as existing and
reusable building blocks. WSDLs make the WS composition
possible through describing the web services in a standard
way. However, it is notable that the SOAP and WSDL is not
sufficient to support the composition of web services.

                                                                                      Figure 1.1

       A new language is required to take care of the order in which the web services are
invoked in the composition. In addition, there are several composition languages (such as
BPEL) that provide several additional features to support business processes such as
transactions, exception handling and compensation.

       What might be surprising is the fact that a WS composition is usually a Web Service
also by itself. The functionality of a WS composition is exposed to the outer world through a
WSDL interface, just like with any other Web Service.

       An important difference between WSDL and a composition language is revealed when
considering the states. WSDL is in essence stateless because the language is not aware of
states in-between operations. Any technology supporting a web services composition
language will have to record states for processes that are more complex than a simple request-
response. Only by recording the state it is possible to determine what should/can be done, thus
enabling long-lived business transactions. This was the original reason that started the
development of WS composition languages.

       For this purpose, a new web services composition layer is needed on top of the WS
protocol stack (above WSDL layer). It is in this new layer that composition languages such as
BPEL, BPML, XPDL, WS-CDL and others are to be found.

       BPEL (Business Process Execution Language) is a language for composing Web
services and hence enabling business processes to be fully automated.

1.1. History of BPEL

                                    BPEL4WS 1.0
           XLang                     (IBM, BEA,                                WS-BPEL 2.0
         (Microsoft)                                                            (OASIS)

             2000      2001     2002        2003     2004    2005       2006      2007       2008

                       (IBM)                BPEL4WS 1.1

                                                                                         Figure 1.2

       Microsoft initially developed the XLANG specification, which was a block-structured
language, for the Microsoft BizTalk Server. XLANG focused on the creation of business
processes and the interactions between web service providers. The specification provided
support for sequential, parallel, and conditional process control flow. XLANG used WSDL as
a means to describe the service interface of a process.

       The Web Services Flow Language (WSFL), a graph-based workflow language, was an
IBM proposal to describe both public and private process flows. WSFL defines a specific
order of activities and data exchanges for a particular process. It defines both the execution
sequence and the mapping of each step in the flow to specific operations, referred to as flow
models and global models. The flow model represents the series of activities in the process,
while the global model binds each activity to a specific web service instance. A WSFL
definition can also be exposed with a WSDL interface, allowing for recursive decomposition.
WSFL supports the handling of exceptions but has no direct support for transactions.

       In 2002, the two companies decided to bring the two camps together, combined block
with graphs, and enticed BEA to join the effort. The result was published as BPEL4WS in
July 2002. The BP stands for business process, of course, E for execution, and L for language.
The 4WS is "for Web Services." Then, SAP and Siebel were invited to participate in the
specification (vs. standard) effort, and thus was born BPEL 1.1 which was submitted to an
OASIS technical committee in May of 2003 so that the specification could be developed into
an official, open standard.

       Since then, OASIS had been working to release WS-BPEL 2.0 and finally the
technical committee has just announced that Web Services Business Process Execution
Language 2.0, or WS-BPEL 2.0 is approved as an OASIS standard the latest 13 April 2007.

1.2. Competitors of BPEL

       The race for the universal standard in web services composition and BPM (Business
Process Management) languages that has been going on in the past few years can be said to be
over now.
       BPEL is clearly the most popular language; it has gained support from the majority of
the software industry. Thus, in the following we explain only shortly the alternative
composition languages for BPEL.

                                                                                     Figure 1.3


       BPEL is currently the de-facto composition language of the software industry. BPEL
standard is discussed in more detail in this thesis.


       BPML (Business Process Modelling Language) is a similar orchestration (see section
2.1) language to BPEL and it was one of the major rivals for BPEL in the standards war.
However, the BPML has now lost the standard war against BPEL. BPML was developed by
BPMI.org (Business Process Management Initiative) which is an independent organization
chartered by Intalio, Sterling Commerce, Sun, CSC, and others. BPML is closely related to
WSCI standard and both BPML and WSCI share the same underlying process execution
model and similar syntax.


       WSCI (Web Services Choreography Interface) is a specification from Sun, SAP, BEA,
and Intalio that defines an XML-based choreography language for web services collaboration.
It works in quite the same way as WS-CDL. The development of WSCI is today discontinued
and it is superseded by WS-CDL.


       WS-CDL is the successor of the WSCI and is the most current standard for
choreography (see section 2.1) languages and is standardized by W3C. It describes the global
view of observable behaviour of message exchange of all Web service participants that are
involved in the business collaboration. WS-CDL does not address the definition of executable
business processes as BPEL and there is no central coordinator managing the interaction. WS-
CDL models the peer-to-peer collaboration between participants with different roles in the
choreography. The WS-CDL makes use of WSDL in defining the message exchanges.


       WSCL (Web Services Conversation Language) is a specification from HP (Hewlett
Packard), it has been submitted to W3C in 2002 as a W3C Note. Since then it has not been
very active and has not gained much support from the industry.


       WSFL (Web Services Flow Language) is an old IBM initiative for web services
composition language but it is nowadays superseded by BPEL.


       XLANG is the composition specification from Microsoft for the Microsoft BizTalk
Server business process management platform. However, like WSFL, it is discontinued and
superseded now by BPEL.

1.3. Why BPEL?

       Comparing BPML to BPEL shows that both share similar roots in web services and
leverage other web services specifications, particularly WS-Security, WS-Coordination, and
WS-Transactions. BPML, however, supports modelling more complex business processes
through its support for advanced semantics such as nested processes and complex
compensated transactions. BPML can therefore be regarded as a superset of BPEL. The
extensions of BPEL with business rules, task management, human interactions, etc. are
defined in BPXL (Business Process Extension Layers).

       The fact that both BPEL and BPML share the same idioms and have similar syntax
can be a basis for possible future convergence. This is interesting because BPMI.org provides
solutions for analysis and design of business processes (Business Process Modelling
Notation—BPMN), a semantic model (Business Process Semantic Model—BPSM), and a
query language (Business Process Query Language—BPQL).

        The biggest problem of BPML is that the 1.0 version was released a month after the
1.0 version of BPEL. And BPEL was supported by big corporations like Microsoft, IBM and
SAP. The BPML standard just couldn't cope with the big support behind the BPEL standard,
so even the creators of BPML, BPMI.org acknowledged that BPEL would maybe be the
better supported version.

                                                                        Figure 1.4

        Since WSCI follows the choreography (see section 2.1.) pattern and does not address
defining executable business processes, it compares directly only to BPEL abstract processes.
WSCI has a cleaner interface, which makes it a little easier to learn than BPEL. The WSCI
specification has also been submitted to W3C, which has published it as a W3C Note. Further,
W3C has formed a WS-Choreography working group, which will address the choreography
of web services, but has only released the requirements specification so far.

        WSCI [1] has not gained industry support comparable to BPEL and the only company
that has provided support in tools is Sun with the SunONE WSCI Editor. The industry
consensus seems to support BPEL.

[1] (The WSCI specification is accessible at http://www.w3.org/TR/wsci/. )

1.4. Thesis Plan

       In the course of next chapters, we will elaborate the main concepts of BPEL, and
explain how to work with the specification elements. After that, we will test the language by
means of a case study (Transfer all patients from one Web Service (“HospitalSpring”) to
another Web Service (“HospitalJava”)). At the end, we will give the conclusions after the
complete evaluation of the BPEL language.

   •   Chapter 2
              Concepts of BPEL and main features of the specification.
   •   Chapter 3
              Case Study (Transfer all patients).
   •   Chapter 4
              Conclusion of the specification of BPEL.

2. Concepts of BPEL

       As we introduced in the Introduction Chapter: “BPEL (Business Process Execution
Language) is a language for composing Web services and hence enabling business processes
to be fully automated”.

2.1. Service composition

       The ability to integrate, or compose, existing services into new services is, arguably,
the most important functionality provided by SOA. At its very core, composition of services
should allow creating, running, adapting, and maintaining services which rely on other
services in an effective and efficient way.

       Service composition differs from traditional composition approaches in one important

   • Service composition works in a distributed fashion: In traditional composition
       approaches, components are compiled, linked, included, and sold with the final
       composition. Service compositions, on the other hand, use existing services as-is,
       invoking them via a network.

       There are two distinct ways for designing composite services, which have been named
choreography and orchestration:

   •   Orchestration: In orchestration (See figure 2.1.), a central coordinator controls the
       execution of operations of the involved web services. The involved web services do
       not know that they are involved into a composition and that they are taking part in a
       higher-level business process. Only the central coordinator is aware of the involved
       web services and in which order they should be invoked. Orchestration is used
       normally to control the private processes of the enterprise. An orchestration server is
       needed to realize the orchestration in practice. The orchestration server is usually
       integrated to the enterprise application server.

                                                                                Figure 2.1

•   Choreography: Choreography (See figure 2.2.), in contrast, does not rely on a central
    coordinator. Rather, each Web service involved in the choreography knows exactly
    when to execute its operations and with whom to interact. Choreography is a
    collaborative effort focusing on the exchange of messages in public business
    processes. All participants in the choreography need to be aware of the business
    process, operations to execute, messages to exchange, and the timing of message
    exchanges. The choreography-style control is well-suited for inter-enterprise

                                                                                Figure 2.2

2.2. An introduction to BPEL

       The Business Process Execution Language for Web Services (BPEL4WS, also known
as WSBPEL and BPEL) (Curbera, Goland 2002) is an XML-based language, built on top of
web services specifications, which has been approved as a standard for specifying and
executing service orchestration processes against a domain of web services for OASIS.

The main characteristics of the language are:

   •   BPEL is built on top of web services specifications.
   •   BPEL is an XML-based language.
   •   BPEL is a language for orchestration composing web services.
   •   BPEL provides support for both executable and abstract business processes.
   •   BPEL process is a Web Service in itself.

Let’s clarify some characteristics of the Language:

BPEL is built on top of web services specifications

                                                                                    Figure 2.3

        Web services are important to BPEL because they are the input of the process but
moreover also the output. BPEL processes follow the WSDL interface model; which is why
BPEL processes are implemented as services. A BPEL document leverages WSDL in several
ways. First, every BPEL process is exposed as a Web service using WSDL. The WSDL
describes the public entry and exit points for the process. Further, WSDL data types are used
within a BPEL process to describe the information that passes between requests. Finally,
WSDL can be used to reference external services required by the process.

BPEL is an XML-based language

        The syntax of BPEL is in XML, wich sounds obvious if you take a look at the Web
Services stack. All specifications being part of that originate from XML syntax. XML, as
most people know, is a standard (tags-based) markup language used in document and message
definition and processing. BPEL follows this same model.

        BPEL is expressed entirely in XML, uses and extends WSDL, and uses WSDL and
XML Schema for the data model. BPEL also incorporates XPATH to write expressions and

BPEL is a language for orchestration composing web services

“Orchestration is akin to traffic lights where events are controlled centrally, whereas
Choreography is more like a roundabout, where each participant is following a prearranged
set of rules.”

                                                                 Figure 2.4

       In a previous section, we have already described the meaning of orchestration and also
the composing of web services.

BPEL provides support for both executable and abstract business processes

       In BPEL, a business process is composed of elements ("activities") that define activity
behaviours, including the ability to invoke web services and control flow, and to compensate
when errors occur. The resulting business process is exposed as one or more web services.

   •   Executable business processes specify the exact details of business processes and can
       be executed by a BPEL engine. In the majority of cases we will use BPEL to specify
       executable processes.

   •   Abstract business processes specify only the public message exchange between
       parties, without including the specific details of process flows. They are not
       executable and are rarely used.

BPEL is a Web Service in itself

       BPEL processes are exposed through a WSDL interface. This allows us to address
them like normal web services, and also permits recursive construction of business processes.

2.3. Key Features of BPEL 2.0

       BPEL has been designed specifically with business processes in mind, and thus it
provides good support for the common business process characteristics. In the following we
have listed some of the key features of BPEL, with some example snippets extracted from the
examples attached in the APPENDIX A (Loan Approval Process and Scope Process) and
other examples extracted from the ActiveBPEL user guide.

       Following the figure 2.5 and with all the sections that we describe below, we are going
to explain the main features of the specification.

   2.3.1         2.3.8                                  2.3.2

                     2.3.6                 2.3.7



                                                                                     Figure 2.5

2.3.1. Process Life Cycle and process Types

       BPEL processes are typically long-lived and have state. A process is initiated through
an initial receive of a message. When the process completes its behaviour, its life cycle ends
and is terminated. It can also be terminated by uncaught faults which reach the process scope,
or explicitly by the terminate activity.

       BPEL can define two kinds of processes: abstract processes (which can be used to
specify a business protocol) and executable processes. The BPEL specification defines its
core concepts without making a distinction between the two kinds of processes.

2.3.2. Partner Links and Communication

                                                                                     Figure 2.6

       WSDL defines abstract types, the messages, the operations, and the portTypes. WSDL
also specifies the concrete bindings and services (how and where to invoke the operations).

       WS-BPEL uses WSDL’s abstract constructs and extends WSDL through a number of
new elements including partnerLinkType, providing a mechanism to track the stateful context
of conversations among otherwise stateless web services.

       A PartnerLinkType (is defined in a WSDL file, that is, the WSDL interface of the
process or the WSDL file that represents the partner) describes the kind of message exchange
that two WSDL interfaces intend to carry out. A partnerLinkType characterizes this exchange
by defining the roles played by each service and by specifying the portType provided by the
service to receive messages appropriate to the exchange.

       A partnerLinkType can include one role or two roles. In the case where a
partnerLinkType contains two roles, each of the services must implement its role by providing
the portType specified. The use of two roles indicates that there is a requirement for the
calling service to receive some type of callback from the target service in the course of the

       In the case where a partnerLinkType contains only one role, there is no restriction
placed on the calling web service regarding roles. The service described by the single role is
capable of completing the conversation simply by having its operation invoked without the
need for issuing a callback.

       Whereas the partnerLinkType is an abstract definition of a conversation between two
services, a partnerLink is the embodiment. It defines the role that the process plays (if any)
and the role that the partner service plays (if any).

                               BPEL FILE                                        WSDL FILE

 Partner Links                                               PartnerLinkType
        Partner Link                                                Role
               Name                                                       PortType
               Partner Link Type                                    Role
               My Role (process role)                                     PortType
               Partner Role
     …                                                       PortType
                                                                   Input Message
                                                                   Output Message

                                                                                     Figure 2.7

A partnerLink definition consists of:

   •   A unique name
   •   A partner link type
   •   At least one role and can include two roles
   •   Role names of My Role, which is the process role, and Partner Role.

       The myRole attribute specifies the role of the BPEL process. Defining only myRole
for partnerLink enables any partner or client to interact with the BPEL process with nothing
required of the other partner or client.

          The partnerRole attribute specifies the role of the partner or client. Defining only
partnerRole for partnerLink enables interactions with a partner or client that imposes no
requirements on its caller

          In a BPEL process, you use the partnerLink when defining Web service interaction
activities. At least, a process must have one partnerLink for each type of conversation it is
engaged in. Note that multiple partnerLink elements can reference the same partnerLinkType.
This is useful for when a process service has the same relationship with multiple partner
services. All of the partner services can therefore use the same process service portType

          EndpointReference element defines the endpoint for the destination and the message

The next example is extract from Loan Approval (Appendix A.1.1):

                                                                                     Figure 2.8

2.3.3. Data Handling

          Business processes model stateful interactions. The state involved consists of
messages received and sent as well as other relevant data such as time-out values.

       To maintain the state of a business process, BPEL uses state variables, simply called
variables. To process and manipulate the data collected in variables, BPEL provides data
expressions. Furthermore, a notion of assignment is required to update the state of a business
process, which is available in BPEL through its <assign> activity. Thus, data handling in
BPEL is delivered through concepts of variables, expressions, and assignments.

       In a BPEL process definition, variables are used to hold messages exchanged between
the process and its partners as well as internal data that is private to the process. To specify
the type we have to specify one of the following attributes:

   •   messageType: A variable that can hold a WSDL message
   •   element: A variable that can hold an XML Schema element
   •   type: A variable that can hold an XML Schema simple type

Example extract from Loan Approval bpel file (section A.1.1.):

       <bpel:variable messageType="lns:creditInformationMessage" name="request"/>
       <bpel:variable messageType="lns:riskAssessmentMessage" name="risk"/>
       <bpel:variable messageType="lns:approvalMessage" name="approval"/>

       Each variable is declared within a scope and is said to belong to that scope. Variables
that belong to the global process scope are called global variables, while others are called
local variables. BPEL follows the same rules as those in imperative programming languages
with lexical scoping of variables. A variable is visible in the scope (e.g., namely Q) to which
it belongs and all scopes that are nested within Q after variable declaration. Thus, a global
variable is visible in the entire process. Also, it is possible to hide a variable in a scope (Q) by
defining a variable with the same name in one of the scopes nested in Q.

Variable Validation
       Values stored in variables can be mutated during the course of process execution. The
<validate> activity can be used to ensure that values of variables are valid against their

associated XML data definition, including XML Schema simple type, complex type, element
definition and XML definitions of WSDL parts. The <validate> activity has a variables
attribute, listing the variables to validate. The attribute accepts one or more variable names
(BPELVariableName), separated by whitespaces. The syntax of the validate activity is:

<bpel:validate name="ValidateInput" variables="PhoneNumberVar"/>

        Data can be copied from one variable to another using the assign activity. An assign
activity may consist of a number of assignments, each of which being defined by a copy
element with from and to attributes. The source of the copy (specified by from attribute) and
the target (specified by to attribute) must be type-compatible. BPEL provides a complete set
of possible types of assignments. For example, within common uses of assignment, the source
of the copy can be a variable, a part of a variable, an XPath expression, and the target of the
copy can be a variable or a part of a variable. But also we can assign partner link endpoint
references or literal to the target of the copy.

Example extract from the code of Transfer Patients (Appendix B):

<bpel:assign name="CopyLocalVarToOutputMessage">
               <bpel:from variable="localVariable"/>
               <bpel:to part="output" variable="outputMessage"/>

        If a variable holds a WSDL message, which is common, we can further refine the copy
by specifying the part of the message we would like to copy. The location path must select
exactly one node. In the query attribute, we specify an absolute location path, where the root
'/' means the root of the document fragment representing the entire message.
The Specification does not indicate any execution order on copy elements of an assign

BPEL supports five types of expressions:

   •   Boolean expressions (transition, join, while, and if conditions)
   •   Deadline expressions (until expression of <onAlarm> and <wait>)
   •   Duration expressions (for expression of <onAlarm> and <wait>, <repeatEvery>
       expression of <onAlarm>)
   •   Unsigned Integer expressions (<startCounterValue>, <finalCounterValue>, and
       <branches> in <forEach>)
   •   General expressions (<assign>)

       BPEL provides an extensible mechanism for specifying the language used to define
expressions. This language must have facilities such as the querying of data from variables, or
inspecting the control links status, and so forth. XPath 1.0 is the default language for
specifying expressions. Another language that can be used is XSLT.

Example of Boolean expression from Loan Approval (section A.1.1.):

<bpel:transitionCondition>($risk.level = 'low')</bpel:transitionCondition>

2.3.4. Message Properties

       BPEL provides a notion of message properties, which allow us to associate relevant
data with names that have greater significance than just the data types used for such data.

       For example, a chassis number can be used to identify a motor vehicle in a business
process. The chassis number will probably appear in several messages and it will always
identify the vehicle. Let us suppose that the chassis number is of type string, because a chassis
number consists of numbers and characters. Naming it (variable) with a global property name
chassisNo gives this string a greater significance than just the data type string.

       Properties are useful on non-message variables as a way to isolate a process’ logic
from the details of a particular variable's definition. Using properties, a process can isolate its

variable initialization logic in one place and then set and get properties on that variable in
order to manipulate it. If the variable's definition is later changed, the rest of the process
definition that manipulates that variable can remain unchanged. A variable can have several
properties, each defined as a property alias.

2.3.5. Message Correlation

       Business processes may in practice continue over a long period of time, possibly days
or months. In long-running business processes, it is necessary to route messages to the correct
process instance. For example, when a request is issued from a partner, it is necessary to
identify whether a new business process should be instantiated or the request should be
directed to an existing process instance. Instead of using the concept of instance ID as often
used in distributed object systems, BPEL reuses the information that can be identified from
the specifically marked parts in incoming messages, such as order number or client id, to
route messages to existing instances of a business process. This mechanism is known as

       The concept of correlation set is then defined by naming specific combinations of
certain parts in the messages within a process. This set can be used in receive, reply and
invoke activities, the onMessage branch of pick activities, and the onEvent handlers.

       Similarly to variables, each correlation set is defined within a scope. Global
correlation sets are declared in the process scope, and local correlation sets are declared in the
scopes nested within a process. Correlation sets are only visible for the scope (Q) in which
they are declared and all scopes nested in Q. Also, correlation set can only be initialized once
during the lifetime of the scope to which it belongs.

       <correlationSet name=”PurchaseOrder” properties=”cor:customerID

2.3.6. Basic Activities

         A BPEL process description defines a workflow consisting of a sequence of events
based on predefined conditions and embedded logic. Each step within a workflow is
implemented through the use of a basic activity or a structured activity.

         Every basic activity has several standard attributes and elements that can be used to
specify certain properties. In the explanation we will not get into all the options offered by
these attributes and elements. More information about these can be found in the BPEL

         With an invoke activity a process can call another Web Service that has been defined
as a partner. The invoke can be either asynchronous or synchronous.

         An asynchronous invoke only needs to specify an input variable, because there is no
direct reaction and thus no output variable. A synchronous invoke needs both an input and an
output variable. In an executable business process these input and output variables are
required. A synchronous invoke can return a WSDL error message. This will result in a BPEL
error. Such an error could be handled locally. When the fault isn't captured then it's given to
the scope.

Example extract from Loan Approval (section A.1.1):

<bpel:invoke inputVariable="request"

        A business process offers services to its partners by receive and matching reply
activities. A receive activity specifies a partnerLink, a portType and an operation that can be
invoked. There is also an attribute in which a variable can be specified.

        The receive activity plays an important role in the life cycle of a business process. One
of the ways to initiate a process is by way of a receive activity with the attribute
createInstance set to yes. The default value of this attribute is no. A receive activity with
createInstance set to yes can be one of the initial activities of a process (this happens in a lot
of business processes). It is permitted to have multiple activities with createInstance set to
yes. In this case, the first activity that is called will initiate the process.

Example extract from Loan Approval (section A.1.1):

<bpel:receive createInstance="yes"

        A reply activity is used for sending a response after a receive activity has been called.
The reply is only useful in a synchronous interaction. An asynchronous reaction always has to
be given by use of an invoke. With the reply activity it's also possible to transfer data by
specifying a variable. A reply activity can only be placed after a receive or an onMessage
activity with the same partnerLink, portType and operation.

Example extract from Loan Approval (section A.1.1):

<bpel:reply operation="request"


Signalling faults
       When the process wants to report an internal fault, the <throw> activity can be used.
Every fault must have a globally unique qualified name. In the fault activity this name must
be defined together with a faultVariable. The faultVariable contains further information about
the fault. When handling the fault this information could be used to analyze the generated
fault and notify other partners of this fault.

Example extract from Loan Approval (section A.1.1):

<bpel:throw faultName="ns1:customFault"/>

        The <rethrow> activity is used in fault handlers to rethrow the fault they caught, i.e.
the fault name and, where present, the fault data of the original fault. It can be used only
within a fault handler (<catch> and <catchAll>).

        The <wait> activity offers the possibility to build in a certain time to sleep or wait till
a specified deadline has passed.

<wait for="'P1Y2M3D'"/>

        To specify a duration of 1 year, 2 months, and 3 days, the duration expression would
look like P1Y2M3D

Doing nothing
        There are situations where it's necessary that a process does nothing. This could
happen when you want to catch a fault, but then want to suppress it. In this case you can use
the empty activity.


         The <exit> activity is used to immediately end the business process instance. All
currently running activities must be ended immediately without involving any termination
handling, fault handling, or compensation behaviour.

         Variable update occurs through the <assign> activity, which was described previously
in section (2.3.3. Data Handling).

2.3.7. Structured Activities

Structured activities prescribe the order in which a collection of activities is executed.

WS-BPEL defines structured activities for various control-flow patterns:
     •   Sequential control between activities is provided by <sequence>, <if>, <while>,
         <repeatUntil>, and the serial variant of <forEach>.
     •   Concurrency and synchronization between activities is provided by <flow> and the
         parallel variant of <forEach>.
     •   Deferred choice controlled by external and internal events is provided by <pick>.

         A <sequence> activity contains one or more activities that are performed sequentially,
in the lexical order in which they appear within the <sequence> element. The <sequence>
activity completes when the last activity in the sequence has completed.



        The <if> element supports conditional branching. It can contain nested <elseif>s. The
first one activity whose branch is true is chosen to execute.

        The <while> semantics are equal to while looping in programming languages. The
statements in the body of the loop continue executing until the Boolean expression is no
longer true.

        <condition>$orderDetails > 100</condition>

        This structured activity will have an activity over which it will repeat in a loop until a
condition is satisfied. In contrast to the <while> activity, the <repeatUntil> loop executes
the contained activity at least once.

        The <forEach> activity will execute its contained <scope> activity exactly N+1 times
where N equals the <finalCounterValue> minus the <startCounterValue>.

        The <forEach> construct introduces dynamic parallelism (i.e. having parallel branches
of which number is not known ahead of time). The <scope> activity provides well-defined
scope semantic and a way to name the dynamic parallel work for compensation purposes. If
the value of the parallel attribute is no then the activity is a serial <forEach>. The enclosed
<scope> activity must be executed N+1 times, each instance starting only after the previous
repetition is complete.

        The <flow> activity provides concurrency and synchronization. The syntax for <flow>

               <bpel:link name="receive-to-assess"/>

       Support for concurrent activity execution is provided by the flow activity. This
activity is, arguably, the most powerful construct in the BPEL language. All activities inside a
flow activity are executed simultaneously once the flow activity is executed.

       The flow activity is the most visible remnant of IBM’s WSFL language, which was
one of the two languages serving as input to the BPEL specification. To allow for complex
concurrency scenarios, the flow construct allows the expression of synchronization
dependencies between the enclosed activities. In particular, execution of an activity can be
dependent on other activities and certain conditions.

       The synchronization dependencies are expressed by a fold approach. A named link is
defined in the links sub element of the flow activity. The link is then attached to two activities
inside the flow – a source, and a target. As a consequence, the target activity will only be
executed after the source activity has finished.

                                                               Figure 2.9
       A <pick> activity awaits the occurrence of one event from a set of events and executes
the associated activity of that event. If more than one event occurs then the pick activity will
choose the first one that has occurred.

        The <pick> activity is important because it is the second activity where the process
can start (see section 2.3.6. receive activity).
As soon as an event is chosen, the pick activity no longer accepts any of the other events.
Basically, there are two types of events on which pick activities can wait:

    •   The <onMessage> is similar to a <receive> activity, in that it waits for the receipt of
        an inbound message.
    •   The <onAlarm> corresponds to a timer-based alarm. If the specified duration value in
        <for> is zero or negative, or a specified deadline in <until> has already been reached
        or passed, then the <onAlarm> event is executed immediately.

In this example, the business process starts with a message received (onMessage) or after 5
minutes (onAlarm):

<bpel:pick createInstance="yes">
        <bpel:onMessage operation="receiveOrder" partnerLink="orderProcessPLT"
        portType="ns4:OrderPT" variable="orderMessage">
               <bpel:sequence name="Sequence">

2.3.8. Scopes and Handlers

        WS-BPEL has the notion of scopes and <scope> element. The concept is very similar
to structural scopes in programming languages. One of the most important benefits of having
scopes is the notion of compensation handlers.

The syntax for scope is:

<bpel:scope name="OuterScope">
                <bpel:variable name="localVariable" type="xsd:string"/>
                <bpel:scope name="InnerScope">

        An important attribute about the <scope> element is the “isolated” attribute. When set
to "yes", it provides control of concurrent access to shared resources: variables, partner links,
and control dependency links. Such a scope is called an isolated scope. The default value of
the isolated attribute is "no".

        It is useful to note that the semantics of isolated scopes are very similar to the standard
isolation level "serializable" used in database transactions.

       In any business process, occasionally situations will arise where exceptions or faults
occur. The WS-BPEL standard provides a fault handling element, which executes an activity
in response to faults that could potentially occur in the executing scope or process instance.

       The WS-BPEL processes can be long-duration processes, potentially involving many
partners and activities. In traditional transaction systems, transactions typically have atomic,
all-or-nothing semantics. This atomic transaction support and all the ACID (Atomicity,
Consistency, Isolation, and Durability) properties of transactions are appropriate for short-
duration transactions in DBMS (Data Base Management System) or messaging systems. In
long-duration business transactions, however, a more reasonable approach is to provide a
more flexible transaction model with less stringent requirements for atomicity as well as
isolation levels between transactions.

       The WS-BPEL approach is to use compensation activities to undo the effects of
completed steps. Inside a fault, for instance, an explicit <compensate> element can be used to
invoke a named scope’s compensation handler to undo work that previously completed
successfully. One of the most common usages of compensation is for a parent scope to invoke
the compensation handlers of its child scope. For example, if a credit card was charged in a
nested scope for a purchase and then there was a problem and the purchase is to be cancelled,
the compensation is to credit the account with the charged amount.

Some important elements of scopes are Compensation Handlers, Fault Handlers, Termination
Handlers and Event Handlers.

Compensation handler
       With a compensation handler it's possible to define a set of activities that have to be
executed when there is a problem in the process. The compensation handler can be started
from the process itself to undo certain steps that have already been completed. Another use of
the compensation handler is to define alternative steps that need to be done when a certain
event happens.

Syntactically, a <compensationHandler> is simply a wrapper for an activity that performs
compensation as shown below.

Example extract from Scope Process (section A.2.1.)

                <bpel:links><bpel:link name="L1"/></bpel:links>
                <bpel:assign name="AssignCompensatedValue">
                      <bpel:sources><bpel:source linkName="L1"/></bpel:sources>
                               <bpel:from><bpel:literal>Compensated value</bpel:literal>
                               <bpel:to variable="localVariable"/>
                <bpel:assign name="CopyLocalVarToOutputMessage">
                      <bpel:targets> <bpel:target linkName="L1"/></bpel:targets>
                               <bpel:from variable="localVariable"/>
                               <bpel:to part="output" variable="outputMessage"/>

       What if during the execution of a compensation handler an error occurs? Processing in
a compensation handler is part of the normal behaviour processing, so it means that we will
catch the error into the corresponding fault handler and execute the actions described there.

Fault handler
       Fault handling in WS-BPEL is designed to catch standard faults as well as faults from
a throw or rethrow activity or service invocation .

       The optional fault handlers that can be attached to the scope, define a set of fault
handling activities, so called catch activities. A catch activity catches a fault by its faultName
and faultVariable. When a fault occurs without a faultName, then the fault will be associated

with every faultHandler that has the same type of faultVariable. Next to the catch activities,
there is also one catchAll activity that catches all the faults that are not handled by the defined
catch activities.

                        <bpel:compensateScope target="InnerScope"/>

        When no catch or catchAll activities are provided, the fault will be given to the parent
scope. When the fault isn't caught by the global scope, then the process will stop with a
terminal activity.

Termination Handler
        Termination handlers provide the ability for scopes to control the semantics of forced
termination to some degree. The syntax is as follows:

        <bpel:assign name="HandleTermination">

        The forced termination of a scope begins by disabling the scope's event handlers and
terminating its primary activity and all running event handler instances. Following this, the
custom <terminationHandler> for the scope, if present, is run. Otherwise, the default
termination handler is run.

Event handler
        It's possible to attach an event handler to every scope in a process. This event handler
can specify what to do when certain events happen. It's important to understand that the event
handler is a normal part of the scope that is enabled when it's there.

       Message events in event handlers can occur multiple times, even concurrently, while
the corresponding scope is active. We have to take care of concurrency and use serializable
scopes if necessary.

       Typical usage of event handlers is to handle a cancellation message from the client
The syntax of the event handler section is similar to the syntax of the <pick> activity. The
only difference is that within the event handler, we can specify zero or more <onMessage>
events and/or zero or more <onAlarm> events.

Example of event handler that starts when a cancel is pressed:

<process name="Travel" enableInstanceCompensation="yes" ... >
       <onMessage partnerLink="client"
       variable="TravelRequest" >

       In the real world, we would want to undo some work when a cancellation actually
occurs. Since we cannot invoke a compensation handler from an event handler, a better
approach is to terminate the process and invoke the compensation handler for the whole
process. To enable this, we have to set the enableInstanceCompensation attribute of the
<process> tag to yes

2.3.9. BPEL Abstract Process

       Although the BPEL name suggests that this is a language for specifying executable
business processes a BPEL supports both executable business processes and abstract business
processes. Maybe for that reason this important feature is the least known. Abstract business
processes specify public message exchange between parties only.

       An abstract process describes the public interfaces and rules associated with those
interfaces while a WSDL file only describes the interfaces that are used. In addition a WSDL
file has no way of describing the sequence of communications or any dependencies that may
exist. In an abstract BPEL process you can describe all of these things and provide a template
to a partner for their own implementation.

       Because abstract processes do not specify the exact process implementation (and are
thus not executable), they differ from executable processes in several syntactical details. On
one hand, they are not allowed to use certain BPEL constructs. On the other hand, some
BPEL constructs can only be used in abstract processes.

Because abstract processes are not executable, the question is: What are they useful for?

         Order Process Steps                                      Rules
    1. Accept a PO                            •   The     order   must    be   accepted   and
    2. Acknowledge the PO                         acknowledged within 2 hours or cancelled.
    3. (Other internal services)              •   The order must be completed (Booked)
    4. Check for Inventory                        within 1 day or cancelled.
    5. Book the order                         •   The order must be completed (Invoiced)
    6. (Other internal services)                  within 2 weeks or cancelled.
    7. Sends a Shipment notification
    8. Sends an Invoice

       Using a WSDL file the only information that you can share with the partner is the
messages that will be exchanged as mentioned previously all the other rules must be written
down and interpreted by each party in the process.

       Using Abstract BPEL you can provide a process definition that includes the messages
to be exchanged using the WSDL messages, the sequence of execution using the <flow> or
<sequence> activity and the timing values specified in a onAlarm in an BPEL event handler.
As you can see the abstract process definition can provide a great deal of information that can
then be used by each partner to show the executable processes they need to implement.

2.4. What components does a BPEL implementation consist of?

       This section describes the standard architecture to work with BPEL. The objective is
to give an overview of the main architectural parts.

       The typical structure consists of three main parts:

       •   BPEL visual designer
       •   BPEL server (also knows as BPEL execution environment)
       •   BPEL management console

BPEL visual designer
       BPEL visual designer enables the development of BPEL processes in a graphical
environment without having to write BPEL code by hand. Instead of writing code, we drag
and drop activities to the process. We can add partner links and locate services. We can also

use function and copy wizards, XPath expression builder. This tool can deploy the developed
processes directly to the BPEL server. BPEL visual designer eases the development and
maintenance of BPEL processes considerably.

BPEL server
       BPEL server processes run on a variety of servlet engines/J2EE application servers
(e.g. JBoss, WebSphere, Weblogic, Tomcat, etc) but the main part of the BPEL Server is the
BPEL Engine.

       The core BPEL engine is the run-time environment where BPEL processes are
deployed and executed. In addition to full BPEL 2.0 support, an engine provides support for
key web services orchestration stack technologies, particularly WS-Addressing, WS Reliable
Messaging, WS-Security, and the BPEL compensating transaction model.

       A BPEL engine also provides support for version control. This enables development
of several versions of a business process, which can be deployed side by side. This feature is
important in real-world scenarios because business processes evolve over time. Having
effective versioning support simplifies the management.

       Another very important feature is dehydration. The business processes can be long
running because the involved partners might not be able to react instantly to the requests. This
happens particularly in asynchronous scenarios where a business process invokes a partner
web service and then waits for the response. While waiting for the response the engine can
store the process (and its state) in the database, thus freeing up server resources. This is called
dehydration. When the engine receives the response it first restores the process with its state
from the database (hydration) and then continues with the execution of the process. In real-
world scenarios where many business processes might be running side by side, the
dehydration capability is important as it reduces the demands on hardware performance.

BPEL Console
       Usually the most important features of the BPEL console include:

   •   Visual process flows
   •   Debugging view of processes

   •   Process history
   •   Management of BPEL domains and their configuration

2.4.1. Example Engines

       Implementers of the standard have developed several BPEL engines, here we list some
of them:

   •   Active Endpoints—a complete BPEL engine running either on top of a J2EE
       application server or standalone with a web servlet container (such as Tomcat).

   •   Apache Ode—an open source implementation of BPEL currently being developed
       within the incubator of the Apache Software Foundation. Original code donated from
       FiveSight/Intalio PXE—an open source, modular BPEL engine with a focus on
       reliability and flexibility. (http://incubator.apache.org/ode/)

   •   Fiorano BPEL 2006—implements BPEL including a visual BPEL editor. (available
       from Fiorano Software) (http://www.fiorano.com/)

   •   Oracle BPEL Process Manager—a BPEL engine, supporting WSBPEL 1.1,
       including Adapter Services (J2CA), Human Workflow and several other components.
       Runs as J2EE application on top of the Oracle Application Server, JBoss, BEA
       Weblogic and IBM Websphere

3. Case Study Department Nephrology

3.1. Engine Selection

       As we said, BPEL is a language so it means that we need some engine to work with it.
After the study of some of them (there aren’t a lot of OpenSource Engines), we decided to
work with ActiveBPEL. That engine accomplishes all our requirements to work with BPEL.
However the election of the Engine is not directly relevant for the thesis. The engine is only
relevant to be able to apply BPEL in our case study.

ActiveBPEL is an implementation of the BPEL standard that includes as key benefits the

   •   Completeness: The engine comprehensively implements both the BPEL4WS 1.1
       specification and the WSBPEL 2.0 standard. The engine supports the full complement
       of BPEL activities, event handling, exception handling and scope/compensation

   •   Industrial Strength: The engine includes high-end features like deployment
       packaging, process persistence, event notifications and console APIs.

   •   BPELDesigner for free with a nice GUI that is an Eclipse GUI.

3.1.1 ActiveBPEL Engine

In this section we will show the main parts of the selected engine.
As we said in section (2.4.), we can split the implementation in three different parts.

       Hand-coding BPEL process definitions can be tedious and error-prone. To assist in
the creation of well-formed BPEL, Active Endpoints makes the ActiveBPEL Designer - a
BPEL authoring tool - available for free download and use. The ActiveBPEL Designer can

be used to visually create BPEL process definitions.               The ActiveBPEL Designer
automatically generates BPEL-compliant process definitions, as well as all of the supporting
artifacts needed to deploy those processes to the ActiveBPEL engine.

                                                                       3                     4



                                                                                    Figure 3.1

In the above figure 3.1 we can easily recognize the different parts of the visual editor:

   1. Navigator: All the files of the project.
   2. Outline: Outline of all the elements of bpel process.
   3. Business process.
   4. Activities available in BPEL.
   5. Properties of elements and problems of the process.

ActiveBPEL engine
       It reads BPEL process definitions (and other inputs such as WSDL files) and creates
representations of BPEL processes. The ActiveBPEL engine is an open source
implementation of a BPEL engine, written in Java. When an incoming message triggers a start

activity, the engine creates a new process instance and starts running. The engine takes care of
persistence, queues, alarms, and many other execution details. The ActiveBPEL engine runs
in any standard servlet container such as Apache Tomcat.

ActiveBPEL Enterprise Administration Console
       The ActiveBPEL Enterprise Administration Console allows you to manage and
configure the ActiveBPEL engine and the artefacts that are deployed into it.
The Administration Console provides ways to deploy, select, inspect, and correct processes
and related endpoint references

                                                                                  Figure 3.2

3.2. Case Study

       To better understand and assess the power of BPEL, we implemented a case study
which relies on some other theses that were developed in the department. The case study
consists of the transfer of all patients from one hospital to another hospital.
       For that case study we have 2 different web services that implement the management
of the patients of the Nephrology department of the Ghent University Hospital. One Web
service is built on Spring (by Filip Blondeel) and the other is built on Java (by Joram Barrez).
       To transfer all the patients first we will get all the patients from one hospital in this
case “spring hospital” and then for every patient of that hospital will be added to the “java
       The business process support exceptions, it means that if an exception occurs we will
notify that. The result of the process will be a notification about the success rate of the

3.3. Pseudocode of case study

       //Creates process instance
       Receive start request
       //We get all the patients of Spring Hospital
       New Array AllPatientsSpring = Invoke getAllPatientsSpringHospital

       //Start the counters
       Integer index=1;
       //All the position of AllPatientsSpring
       Integer totalPos = count(AllPatientsSpring);

       //We add to Java Hospital all the patients from Spring Hospital
       While (index <= totalPos) {
              Boolean b = Invoke addPatientJava (AllPatientsSpring[index];
              If (!b) {
                      throw( );
       //If it succed we note that
       Add Message(“Completed Succesfully”) to Reply to Start;
       Reply to Start request;
} catch {
       //if an exception occurs we catch it and notify the error
       Add Message(“Completed with errors!!”) to Reply to Start;
       Reply to Start request;

3.4. Analysis of code of case study

         All the code is available in the appendix B.1.
         The business process that transfers patients looks in the BPEL designer as the figure

                                                                     Figure 3.3

                                                             Figure 3.4

       As we can see in the figure 3.3, the normal process behaviour is just the same as we
described through pseudocode in the previous section. One can clearly observe a.o. the loop

       In the figure 3.4 it’s the behaviour if an exception occurs, the catch part in the

       So as we have seen, using the BPEL designer the business process is constructed
almost as easily and concise as writing pseudo code, and we don’t have to care about spitting
endless lines of xml code by ourselves (appendix B.1.).

Let’s comment the code from BPEL file (complete code in appendix B.1.):

       We can identify easily the main blocks of the language, the root <process> element,
<PartnerLinks>, <variables>, <FaultHandlers> and the rest of the <process>.

       In the <process> element we declare some significant attributes. We could say that the
most important are of course the name, queryLanguage and expressionLanguage (which take
as default language XPATH 1.0).

<bpel:process xmlns:bpel=http://docs.oasis-open.org/wsbpel/2.0/process/executable
ext:createTargetXPath="yes" name="TransferPatients" suppressJoinFailure="yes"

       WS-BPEL is designed to be extensible. The <extension> child element under
<extensions> element of the <process> element is used to declare namespaces of WS-BPEL
extension attributes/elements and indicate whether they carry semantics that must be
understood by a WS-BPEL processor.

       <bpel:extension mustUnderstand="yes"

           The <import> element is used within a WS-BPEL process to declare a dependency on
external XML Schema or WSDL definitions. Any number of <import> elements may appear
as children of the <process> element.

<bpel:import importType=http://schemas.xmlsoap.org/wsdl/
ts.wsdl" namespace="TransferPatients"/>

           After the root element we have the <PartnerLinks> (it was explained in the section
           In this process we have 3 partnerLinks: the PartnerLink with the Spring Web Service
(Appendix D), with the Java Web Service (Appendix C) and finally the PartnerLink of the
new process TransferPatient (as we said a BPEL process is also a Web Service, that concept is
shown in the graphic of the section 2.3.2) (Appendix E).

           <bpel:partnerLink myRole="AdministradorGeneral"

           The next block is the <variables> where we define the variables of the process (see
section 2.3.3.).

           <bpel:variable messageType="ns2:getAllPatientsRequest"
           <bpel:variable messageType="ns2:getAllPatientsResponse"

       <FaultHandlers> (see section 2.3.8.): in this case we have declared a catch for all
errors with the element <catchall> and we have also declared which action we have to do
when we catch that error, in this case assign a new message to our reply variable and send it.


       The rest of the BPEL file is the normal behaviour of the process; in that part of the
process we mix basic activities with structured activities to accomplish the target of the
process. As we have explained in the previous section (3.2.), the target of this process is the
transfer of allPatients from “SpringHospital” to “JavaHospital”.

       <bpel:receive createInstance="yes" name="ReceiveTransferPatients"
               operation="TransferAllPatients" partnerLink="AdministradorTransfer"
               portType="ns1:TransferPort" variable="Input">

4. Conclusion

       ”A set of linked activities that take an input and transform it to create an output.
       Ideally, the transformation that occurs in the process should add value to the        input
       and create an output that is more useful and effective to the recipient either
       upstream or downstream.”

                                               Johansson et al. (1993) process definition.

       Companies are interested in business processes because automation of them brings
more money to the enterprise. For this automation, they need different software applications
to become integrated. A possible solution is exposing existing IT systems as web services,
and they use BPEL to tie the knots together.

       WS-BPEL 2.0 (Business Process Execution Language for Web Services) is a new
standard that permits to orchestrate different web services to create new business processes. In
other words, it allows isolated services of different companies to work together to accomplish
a new target (business process).

       Within BPEL, we are able to join different web services into a new process and then
expose that as a web service, also we have some features as data handling (which allows us to
store data from this web service and manipulate it), fault handlers, activities (basic and

       Simple business processes can be modelled easily with this language, as shown in
previous chapters, but (more complex) real world business processes bring out some

       A process often needs to communicate with other software outside its own
       environment. If that software is accessible via web services, this does not represent a
       problem for a BPEL-defined process. However, much software does not provide a web
       services interface yet, a situation for which BPEL provides no standard solution.

       Processes commonly need to access data, such as information stored in a relational
       database system. BPEL is focused entirely on web services access, and so while it
       does allow working with XML data, sometimes the access to bigger data stores (where
       XML does not scale up sufficiently) is required. The language does not define a
       standard way to access relational data or other non-XML information

       But maybe the most important lacking feature is the absence of Human Task, since it
       is not difficult to think about a real business process that requires Human interaction.
       For example, a complex process in which users may be required to enter data or
       change the state of running processes, such as initiate, suspend or resolve exceptions
       to a process. These interactions can prove to be the determining factor in whether a
       process succeeds or fails.

       Human tasks differ from services in 2 ways. First, they are assigned to roles (mapped
at runtime to users or groups) not service endpoints (URLs). Second, human tasks are so
fundamentally different than services that human tasks are primarily stateful (ready, in
progress, complete, failed, and so on) and can only have one consumer at a time, whereas
service invocations are primarily stateless, such that the service does not care how many
consumers are using it at a given time. Because of those fundamental differences, any
implementation of this functionality should be handled as an extension and not as part of the
core specification.

       The BPEL language currently does not support the explicit definition of business
       process “fragments” that can be invoked from within the same business process or
       from another business process. Such functionality is well-known in business process
       technology and subsumed by the term sub-process (activity). Sub-processes are used
       in practice to modularize large business process and to foster reuse of processes.
       Consequently, sub-processes are typically tightly coupled in terms of their lifecycle to
       the invoking process (called parent process). For example, when a parent process is
       terminated, its sub-processes have to be terminated too; when the activity invoking a
       sub-process is compensated, compensation is delegated to the sub-process.

       The only way to approximate similar behaviour in BPEL is by defining a complete
business process as an independent service and invoking it via an invoke activity. The fact

that this activity is really implemented as another process is completely hidden from the
parent process. There is no mechanism to establish the lifecycle dependency described above.
As a consequence, this approach is really only an approximation. Although the invoke activity
of the parent process will be interrupted and terminated, BPEL does not provide any means to
ensure that termination propagates to the invoked Web service. Therefore it cannot be ensured
that the sub-process, which is exposed as a Web service, will be terminated if the parent
process terminates.

       The lack of all this features, raise some questions: Which kind of business process can
I build? Only trivial business processes can be modelled?

       In its new specification 2.0, BPEL was designed to be extensible. This characteristic
helps to address those deficiencies and makes it able to implement most kinds of business
processes. In fact, there is an industry group working on many of the lacking features
aforementioned, for example:

•   WS-BPEL Extension For People – BPEL4People by IBM and SAP
•   WS-BPEL Extension for Sub-processes – BPEL-SPE by IBM and SAP

       However, it is important to understand some deeper implications of this absence. The
most important is that to be able to implement different kinds of business processes in BPEL
generally requires using product-specific extensions. Some vendors have already developed
proprietary implementations thus losing the interoperability and portability that a fully
standardized language gives.

       WS-BPEL 2.0 has considerable differences to its previous 1.1 version. The major ones
include syntax changes to the language, inclusion of new features like parallel for-each, and
modifications to the semantic of existing constructions, such as compensation handling.

       Nevertheless, for all but the simplest business processes, migration from BPEL 1.1 to
BPEL 2.0 is not an easy task. Some of the syntactic changes can be automated, however the
semantic differences, especially when dealing with links, messaging, compensation handling,
and data manipulation, demand a comprehensive and time-consuming process

       As we shown, for a simple business process we have generated almost 6 pages of
XML code for the BPEL file, so it means that handwriting the file is not a serious option.
Conversely, we also demonstrated that a visual BPEL editor makes short work of a similar
handicap. So it won’t be a problem for the spread the language.

       In conclusion, despite several useful features lacking at the moment, I think that BPEL
will remain the future standard for web service composition. With its properties extensions
(BPEL4People, BPEL-SPE…), the language has the ability to create most kinds of business
processes. It is obvious that the language has some rough edges, but there are very big
companies pushing new features, which eventually could be merged into the main standard.

       Therefore, in my opinion, it is important to consider BPEL as a milestone for web
service composition, and I will encourage using it if I had to work in this scope.

5. Bibliography

  •   Essential Business Process Modeling By Michael G. Harvey

  •   Business Process Execution Language for Web Services (2006),.2Ed by Matjaz B.

  •   "Service-Oriented Architecture: Concepts, Technology, and Design" by Thomas Erl
      Chapter 16

  •   WS-BPEL Extension for Sub-processes (BPEL-SPE), White Paper, IBM, SAP AG,
      September 2005

  •   WS-BPEL Extension for People (BPEL4People), White Paper, IBM, SAP AG, July

  •   Service-Oriented Processes (Chapter VIII An Introduction to BPEL) by Chun Ouyang,
      Wil M.P. van der Aalst, Marlon Dumas, Arthur H.M. ter Hofstede, and Marcello La

  •   Web Services Business Process Execution Language Version 2.0 Committee
      Specification by OASIS

  •   Wikipedia (http://wikipedia.org/)

  •   ActiveEndPoints (http://active-endpoints.com/)

  •   BPELSource (http://bpelsource.com/)


Both examples are extracted from the ActiveBPEL guide as another snippets used in section

A.1. Loan Approval Process

The first example that we show is the typical (and maybe the most popular) example of BPEL
the Loan Approval Process.

What is the Loan Approval Process?

The loan approval process starts by receiving a customer request for a loan amount. If the
request is for less than $10,000, the assessor’s Web service is invoked to assess whether the
customer is a low or high risk. If the customer is low risk, the request is approved. Otherwise,
the request is sent to the approver for review. If the amount is for $10,000 or more, the request
is always sent to the approver for review. The customer can receive acceptance from the
assessor or an accept/reject reply from the approver.

A.1.1. Code of Loan Approval Process

<bpel:process xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="loanApprovalProcess"
suppressJoinFailure="yes" targetNamespace="http://docs.active-
       <bpel:extension mustUnderstand="yes"
<bpel:import importType="http://schemas.xmlsoap.org/wsdl/"
location="../../Resources/WSDL/loan_approval.wsdl" namespace="http://docs.active-

       <bpel:partnerLink myRole="loanService" name="customer"
       <bpel:partnerLink name="approver" partnerLinkType="lns:loanApprovalLinkType"
       <bpel:partnerLink name="assessor" partnerLinkType="lns:riskAssessmentLinkType"
       <bpel:variable messageType="lns:creditInformationMessage" name="request"/>
       <bpel:variable messageType="lns:riskAssessmentMessage" name="risk"/>
       <bpel:variable messageType="lns:approvalMessage" name="approval"/>
       <bpel:catch faultMessageType="lns:errorMessage" faultName="lns:loanProcessFault"
                <bpel:reply faultName="lns:unableToHandleRequest" operation="request"
                partnerLink="customer" portType="lns:loanServicePT" variable="error"/>
       <bpel:link name="receive-to-assess"/>
       <bpel:link name="receive-to-approval"/>
       <bpel:link name="assess-to-setMessage"/>
       <bpel:link name="assess-to-approval"/>
       <bpel:link name="setMessage-to-reply"/>
       <bpel:link name="approval-to-reply"/>
<bpel:receive createInstance="yes" operation="request" partnerLink="customer"
portType="lns:loanServicePT" variable="request">
                <bpel:source linkName="receive-to-assess">
                <bpel:transitionCondition>($request.amount &lt;

                <bpel:source linkName="receive-to-approval">
                <bpel:transitionCondition>($request.amount &gt;=
<bpel:invoke inputVariable="request" name="InvokeAssessor" operation="check"
outputVariable="risk" partnerLink="assessor" portType="lns:riskAssessmentPT">
                <bpel:target linkName="receive-to-assess"/>
                <bpel:source linkName="assess-to-setMessage">
                <bpel:transitionCondition>($risk.level = 'low')</bpel:transitionCondition>
                <bpel:source linkName="assess-to-approval">
                <bpel:transitionCondition>($risk.level != 'low')</bpel:transitionCondition>
                <bpel:target linkName="assess-to-setMessage"/>
                <bpel:source linkName="setMessage-to-reply"/>
                <bpel:to part="accept" variable="approval"/>

<bpel:invoke inputVariable="request" name="InvokeApprover" operation="approve"
outputVariable="approval" partnerLink="approver" portType="lns:loanApprovalPT">
                <bpel:target linkName="receive-to-approval"/>
                <bpel:target linkName="assess-to-approval"/>
                <bpel:source linkName="approval-to-reply"/>
<bpel:reply operation="request" partnerLink="customer" portType="lns:loanServicePT"
                <bpel:target linkName="setMessage-to-reply"/>
                <bpel:target linkName="approval-to-reply"/>

A.1.2. Code of Loan Approval WSDL

<?xml version="1.0" encoding="UTF-8" ?>
<definitions targetNamespace=http://docs.active-

<message name="creditInformationMessage">
      <part name="firstName" type="xsd:string"/>
      <part name="name" type="xsd:string"/>
      <part name="amount" type="xsd:integer"/>

<message name="approvalMessage">
      <part name="accept" type="xsd:string"/>

<message name="riskAssessmentMessage">
      <part name="level" type="xsd:string"/>

<message name="errorMessage">
      <part name="errorCode" type="xsd:integer"/>

<portType name="loanServicePT">
      <operation name="request">
              <input message="lns:creditInformationMessage"/>
              <output message="lns:approvalMessage"/>
              <fault name="unableToHandleRequest" message="lns:errorMessage"/>

<portType name="riskAssessmentPT">
      <operation name="check">
              <input message="lns:creditInformationMessage"/>
              <output message="lns:riskAssessmentMessage"/>
              <fault name="loanProcessFault" message="lns:errorMessage"/>

<portType name="loanApprovalPT">
      <operation name="approve">
              <input message="lns:creditInformationMessage"/>
              <output message="lns:approvalMessage"/>
              <fault name="loanProcessFault" message="lns:errorMessage"/>

<binding name="SOAPBinding" type="tns:loanApprovalPT">
      <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="approve">
      <soap:operation soapAction="" style="rpc"/>
              <soap:body use="encoded" namespace="urn:loanapprover"
              <soap:body use="encoded" namespace="urn:loanapprover"

<service name="LoanApprover">
      <documentation>Loan Approver Service</documentation>
      <port name="SOAPPort" binding="tns:SOAPBinding">
      <soap:address location="http://localhost:8080/active-
<binding name="SOAPBinding1" type="tns:riskAssessmentPT">
      <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="check">
      <soap:operation soapAction="" style="rpc"/>

                 <soap:body use="encoded" namespace="urn:loanassessor"
                 <soap:body use="encoded" namespace="urn:loanassessor"
<service name="LoanAssessor">
       <documentation>Loan Assessor Service</documentation>
       <port name="SOAPPort1" binding="tns:SOAPBinding1">
       <soap:address location="http://localhost:8080/active-
<plnk:partnerLinkType name="loanPartnerLinkType">
       <plnk:role name="loanService">
       <plnk:portType name="lns:loanServicePT"/>
<plnk:partnerLinkType name="loanApprovalLinkType">
       <plnk:role name="approver">
       <plnk:portType name="lns:loanApprovalPT"/>
<plnk:partnerLinkType name="riskAssessmentLinkType">
       <plnk:role name="assessor">
       <plnk:portType name="lns:riskAssessmentPT"/>

A.2. Scope Process

This sample focuses on the scope activity: its uses, parts, and syntax. It includes an example
BPEL process that uses all of the aspects of the scope activity (except one: the
variableAccessSerializable attribute, covered in Serializable Scopes).

What’s a Scope Process?

The sample process, shown below, contains a sequence that starts with a receive activity that
accepts a message containing an order. The sequence ends with a reply that returns a message
containing a string. In between the receive and the reply is an outer scope that contains an
inner scope.The outer scope declares a local variable. (This declaration isn't visible in the
image below.)

The scope's primary activity is a sequence containing four activities. The first assigns the
string "Initial variable value" to the local variable. The second is an inner scope. The third is
an empty activity named "DoSomethingInteresting" that is standing in for some fictional
"interesting" activities. The final activity of the scope's sequence copies the value of the local
variable to the output message.
The inner scope's activity is an assign activity that sets the local variable's value to "Inner
scope value".

The previous paragraphs describe the normal flow through the process: receive a message,
declare a local variable, assign a few values to it, and return the value. Now it gets interesting:
the outer scope has an event handler that contains an onAlarm which times out after five
minutes. If the alarm goes off, it throws a fault. The same outer scope has a fault handler that
contains a catchAll, so it will catch the thrown fault. The catchAll contains a compensate
activity that compensates the inner scope.

Then after that the inner scope's compensation handler starts to work (does what is
implemented inside), it sets the local variable's value to "Compensated value". So, if the alarm
goes off after if the inner scope has completed normally but before the outer scope has
completed normally (for example, during the execution of the "DoSomethingInteresting"

activity) then the value of the local variable will be set to "Compensated value", and that
value will be copied to the output message.

A.2.1 Code of Scope Process

<bpel:process xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="scope"
suppressJoinFailure="yes" targetNamespace="http://docs.active-
       <bpel:extension mustUnderstand="yes"
<bpel:import importType="http://schemas.xmlsoap.org/wsdl/"
location="../../Resources/WSDL/scope.wsdl" namespace="http://docs.active-
       <bpel:partnerLink myRole="scopeProcess" name="scopeProcess"
       <bpel:variable messageType="ns1:orderMessage" name="orderMessage"/>
       <bpel:variable messageType="ns1:outputMessage" name="outputMessage"/>
       <bpel:receive createInstance="yes" operation="receiveOrder"
       partnerLink="scopeProcess" portType="ns1:scopePT" variable="orderMessage"/>
       <bpel:scope name="OuterScope">
              <bpel:variable name="localVariable" type="xsd:string"/>

              <bpel:compensateScope target="InnerScope"/>
              <bpel:throw faultName="ns1:customFault"/>
       <bpel:assign name="AssignInitialValue">
                               <bpel:literal>Initial variable value</bpel:literal>
                        <bpel:to variable="localVariable"/>
       <bpel:scope name="InnerScope">
                               <bpel:link name="L1"/>
                        <bpel:assign name="AssignCompensatedValue">
                               <bpel:source linkName="L1"/>
                                        <bpel:literal>Compensated value</bpel:literal>
                               <bpel:to variable="localVariable"/>

                                <bpel:assign name="CopyLocalVarToOutputMessage">
                                               <bpel:target linkName="L1"/>
                                       <bpel:from variable="localVariable"/>
                                       <bpel:to part="output" variable="outputMessage"/>
                      <bpel:assign name="AssignInnerScopeValue">
                                       <bpel:literal>Inner scope value</bpel:literal>
                                <bpel:to variable="localVariable"/>
                <bpel:empty name="DoSomethingInteresting"/>
                <bpel:assign name="CopyLocalVarToOutputMessage">
                      <bpel:from variable="localVariable"/>
                      <bpel:to part="output" variable="outputMessage"/>
<bpel:reply operation="receiveOrder" partnerLink="scopeProcess" portType="ns1:scopePT"


B.1. BPEL Code from the case study

<?xml version="1.0" encoding="UTF-8"?>
<!-- BPEL Process Definition Edited using ActiveBPEL(tm) Designer Version 3.0.0
(http://www.active-endpoints.com) -->
<bpel:process xmlns:bpel=http://docs.oasis-open.org/wsbpel/2.0/process/executable
xmlns:ns3="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns4="http://services/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" ext:createTargetXPath="yes"
name="TransferPatients" suppressJoinFailure="yes"
       <bpel:extension mustUnderstand="yes"
<bpel:import importType=http://schemas.xmlsoap.org/wsdl/
       erPatients.wsdl" namespace="TransferPatients"/>
<bpel:import importType=http://schemas.xmlsoap.org/wsdl/
<bpel:import importType="http://schemas.xmlsoap.org/wsdl/"
       plService.wsdl" namespace="http://services/"/>

       <bpel:partnerLink myRole="AdministradorGeneral"
       <bpel:partnerLink name="AllLT"
       <bpel:partnerLink name="AdministradorJavaLT"
       <bpel:variable messageType="ns1:Input" name="Input"/>
       <bpel:variable messageType="ns1:Output" name="Output"/>
       <bpel:variable messageType="ns2:getAllPatientsRequest"
       <bpel:variable messageType="ns2:getAllPatientsResponse"
       <bpel:variable messageType="ns4:addPatient" name="addPatient"/>
       <bpel:variable messageType="ns4:addPatientResponse"
       <bpel:variable name="TotalPosition" type="xsd:integer"/>
       <bpel:variable name="index" type="xsd:integer"/>
                              <bpel:link name="L7_1"/>
                              <bpel:source linkName="L7_1"/>

                               <bpel:literal>Process completed with errors!</bpel:literal>
                        <bpel:to part="Complete" variable="Output"/>
                        <bpel:reply name="ReplyTransferPatients"
                        operation="TransferAllPatients" partnerLink="AdministradorTransfer"
                        portType="ns1:TransferPort" variable="Output">
                               <bpel:target linkName="L7_1"/>
              <bpel:link name="L1"/>
              <bpel:link name="L2"/>
              <bpel:link name="L3"/>
              <bpel:link name="L6"/>
              <bpel:link name="L7"/>
       <bpel:receive createInstance="yes" name="ReceiveTransferPatients"
              operation="TransferAllPatients" partnerLink="AdministradorTransfer"
              portType="ns1:TransferPort" variable="Input">
                        <bpel:source linkName="L1"/>
       <bpel:reply name="ReplyTransferPatients" operation="TransferAllPatients"
              partnerLink="AdministradorTransfer" portType="ns1:TransferPort"

                <bpel:target linkName="L7"/>
<bpel:invoke inputVariable="getAllPatientsRequest"
name="getAllPatientsSpring" operation="getAllPatients"
outputVariable="getAllPatientsResponse" partnerLink="AllLT"
                <bpel:target linkName="L1"/>
                <bpel:source linkName="L2"/>
<bpel:assign name="IniIndex">
                <bpel:target linkName="L2"/>
                <bpel:source linkName="L3"/>
       <bpel:copy ignoreMissingFromData="yes">
                <bpel:to variable="index"/>
       <bpel:copy ignoreMissingFromData="yes">
                <bpel:to part="parameters" variable="addPatientResponse"/>

               <bpel:to variable="TotalPosition"/>
               <bpel:target linkName="L3"/>
               <bpel:source linkName="L6"/>
               $index &lt;= $TotalPosition</bpel:condition>
                       <bpel:link name="L5"/>
                       <bpel:link name="L8"/>
                       <bpel:link name="L4"/>
               <bpel:invoke inputVariable="addPatient" name="AddPatientJava"
               operation="addPatient" outputVariable="addPatientResponse"
                       <bpel:target linkName="L4"/>
                       <bpel:source linkName="L5">
                       <bpel:source linkName="L8">

expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0">not( boolean(
             $addPatientResponse.parameters/. ) )</bpel:transitionCondition>
             <bpel:assign name="AssignDataPatient">
                              <bpel:source linkName="L4"/>
                              <bpel:from variable="index"/>
                              <bpel:to part="parameters" variable="addPatient">
                              Return/PatientDTO[ $index]/firstName</bpel:from>
                              <bpel:to part="parameters" variable="addPatient">
             <bpel:assign name="IncIndex">
                              <bpel:target linkName="L5"/>
                              <bpel:to variable="index"/>
             <bpel:throw faultName="ErrorAddPatient">

                                <bpel:target linkName="L8"/>
                      <bpel:target linkName="L6"/>
                      <bpel:source linkName="L7"/>
               <bpel:copy ignoreMissingFromData="yes">
                                <bpel:literal>Process completed successfully</bpel:literal>
                      <bpel:to part="Complete" variable="Output"/>


C.1. Code of Java Web Service

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="PatientServiceImplService" targetNamespace="http://services/"
xmlns:tns="http://services/" xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-
link/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
       <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
              <xsd:import namespace="http://services/" schemaLocation="http://
<message name="removePatientResponse">
       <part name="parameters" element="tns:removePatientResponse"/>
<message name="addPatient">
       <part name="parameters" element="tns:addPatient"/>
<message name="getPatientResponse">
       <part name="parameters" element="tns:getPatientResponse"/>
<message name="getPatient">
       <part name="parameters" element="tns:getPatient"/>
<message name="addPatientResponse">
       <part name="parameters" element="tns:addPatientResponse"/>

       <message name="getAllPatientsResponse">
<part name="parameters" element="tns:getAllPatientsResponse"/>
       <message name="getAllPatients">
       <part name="parameters" element="tns:getAllPatients"/>
<message name="removePatient">
       <part name="parameters" element="tns:removePatient"/>
<portType name="PatientServiceImpl">
       <operation name="addPatient">
              <input message="tns:addPatient"/>
              <output message="tns:addPatientResponse"/>
       <operation name="getPatient">
              <input message="tns:getPatient"/>
              <output message="tns:getPatientResponse"/>
       <operation name="removePatient">
              <input message="tns:removePatient"/>
              <output message="tns:removePatientResponse"/>
       <operation name="getAllPatients">
              <input message="tns:getAllPatients"/>
              <output message="tns:getAllPatientsResponse"/>
<binding name="PatientServiceImplPortBinding" type="tns:PatientServiceImpl">
<soap:binding xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" style="document"
       <operation name="addPatient">
              <soap:operation xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

               <soap:body xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
               <soap:body xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
<operation name="getPatient">
      <soap:operation xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
               <soap:body xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
               <soap:body xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
<operation name="removePatient">
      <soap:operation xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
               <soap:body xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
               <soap:body xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
<operation name="getAllPatients">

                 <soap:operation xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                       <soap:body xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                       <soap:body xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
<service name="PatientServiceImplService">
<port name="PatientServiceImplPort" binding="tns:PatientServiceImplPortBinding">
<soap:address xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
<plnk:partnerLinkType xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype"
       <plnk:role name="AdministradorJava" portType="tns:PatientServiceImpl"/>


D.1. Code of Spring Web Service

<?xml version="1.0" encoding="UTF-8"?>
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:plnk2="http://docs.oasis-
open.org/wsbpel/2.0/plnktype" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
       <schema targetNamespace="urn:Kidney"
<import namespace="http://boromir.ugent.be:57000/kidneyspring/services/PatientService"/>
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<complexType name="PatientDTO">
               <element name="firstName" nillable="true" type="soapenc:string"/>
               <element name="lastName" nillable="true" type="soapenc:string"/>
               <element name="loginName" nillable="true" type="soapenc:string"/>
<import namespace="urn:Kidney"/>

<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<complexType name="ArrayOf_tns1_PatientDTO">
                <restriction base="soapenc:Array">
                <attribute ref="soapenc:arrayType" wsdl:arrayType="tns1:PatientDTO[]"
      <wsdl:message name="getAllPatientsRequest">
      <wsdl:message name="removePatientResponse">
                <wsdl:part name="removePatientReturn" type="xsd:boolean"/>
      <wsdl:message name="removePatientRequest">
                <wsdl:part name="loginName" type="soapenc:string"/>
      <wsdl:message name="validatePatientResponse">
                <wsdl:part name="validatePatientReturn" type="tns1:PatientDTO"/>
      <wsdl:message name="updatePatientResponse">
                <wsdl:part name="updatePatientReturn" type="tns1:PatientDTO"/>
      <wsdl:message name="registerNewPatientResponse">
                <wsdl:part name="registerNewPatientReturn" type="tns1:PatientDTO"/>
      <wsdl:message name="updatePatientRequest">
                <wsdl:part name="loginName" type="soapenc:string"/>
                <wsdl:part name="firstName" type="soapenc:string"/>
                <wsdl:part name="lastName" type="soapenc:string"/>
      <wsdl:message name="validatePatientRequest">

             <wsdl:part name="loginName" type="soapenc:string"/>
      <wsdl:message name="Salidita">
             <wsdl:part name="Pat" type="tns1:PatientDTO"/>
      <wsdl:message name="registerNewPatientRequest">
             <wsdl:part name="loginName" type="soapenc:string"/>
             <wsdl:part name="firstName" type="soapenc:string"/>
             <wsdl:part name="lastName" type="soapenc:string"/>
      <wsdl:message name="Vacia">
      <wsdl:message name="getAllPatientsResponse">
      <wsdl:part name="getAllPatientsReturn" type="impl:ArrayOf_tns1_PatientDTO"/>
<wsdl:portType name="JaxRpcPatientService">
      <wsdl:operation name="updatePatient" parameterOrder="loginName firstName
             <wsdl:input name="updatePatientRequest"
             <wsdl:output name="updatePatientResponse"
      <wsdl:operation name="validatePatient" parameterOrder="loginName">
             <wsdl:input name="validatePatientRequest"
             <wsdl:output name="validatePatientResponse"
      <wsdl:operation name="registerNewPatient" parameterOrder="loginName firstName
             <wsdl:input name="registerNewPatientRequest"

              <wsdl:output name="registerNewPatientResponse"
       <wsdl:operation name="removePatient" parameterOrder="loginName">
              <wsdl:input name="removePatientRequest"
              <wsdl:output name="removePatientResponse"
       <wsdl:operation name="getAllPatients">
              <wsdl:input name="getAllPatientsRequest"
              <wsdl:output name="getAllPatientsResponse"
<wsdl:binding name="PatientServiceSoapBinding" type="impl:JaxRpcPatientService">
<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"
       <wsdl:operation name="updatePatient">
       <wsdlsoap:operation soapAction=""
              <wsdl:input name="updatePatientRequest">
              <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
              namespace="http://remote.patient.services" use="encoded"
              <wsdl:output name="updatePatientResponse">
       <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
       use="encoded" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"/>
       <wsdl:operation name="validatePatient">

<wsdlsoap:operation soapAction=""
      <wsdl:input name="validatePatientRequest">
      <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
      namespace="http://remote.patient.services" use="encoded"
      <wsdl:output name="validatePatientResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
use="encoded" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"/>
<wsdl:operation name="registerNewPatient">
<wsdlsoap:operation soapAction=""
      <wsdl:input name="registerNewPatientRequest">
      <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
      namespace="http://remote.patient.services" use="encoded"
      <wsdl:output name="registerNewPatientResponse">
      <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
      use="encoded" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"/>
<wsdl:operation name="removePatient">
<wsdlsoap:operation soapAction=""
      <wsdl:input name="removePatientRequest">
      <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
      namespace="http://remote.patient.services" use="encoded"

               <wsdl:output name="removePatientResponse">
               <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               use="encoded" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"/>
      <wsdl:operation name="getAllPatients">
      <wsdlsoap:operation soapAction=""
               <wsdl:input name="getAllPatientsRequest">
               <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="http://remote.patient.services" use="encoded"
               <wsdl:output name="getAllPatientsResponse">
               <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               use="encoded" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"/>
<wsdl:service name="JaxRpcPatientServiceService">
<wsdl:port name="PatientService" binding="impl:PatientServiceSoapBinding">
      <plnk2:partnerLinkType xmlns:plnk2="http://docs.oasis-
      open.org/wsbpel/2.0/plnktype" name="AllLT">
               <plnk2:role name="ObtenedorPacientes"


E.1. Code from TransferPatients Web Service

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="TransferPatients" targetNamespace="TransferPatients"
xmlns:tns="TransferPatients" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
       <wsdl:message name="Output">
              <wsdl:part name="Complete" type="xsd:boolean"/>
       <wsdl:message name="Input">
       <wsdl:portType name="TransferPort">
              <wsdl:operation name="TransferAllPatients">
                      <wsdl:input message="tns:Input"/>
                      <wsdl:output message="tns:Output"/>
<plnk2:partnerLinkType xmlns:plnk2="http://docs.oasis-open.org/wsbpel/2.0/plnktype"
       <plnk2:role name="AdministradorGeneral" portType="tns:TransferPort"/>


To top