Section 14.2. Architectural Concepts

14.2. Architectural Concepts

As described in section 14.1, BPEL was created to address the requirements of composition in a service-oriented computing environment. This section describes the architectural concepts of the language in which these requirements are reflected.

This section first provides an overview of BPEL's service composition model and the elements that make up a BPEL process. Then it explains BPEL's recursive type-based composition model and describes process instance lifecycle. The rest of this section handles advanced capabilities, including event handling, dealing with exceptional behavior, and using Web services policies to attach quality of service to a BPEL process.

14.2.1. Overview of the Process Composition Model

The major building blocks of BPEL business processes are nested scopes that contain relationships to external partners, declarations for process data, handlers for various purposes and, most importantly, the activities to be executed. The outermost scope is the process definition.

Data in BPEL is written to and read from lexically scoped, typed variables. The values of these variables are either messages exchanged between the process and its partners, or intermediate data that is private to the process. In keeping with the Web services framework, BPEL variables are typed using WSDL message types, XML Schema [XML Schema] simple types, or XML schema elements. XPath is the default language for manipulating and querying variables.

Data can be read or written by activities that exchange messages between the process and its partners or by specific activities that manipulate process-data (so-called assign activities). Conditional expressions also read data. BPEL contains several expression types that are used for different purposes, such as defining conditions (Boolean expressions), expressing time intervals and dates (duration and date expressions), and accessing values of variables in the assign activity (general expressions).

The activities in a BPEL process are either structured or basic. Structured activities contain other activities and define the business logic between them. Basic activities are, for example, the inbound or outbound Web service interactions or the specific activities for data manipulation.

Activities that deal with Web services are receive, reply, pick, invoke, and event handlers. These activities allow a process to exchange messages with the services that it composes. They are discussed in detail in section 14.2.3, "Recursive, Type-Based Composition."

The assign activity atomically copies data from one location to another, using a list of copy statements that copy one value each. The common usages of an assign activity include constructing values by copying them from XPath expressions into a part of a variable, copying data from the part of one variable into a part of another, and copying endpoint references so that they can be exchanged between the process and its partners. This last case is the enabler of dynamic partner assignment in BPEL.

Structured activities combine multiple activities to provide higher-level business logic. These include sequence, switch, while, and flow activities. The sequence activity is a simple aggregation of activities executed in the order in which they are specified. The switch activity provides a multibranch decision construct, and the while activity provides a loop construct. Both switch and while have semantics from corresponding programming language constructs, such as Java. You can execute activities in parallel by nesting them in a flow activity. If you have to constrain the degree of parallelism, you can use conditional control links to specify a partial (acyclic) order on the set of activities nested in a flow.

Figure 14-1 illustrates how to create a business process for the service pack validation (SPK) example using several of these constructs. You can see the receive activity and its reply further downstream, in addition to several invocations that invoke the specialized validators. Surrounding these and imposing control, you see a sequence activity that imposes order on the validation and the purchasing, several nested while loops, and a scope that surrounds the purchasing section at the end.

Figure 14-1. Structured activities.

A transition condition is associated with each control link and evaluated at completion of the link's source activity. This condition has a default value of true, but you can use any Boolean expression that relates to the values of data fields and other states of the process. On the other hand, a join condition is associated with an activity that is a target of links. It is a Boolean expression in terms of the link values. It is evaluated after you know all incoming link values and it must evaluate to TRue to run the activity. A joint condition's default value is an or. These concepts are illustrated in Figure 14-2, in which four activities are joined with control links.

Figure 14-2. Links, transition conditions, and join conditions.

In addition to Web service interactions and nested structured activities, you can use a couple more basic activities to specify different types of behavior. These activities are called empty, wait, terminate, tHRow, and compensate. The empty activity is BPEL's rendering of a no-op. You can use it as a placeholder for other activities that you add later. The wait activity provides a means to interrupt the execution for a specified time interval or until a specified time has been reached, and the terminate activity stops the execution of the process immediately. Finally, the throw and compensate activities are used in conjunction with handlers for error detection and recovery, which will be discussed later.

A BPEL process might contain handlers to recognize unexpected problems and deal with them. These handlers can include operations that reverse effects from other activities that have been completed successfully before an error situation occurred.

