Service-Oriented Business Processes with BPEL
by Thomas Erl

The ability to compose legacy and contemporary resources into coordinated sequences allows for the design of sophisticated business automation solutions, such as those traditionally provided by EAI products. Process integration into a service-oriented architecture, however, is best facilitated by a service-oriented process.

A number of business process dialects have emerged over the past few years. IBM released the Web Services Flow Language (WSFL), and Microsoft provided the XLANG standard. Sun and Oracle collaborated to produce the Web Service Choreography Interface (WSCI), and both IBM and Microsoft went on to combine their efforts and created a successor to both WSFL and XLANG, called BPEL.

Subsequently, the Organization for the Advancement of Structured Information Standards (OASIS) formally announced their support for BPEL by forming a governing body called the OASIS Web Services Business Process Execution Language (WSBPEL) technical committee.

The Business Process Execution Language for Web Services provides a comprehensive syntax for describing business workflow logic. It allows for the creation of abstract processes that can describe just the business protocols, as well as executable processes, that can be compiled into runtime scripts.

An executable process encapsulates the process description within a Web service. The BPEL document essentially describes the sequence and logic behind other services managed by the process. Middleware server products use orchestration engines to implement executable process descriptions within vendor-specific platforms.

A BPEL process description incorporates numerous language constructs that can accommodate most traditional workflow requirements. The WSDL document representing the BPEL process contains interfaces (previously portTypes) for the process service itself, as well as any additional services involved with the execution of the process.

Unlike regular WSDL documents, however, the service definition for a BPEL process provides no binding information. It is intentionally implementation-neutral so that the process can remain mobile, reusable, and independent from changes to the technical deployment environment.

BPEL relies on WS-Coordination to provide a fundamental context-management framework. The business activity coordination type, as defined by WS-Transaction, is utilized to establish a standard mechanism for managing long-running activities.

BPEL relies on the following additional standards:

• XPath as a standard location syntax, for which BPEL also provides two extensions

• WS-Addressing for standardized address format representation

• XML Schema Definition Language, providing datatypes that can be used for BPEL variables, and definitions for each primary BPEL construct

A BPEL process can relate to other Web services in two ways:

1. The process service can be invoked or accessed by services external to the process.

2. Alternatively, the process service itself can invoke and interact with services that participate in the execution of a process.

Services that participate with a process are referred to as partner services, and are defined within the process description.

Once a BPEL process has been invoked, an instance of this process remains in existence until execution has completed. Therefore, two interaction scenarios exist between the process services and external partner services:

• the partner service can invoke a new instance of a process

• the partner service can interact with an existing process instance

The latter scenario is accomplished through message correlation.

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. Basic activities provide primitive workflow functions. Examples include:

• receive

• invoke

• reply

• throw

• wait

The first three (receive, invoke, and reply) enable interaction between a process service and partner services. When certain conditions are encountered by the process, exception handling routines can be executed. The throw activity forces a fault condition that shifts processing to the corresponding logic.

A form of scheduled execution can be provided using the wait activity. It essentially suspends processing of the overall activity for a specified amount of time, or until a certain date or time is reached.

BPEL also supplies a set of structured activities that allow for the creation of workflow logic:

• sequence

• flow

• switch

• while

Structured activities essentially determine how basic activities are utilized. The order in which they are to be executed can be set using the parent sequence activity. This establishes a construct hosting a list of other activities that are launched in the sequence in which they appear. In contrast, the flow activity construct contains a list of activities that can be executed concurrently.

The switch and while activities provide conditional logic constructs, similar to the traditional select-case statement and the do-while loop, respectively.

Below is a simple scenario involving an external partner service, the BPEL process service, and an additional service invoked by the process.

1. An external partner service contacts the BPEL process service by sending it a message. The receive activity within the process description establishes an entry point for a message from this partner (A).

2. The logic within the process description then reacts to the arrival of this message by applying the invoke activity to interact with another partner service (B).

3. Once the invoke activity has completed, the process service responds to partner A’s original request using the reply activity.

Let’s take a closer look at a the internal structure of a process description.

This process root element hosts the entire process definition:

<process name="MyProcess"...>
   <partnerLinks>
     ...
   </partnerLinks>
   <variables>
     ...
   </variables>
   <faultHandlers>
     ...
   </faultHandlers>
   <sequence>
     ...
   </sequence>
</process>

A process definition can consist of collections of the following constructs:

• partnerLinks

• variables

• faultHandlers

• sequence

Let’s discuss each of these individually.

