 by Thomas Erl |
WS-* Specifications |
 |
|
|
Service-Oriented Business Processes with BPEL |
|
| 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 BPEL4WS. |
| Subsequently, the Organization for the Advancement of Structured Information Standards (OASIS) formally announced their support for BPEL4WS by forming a governing body called the OASIS Web Services Business Process Execution Language (WSBPEL) technical committee. Although competing standards are still in use, we will focus on the BPEL4WS specification in order to demonstrate how business process logic can be encapsulated within a Web service. |
| 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 BPEL4WS 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 BPEL4WS process description incorporates numerous language constructs that can accommodate most traditional workflow requirements. The WSDL document representing the BPEL4WS 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 BPEL4WS 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. |
| BPEL4WS 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. |
| BPEL4WS relies on the following additional standards: |
|
• XPath as a standard location syntax, for which BPEL4WS also provides two extensions |
|
• WS-Addressing for standardized address format representation |
| • XML Schema Definition Language, providing data types that can be used for BPEL4WS variables, and definitions for each primary BPEL4WS construct |
| A BPEL4WS 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. |
|
SOA: Principles of Service Design by Thomas Erl  An in-depth guide dedicated to service engineering with a thorough exploration of the design principles that comprise the service-orientation design paradigm (including a comparison with object-orientation). 
Service-Oriented Architecture:Concepts, Technology, and Design by Thomas Erl The first "how-to" guide to building SOA, providing coverage of WS-* specifications, .NET and J2EE platforms, and step-by-step processes for service-oriented analysis and design. 
Service-Oriented Architecture:A Field Guide to Integrating XML and Web Services by Thomas Erl The best-selling guide to service-oriented integration, providing hundreds of integration strategies and over sixty best practices. For more information about either book, visit: www.soabooks.com |
About SOA Systems
SOA Systems Inc. provides strategic SOA consulting services and offers a comprehensive SOA training program. For more information see: • www.soasystems.com • www.soatraining.com |
| 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 BPEL4WS 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 BPEL4WS 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. |
| BPEL4WS 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 BPEL4WS process service, and an additional service invoked by the process. |
|
| 1. An external partner service contacts the BPEL4WS 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, BPEL4WS 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.
|
|
|
|
|
|
|
| Home | Copyright © 2003-2007 SOA Systems Inc. |