The constructs that BPEL provides present a rich toolbox with which to create both simple and sophisticated business processes. In the sections that follow, you see how to create and use BPEL processes.

14.2.2. Abstract and Executable Processes

BPEL supports two fundamental usage patterns. One pattern is for describing business protocols called abstract processes, and the other is for describing executable processes. Business protocols or message exchange protocols describe the externally visible interactions between business partners without necessarily exposing the internal business logic of the individual partners. In contrast, executable processes contain the partner's business logic behind the external protocol.

An enterprise might present abstract processes of the existing business processes that it offers to its partners so they can know how to interact with it. The abstraction enables the enterprise to keep its private mechanisms internal while still providing the partners with the information they need. You can think of an abstract process as a projection of an executable process.

On the other hand, for a certain domain just an abstract process can be made publicly available. Service providers that want to supply the specified functionality then derive executable processes that comply with it.

BPEL provides the same language constructs to define both abstract and executable processes. Both processes have a few additional constructs that are an extension of the base language and can be used only in that variant. For example, abstract processes might have "opaque" variable assignment, to signify that a value is set but that how or what that value is remains up to the internal implementation.

14.2.3. Recursive, Type-Based Composition

A BPEL process refers to the parties that it is interacting with as partners. It interacts with each partner along a set of partnerLinks. Partner links are instances of typed connectors that specify the portTypes that the process offers to and requires from the partner at the other end of the link. You can think of a partnerLink as a channel along which a peer-to-peer conversation with a partner takes place.

The composition model is recursive: The portTypes that the process offers form (one or more) Web services with a WSDL interface. The bindings and ports for those portTypes might be specified at deployment time, depending on where the service is deployed.

To illustrate, the client and the service pack validator in the running example of this chapter can both be Web services with a callback on the purchase operation. The validator offers the "purchaseServicePacs" operation to the client, and the client offers the "purchaseServicePacsResp" operation to the validator. Therefore, the validator BPEL contains a partnerLink connecting the two respective portTypes, as illustrated in Figure 14-3.

Figure 14-3. Partner links.

Composing Services

BPEL's composition model is type based, meaning that services are composed at the portType and not at the port/instance level. A BPEL process provides control semantics around receive, reply, and invoke activities. Each of these activities specifies the partnerLink-portType operation and the variables that it relates to.

An input-only operation that a BPEL process provides corresponds to a receive activity in the process that explicitly marks the place in the business process logic where the inbound request message is accepted. For request-response operations, a corresponding reply activity is the place where the response message is handed back to the Web services client. If a process provides multiple operations, then multiple receive activities indicate that you must take all entry points into the process. Alternatively, a pick activity can refer to multiple operations to indicate that, at most, one entry point is taken. Later, you'll learn more about concurrent entry points that event handler activities define. Outbound calls to Web services that entities offer outside of the process are expressed as invoke activities.

To summarize, the invoke activities always refer to the operations that the partners offer. Therefore, in Figure 14-3, you see that the client has an invoke that refers to the validator's "purchaseServicePacs" operation. On the other hand, receive/pick/onMessage and their (optional) corresponding reply activities refer to the operations that the process offers to its partners. These are the operations included in the WSDL portType(s) of the process. Again, you can see this in Figure 14-3, where the receive that consumes the purchase request in the validator's BPEL refers to its own "purchaseServicePacs" operation.

Binding to Concrete Endpoints of Partner Services

BPEL decouples the business logic from the available service endpoints, allowing processes to be more adaptive and more portable. When a process must execute, however, you must be able to bind each partnerLink along which a partner is invoked to a concrete endpoint. Four binding schemes and their combinations are possible:

• Static design time binding A process might be bound to known endpoints as part of the process logic. This is the least flexible form of binding. This binding proves useful when the endpoints are meant to be parts of the business logic. (That is, this process is made only for bank such-and-such.) Every deployment and every instance of this process will use the specified endpoint(s). For this form of deployment, an assign activity explicitly puts an endpoint into a variable. A subsequent <assign> activity then copies the value of that variable into the process's reference to a specific partnerLink.

• Static deployment time binding In this instantiation, the process model does not refer to explicit endpoints, but a set of endpoints is defined at deployment time to the workflow management system into which the process is deployed. This form is useful if all instances of a particular deployment of a process must use the same endpoints.

