Section 14.3. BPEL Processing Model

14.3. BPEL Processing Model

The previous sections explained the different aspects that make up a process. This section delves into the runtime aspects of BPEL processes.

14.3.1. Deployment

A BPEL process exposes zero or one portType along each partnerLink ("myRole"). After the portTypes are deployed, they must be made available for invocations from the partners. With WSDL specifying that one portType corresponds to one port with the address of the available service, engines that deploy BPEL processes are expected to create such ports. The BPEL specification does not specify a deployment approach or syntax for a deployment descriptor.

The engine or workflow system to which a process is deployed is responsible for creating instances based on the instance creation activities and maintaining conversations between each of these instances and their partners, usually using correlation sets. The approach or interfaces that bind to partners at deployment time or specify locators for their binding to happen at runtime, such as in 14.2.3.2, are omitted from the BPEL specification. The workflow systems must present and support such approaches.

14.3.2. Interacting with the Process

After you deploy a process, partners interact with it by invoking the operations it offers them. The first of such invocations, targeted at an instance that creates receive or pick activity, creates an instance of the process and registers the values of correlation properties that are initialized at that point in time. The interaction activities of a process specify which variables to read outgoing messages from and which variables to write incoming messages to.

The messages in invocations of a process's operations are eventually consumed by a running receive activity, pick activity, or event handler. After an activity starts running, it waits for a message to arrive that it can consume, saves it in a specified variable, and completes. To disambiguate which activity might consume an incoming message, only one receive/pick/onMessage with the same partnerLink, portType, operation, and correlation set can be running at the same time. If the operation is request-response, a subsequent reply activity must exist further downstream in the process. After the reply activity executes, a response is sent to the invoker, and the call is complete.

The environment checks incoming messages for correlation information and determines whether they match an existing instance, or whether it has to create a new instance, or do neither. You can also use correlation to validate business data. For example, if you use a middleware-generated opaque token to identify process instances but the process that it refers to uses correlation sets, you can view the correlation information as a business-level check of the validity of an incoming message.

The invocations that a process instance sends to its partners are blocking. An invoke activity that corresponds to a request-response WSDL operation begins by sending a request and ends after it has received the response. The invoke activity specifies which data variable to read the request message from and which optional variable to write the response into. By the time an invoke activity must run, it must know the endpoint of the partner link to send the message to. As noted in section 14.2.3.2, multiple schemes are available for binding partnerLinks to actual deployed endpoints.

The result of an invocation might include an endpoint reference that you can copy using an assign activity to one of the process's partnerLinks. In this case, the process will use the new endpoint reference for all further interactions along that partnerLink. You can use an invoke activity to lookup an endpoint of a partner in a registry; that lookup is followed by an assign activity to copy the endpoint reference into a partner link.

14.3.3. Navigating the Process Model

Control flow in BPEL, as noted earlier, is defined using a combination of structured activities and control links. You can only define control links inside of a <flow> activity, at arbitrary levels of nesting. An activity must wait to proceed until it knows all the link values of its incoming links. The topmost activity of a process has no incoming link, thus it is started once you create an instance of the process.

To understand the processing model of the activity lifecycle, consider the states that a BPEL activity must go through. At first, all activities are in a default state. After an activity gets control from its parent (structured) activity and all its incoming links have fired, it evaluates its join condition to see whether it can run. If the join condition is TRue, the activity starts running. If it is a structured activity, its execution consists of running its child activities according to the prescribed semantics. After the activity completes successfully, it fires all its links with the values that result from the evaluation of their respective TRansitionConditions. For example, a sequence that has two activities begins by activating its first activity. After that first activity runs to completion, the sequence activates its second activity. After the second activity completes, the sequence is finished. Note that already completed activities might need to run again because of being contained in while loops.

Sometimes an activity gets disabled, either because it faulted while it was running or because it is within a part of the process that no longer runs. The former includes activities whose join condition evaluates to false. The latter includes activities in an untaken branch of a switch or in a scope that faulted. In such situations, the activity's outgoing links fire with negative values.

Dead Path Elimination

A BPEL flow activity contains a directed acyclic graph where the nodes are other activities and the edges are the links that define a partial execution order of the activities. When multiple links have the same target activity, multiple parallel execution paths are joined before this target activity is considered to run. A join condition determines whether the target activity is actually eligible for execution. When join conditions evaluate to false, you have two options: raising a fault or continuing to navigate through the flow. You can use both in BPEL. The actual behavior is determined by the suppressJoinFailure attribute of the process or an individual activity.

Figure 14-6. Flow graph and dead-path elimination.

Study the figure. If you suppress join failures by setting the corresponding attribute, the navigation of the flow continues with dead-path elimination (cf. [Ley 2000] for more details). The activity with the false join condition (see "Get Discount") is skipped, and the status of all outgoing links is set to false. For each of these links, this step is repeated for subsequent activities (see "Rush Shipment") until a join condition is reached that can be evaluated to not false. In the figure, this occurs at "Prepare Result" which can run successfully.

14.3.4. Scopes and Handlers

Scopes are the only structured activities that have activities both nested within them as well as attached to them in the form of handlers. Scopes also define data. BPEL variables are always referred to by name, and that name refers to the variable in the nearest enclosing scope.

After a scope starts running, it gives control to its enclosed activity and enables all its event and fault handlers. After a scope completes, it deactivates those handlers. If a scope completes successfully, it enables its compensation handler.

Activities in an event handler routine run concurrently as many times as the handler is triggered. The scope that the handler is defined on remains active.

Fault Handling and Compensation

If a fault occurs within a scope, the scope stops execution, disables its enclosed activities, and negatively fires all unevaluated links whose sources are in the scope but targets are outside of it. If the scope has a handler for the fault, the activities in the fault handler routine execute. Otherwise, the fault is thrown up the scope hierarchy until a handler is found to remedy the situation. If the fault reaches the process root and doesn't find a handler, it terminates the entire process.

Each fault handler of a scope can initiate the reversal of previous activity results by invoking compensation handlers for its nested scopes. This applies only to nested scopes that successfully terminated on their normal execution path. Figure 14-7 illustrates the interplay between fault and compensation handlers. Here, an activity in the main process scope throws a fault after the successful completion of scopes 1 and 2. The fault is caught by the process-level fault handler, which calls the compensation handler of scope 1, which in turn calls the compensation handler of scope 2. After the compensation and any additional processing in the process-level fault handler are completed, the process instance terminates.

Figure 14-7. Fault handling and compensation.

The compensation handler for a scope can operate only on a snapshot of the data that was taken at the time the scope terminated normally, and not on live data of the running process instance. However, the activities in a compensation handler might invoke operations that undo external effects of the activities executed in the normal path of the scope. If no compensation handler is defined for a scope, an implicit compensation handler invokes the compensation handlers of nested scopes in reverse order of their former completion.