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.