• Dynamic binding using lookups In this form of binding, criteria are defined on a partnerLink that a viable endpoint must have. These criteria are evaluated either at runtime or deployment time to search for providers whose deployed services match. Such criteria might include quality-of-service policies (cost, security, speed), transactional capabilities, or functional requirements that are not in the WSDL portType. The location of the endpoints is the responsibility of the environment in which the process is deployed or executed.

• Dynamic binding using passed-in endpoints The last form of dynamic binding includes the process copying in an endpoint from a variable that was previously assigned not by the process, as in (1), but by either a response to an invocation (result of an invoke activity) or a request from a partner (input to a receive activity). The latter is illustrated in Figure 14-4. The process uses the assign activity as in (1) to copy that value into its reference to the partnerLink in question.

  Figure 14-4. Dynamic binding of partner links.

  
  
  

A Conversational Approach

It was stated earlier that a receive or a receive/reply activity pair maps to one WSDL operation exposed to the partners, with the conceptual implementation of that operation being the part of the process that is executed as a result of the receive. In the case of a request-response operation, that is logically the block between the receive and its corresponding reply. For example, in Figure 14-1, you can see the implementation of the "validateSPKs" operation that the process offers between the first receive and the first reply, both of which refer to that operation.

Having different activities for incoming and outgoing messages and breaking up a request-response operation by using receive/reply enables BPEL to support a conversational pattern of composition and interaction with the partners. In BPEL, the activities between the receive and the reply might include other receives, even from the same partner along the same partnerLink, and other invokes. It's like natively being able to call a method within a method.

Depending on the process design, the process, thus, might be a controlling entity, a player on an equal footing with its partners, or a mix of the two. The result is the capability to model a wide range of relationships between a process and its partners, from peer-to-peer to master/slave.

A key architectural enabler is the bidirectionality of partnerLinks. A conversation occurs along each partnerLink for each process instance. That conversation is potentially two sided. The process instance invokes the partner, and the partner invokes the process instance. The lifetime of a conversation is the lifetime of the entire process instance, and you can see the different conversations of an instance through the specification of which partnerLink each interaction activity refers to. In BPEL, only one endpoint is active at any one time at each end of the partnerLink (one being the process instance and the other being the instance of the partner). Although that can change at different points in time because of such things as dynamic assignment, it changes for the entire instance and not only for the lifetime of one operation invocation.

Process Views

Offering possibly different portTypes along each partnerLink, the process can expose to each partner only the functionality that is relevant to it. One BPEL process might be exposed as one or more Web services, each service being a view on the entire process. This provides the separation of concerns of a process's provided functions.

For example, consider a process whose functions include sending requested payments to utility companies and providing auditors with a summary of payment activity. Using BPEL, such a process could publish only the payment portType to the utility companies and only the auditing portType to the auditors. This way, the utility companies do not need to know or care about the auditing capability, and the auditor cannot call the payment functions that are not meant for him.

Likewise, the partner might not need to know about the process's interactions with other entities. In addition to providing for each partner an abstract WSDL view of the parts of the process that the partner is involved with, you can go a step further with BPEL and accompany that WSDL view with the definition of an abstract process showing the parts of the process that the partner is concerned with. Such an abstract process might be simply a projection of the interaction activities that are concerned with that partner. Of course, this is not always necessary. Other options include exposing the whole executable process, exposing an abstract variant that shows interactions with multiple partners and is visible to all, or completely hiding the process based on the circumstances and the goals that the process was created to fulfill.

14.2.4 Process Instance Lifecycle

Business processes that are defined in BPEL represent stateful Web services, and as such, they might have long-running conversations with other Web services. Whenever you start a new BPEL process, a new instance of that process is created, which might communicate with other business partners. Web service definitions in WSDL are always stateless, so the messages that are exchanged in long-running conversations must be correlated to the correct business process instance. BPEL offers the concepts that allow correlating application data to process instances.

After you define and deploy a process, you can create multiple instances of it. All the instances can run concurrently and completely independently of each other. This section considers how such instances are created, destroyed, and identified at runtime.