The partnerLinks collection of partnerLink constructs is used to represent partner services. This element assigns services a name used within the context of the process, and also allows for the allocation of roles.

<process name="MyProcess"...>
   <partnerLinks>
     <partnerLink name="OrderEntry" ...>
       ...
     </partnerLink>
     <partnerLink name="InventoryControl" ...>
       ...
     </partnerLink>
   </partnerLinks>
</process>

Many business processes will involve long-running tasks, often due to various intermediate conditions that must be met before the execution of the process can continue. In order to support lengthy process lifespans, a state information management system is required. For this purpose, BPEL provides the variables element.

Within this construct you can establish variables with different scopes using individual variable element declarations. Variables that are global can be accessed from anywhere in the process definition. Variable values typically consist of messages that contain some piece of state information.

<process name="MyProcess"...>
   <variables>
     <variable xmlns:ORD="http://www.examples.ws/"
       name="OrderStatus"
       messageType="x:OrderStatus"/>
   </variables>
</process>

When a long running business activity fails, a business process will typically revert to a compensation process — a form of exception handling that is encapsulated within the faultHandlers construct.

Using nested catch constructs, you can define different responses for various error conditions.

<process name="MyProcess"...>
   <faultHandlers>
     <catch faultName="x:condition1" faultVariable="err001">
       ...
     </catch>
     <catchAll>
       ...
     </catchAll>
   </faultHandlers>
</process>

Finally, let’s revisit our original interaction scenario that demonstrates the use of the receive, invoke, and reply activities. We’ll nest each activity construct within the sequence element in order to establish the order of execution.

<process name="MyProcess"...>
   <sequence>
     <receive partner=”partnerA”>
       ...
     </receive>
     <invoke partner=”partnerB”>
       ...
     </invoke>
     <reply partner=”partnerA”>
       ...
     </reply>
   </sequence>
</process>

Note the use of the partner attributes. Partner interaction is predefined within process workflows.

SOA Design Patterns by Thomas Erl
Foreword by Grady Booch
With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.
Web Service Contract Design & Versioning for SOA by Thomas Erl, Anish Karmarkar, Priscilla Walmsley, Hugo Haas, Umit Yalcinalp, Canyang Kevin Liu, David Orchard, Andre Tost, James Pasley
SOA Principles of Service Design by Thomas Erl
Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services by Thomas Erl
Service-Oriented Infrastructure:On-Premise and in the Cloud by Raj Balasubramanian, Benjamin Carlyle, Thomas Erl, Cesare Pautasso
Next Generation SOA:A Real-World Guide to Modern Service-Oriented Computing by Pethuru Cheliah, Thomas Erl, Clive Gee, Robert Laird, Berthold Maier, Hajo Normann, Leo Shuster, Bernd Trops, Clemens Utschig, Torsten Winterberg
SOA with .NET & Windows Azure: Realizing Service-Orientation with the Microsoft Platform by David Chou, John deVadoss, Thomas Erl, Nitin Gandhi, Hanu Kommalapati, Brian Loesgen, Christoph Schittko, Herbjorn Wilhelmsen, Mickey Williams
SOA Governance:
Governing Shared Services On-Premise & in the Cloud
by Stephen Bennett, Thomas Erl, Clive Gee, Anne Thomas Manes, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable
SOA with Java by Raj Balasubramanian, David Chou, Thomas Erl, Thomas Plunkett, Satadru Roy, Philip Thomas, Andre Tost
Modern SOA Methodology: Methods for Applying Service-Orientation On-Premise & in the Cloud by Raj Balasubramanian, David Chou, Thomas Erl, Thomas Plunkett, Satadru Roy, Philip Thomas, Andre Tost
Cloud Computing: Concepts, Technology & Architecture by Thomas Erl, Zaigham Mahmood, Ricardo Puttini
Cloud Computing Design Patterns by Thomas Erl, Amin Naserpour

For more information about these books, visit: www.servicetechbooks.com


Arcitura Education Inc.
Arcitura Education Inc. is a leading global provider of progressive, vendor-neutral training and certification programs, providing industry-recognized certification programs for a range of certifications.
For more information:
www.arcitura.com
SOA Certified Professional (SOACP)
The books in this series are part of the official curriculum for the SOA Certified Professional program.
For more information:
www.soaschool.com
Cloud Certified Professional (CCP)
The books in this series are part of the official curriculum for the Cloud Certified Professional program.
For more information:
www.cloudschool.com
Big Data Science Certified Professional (BDSCP)
The books in this series are part of the official curriculum for the Big Data Science Certified Professional program.
For more information:
www.bigdatascienceschool.com/