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:
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:
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:
A process definition can consist of collections of the following constructs:
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.
<partnerLink name="OrderEntry" ...>
<partnerLink name="InventoryControl" ...>
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.
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.
<catch faultName="x:condition1" faultVariable="err001">
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.
Note the use of the partner attributes. Partner interaction is predefined within process workflows.
- The WS-Coordination Context Management Framework
- Cross-Service Transactions with WS-AtomicTransaction
- Long-Running Transactions with WS-BusinessActivity
- An Overview of the WS-Security Framework
- Service-Oriented Business Processes with BPEL
- Building a Communications Framework with WS-Policy and WS-ReliableMessaging
- Defining the Web Service with WSDL
- An Inside Look into SOAP Messaging
- UDDI In and Out of the Enterprise
- A W3C Web Services Glossary
- Understanding WS-Policy Part I: Operator Composition Rules and Attachments
- Understanding WS-Policy Part II: Operator Composition Rules and Attachments
- Web Service Contract Versioning Fundamentals Part I: Version Identifiers and Versioning Strategies
- Web Service Contract Versioning Fundamentals Part II: Version Identifiers andVersioning Strategies
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.
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
For more information about these books, visit: www.servicetechbooks.com