The creation and destruction of BPEL process instances is by design implicit. In some workflow systems, each process has an explicit start and end activity. In BPEL, however, this restriction is not needed and multiple activities in a process model can kick off a process instance. You must tag these activities with the capability of instance creation by setting the createInstance attribute to yes. These activities must be able to receive messages (receive, pick) and come near the beginning of the process so they can be navigated to as soon as the instance is created. An instance can be created if a partner invokes an operation of the process that corresponds to one of these activities. The condition is that no active instance that already existed could consume the incoming message (see section 14.2.4.1 that follows next). After an instance is created, the "createInstance" attribute on any other activities than the one that created it loses its creation potency.

An instance terminates when its last activity completes, a terminate activity executes, or the instance experiences a fault from which it cannot recover. Figure 14-5 summarizes instance creation and termination in a BPEL process.

Figure 14-5. Process instance lifecycle.

Correlation

After you create an instance encompassing multiple receives, you have to figure out how to route subsequent messages to the correct created instance. In traditional middleware systems, you do this using opaque tokens that the middleware generates and maintains. BPEL, however, defines an (optional) correlation mechanism to enable you to do just that using parts of the application data. Two items make up these mechanisms: properties and correlation sets.

Typed properties that are named and mapped (aliased) to parts of several of the WSDL messages that the process uses are defined in WSDL. For example, to use a person's name as correlation identifier, you would define a property called "name" of type "xsd:string" that is aliased to the "name" field in the clientInformation part of a "validateServicePacks" WSDL message and the "lastName" part of a "purchaseOrder" WSDL message. These messages could be inputs to two different operations.

BPEL correlation sets are groups of these properties that identify which process instance an incoming message should be routed to. Zero or more correlation sets might subsequently be attached to the interaction activities (receive/reply/invoke) with a flag on whether the activity will initiate the set's data. With invoke, you must also specify whether you are initiating it based on the outgoing request message or the incoming response message. Initiating a correlation set corresponds to setting the values of the properties for a particular instance. You can then use values in incoming messages to look up the instance that the message is directed to by matching against the values of correlation sets of active instances.

For example, consider that the receive activity on the "validateSPKs" operation shown in Figure 14-1 creates an instance of a process and initiates a correlation set containing the "name" property. Assume that a message "A" comes in for the process and matches that receive activity. An instance is created, and the alias is used to find the "name" in the incoming message and copy it into the value of that property. Subsequent referrals to that property will have that value. More importantly, the correlation set with that value for the name property will be registered as a key to that particular instance.

Now consider that the other receive on the "purchaseServicePacs" operation further downstream refers to the same correlation set. A message comes in for that receive activity with the same name. The workflow engine looks up the name field and finds that the message must go to the same process instance as the one that message "A" had created earlier.

Correlation is a powerful concept. It enables you to maintain conversations between process instances and their partners using clearly defined and aliased portions of the application data. You can use multiple correlation sets to point to the same process instance, using different groups of properties. This enables a process instance to use different sets of identifiers for each partner or for different parts of a conversation.

If you use opaque middleware tokens for routing, correlation still enables validation of the business logic in ensuring that certain pieces of data have the same value in each instantiation of a process. One example is validating that the same account number is used in all of a person's interactions with an instance of an ordering process.

14.2.5. Event Handling

A BPEL process provides one or more Web service interfaces. In addition to the interfaces that are implemented by receive or pick activities in the regular flow, BPEL provides a means to deal with asynchronous events, which are handled concurrently to the execution of the process. These constructs are associated with the process as a whole or with a scope, and they are called event handlers.

You can use event handlers in BPEL for message events and timer-driven alarm events. For the outside world, message events are regular one-way or request-response Web service operations that the business process implements. Alarm events occur whenever a specified time is reached or a specified time interval expires. Both types of event handlers can contain any BPEL activity.

As an example, you can use event handlers to monitor the progress of a business process. For this purpose, the event handler is modeled as a request-response operation, in which the request specifies a query expression, and the response contains process instance status data that corresponds to the query.

14.2.6. Dealing with Exceptional Behavior

Because BPEL processes are composed out of Web services, they have to deal with faults that are a result of Web services invocations. Likewise, because BPEL processes implement regular Web services, they might return exceptional situations as faults to the invokers of these Web services. Finally, abnormal behavior might be recognized within the business logic, either raised explicitly or recognized by the BPEL runtime infrastructure.

Business processes can be long running. As a consequence, you cannot always execute them as a single atomic operation. Results of intermediate process steps are made persistent and may be visible to others. When a fault occurs in such a long-running business process, you have to undo work that is partially or successfully completed.

Within a BPEL process, the construct that is associated with handling fault situations and reversing intermediate results is the scope, which you can consider as an encapsulation of a recoverable and reversible unit of work. You deal with faults by using fault handlers. Undoing work is the responsibility of compensation handlers. Both handlers are either implicit or are explicitly provided by the process modeler.

In addition to these concepts that are local to a business process, abnormal behavior sometimes occurs between multiple business processes. Again, you either can achieve an all-or-nothing behavior, or you need explicit means to reverse results of work that have already been persisted. In the environment of distributed, multiplatform, multivendor business transactions, all-or-nothing behavior is described by the WS-AtomicTransaction [WS-Atomic Transactions] specification, and exception handling in long-running business transactions is described by the WS-BusinessActivity [WS-Business Activity] specification.

Fault Handling

The primary purpose of a fault handler is to catch faults and reverse partial and unsuccessful work. In a BPEL process, faults can originate from different sources. A fault can be the result of a Web service invocation, or it can be thrown explicitly from within the business logic. Furthermore, the BPEL specification lists numerous situations in which the BPEL infrastructure must detect and signal faults, such as when a BPEL variable is used before a value has been assigned to it.

For faults that are returned from a Web service invocation, the Web service interface defines a fault message that allows data to be passed along with the fault. Within the process, you can also raise faults without associated fault data. BPEL fault handlers can deal with both and can examine the fault data.

When a fault handler catches a fault, the regular processing within a scope stops, and exception processing begins. Therefore, in a BPEL process, fault handling is considered a mode switch from doing regular work to repairing an exceptional situation.

Compensation

The BPEL specification mandates a particular transaction model for executing business processes: In many business processes you cannot complete all work within a single atomic transaction, because processes are long-running business transactions in which many committed ACID transactions create persistent effects before a process is completed. Application-specific compensation steps undo these effects when necessary.

In a BPEL scope, the compensation handler reverses completed activities. You can invoke the compensation handler after successful completion of its associated scope, using the compensate activity. You can perform the invocation of a compensation handler either from a fault handler or from the compensation handler of the enclosing scope.

In its first version, the BPEL compensation handler cannot change data within the business process. The activity that is enclosed in a compensation handler typically consists of one or more Web service invocations that undo effects of other previously called Web services.

Compensation and Business Agreement Protocols

The Web Services Business Activity specification (WS-BusinessActivity) describes a model in which the compensation actions are coordinated across several business applications. When you apply this model to BPEL processes, long-running work is distributed over scopes within multiple BPEL processes and executed as nested scopes. In addition, WS-BA conceptually describes the states, state transitions, and stimuli underlying BPEL scope-based local transaction management.

14.2.7. Extensibility and the Role of Web Services Policies

Sometimes you need to define additional capabilities that BPEL's constructs do not provide. One approach uses BPEL's extensibility. It involves defining private extensions and providing support for them in specialized engines. The problem is that these processes can no longer be shared with others. Portability is compromised. When portability is not a goal, you can certainly take this approach. You can create domain-specific BPEL extensions for certain specialized areas. The relevant industry sectors can then standardize these extensions.

More important, however, is the ability to recognize when these capabilities are orthogonal to the business logic. Examples include quality-of-service requirements and capabilities. People often rush to add functionality to the base language when the requirements they have are better met by the other pieces of the Web services stack. This is when you apply the modularity of the Web services stack. In these situations, you can attach Web services policies to different parts of the BPEL process, the corresponding WSDLs, or both. You can attach policies to the partner construct to denote requirements that must apply along all the interactions with the specified partner. You can apply them to the partnerLink or even to each interaction activity. On the other hand, you can attach policies to the WSDL portTypes or ports that correspond to the process. These specify the capabilities that the process offers to its partners.

Earlier chapters presented some of the policy languages provided by Web services, such as WS-Security and WS-ReliableMessaging.

The attachment of policies to the business process enables the separation of concerns that is desirable to keep the business logic intact and first order. Therefore, when you consider adding proprietary constructs to BPEL, you should first think of whether the functionality that the constructs are trying to add is better achieved through the use of Web services policies that are orthogonal to, yet can be integrated with, the business logic.