Business Process Context

Use case

Robert's Rubber and Penny's Pencils have been doing business for quite some time electronically and over the Internet. Both companies agree with the oft-heard refrain "I am not in the IT business" and wish to transition to a more standard, off-the-shelf infrastructure. They are hoping new process technologies such as WS-BPEL will get them both most of the way there.

Rob and Pen currently are working within a 5 year contract that calls out their roles, responsibilities and expectations. This legal document does not discuss particular technologies or service (as in "Internet protocol") level agreement terms. It does, however, describe expected document exchanges, time lines for each and the related delivery of goods.

The particular documents exchanged on a regular basis and the terms under which they are exchanged are "relatively" simple due to the repeated nature of the purchases and the smoothness of their historical relationship. Both companies wish to avoid additional complications and new technical problems as they transition to a new document exchange protocol.

At the moment, our pencil manufacturer (the buyer) orders varied amounts of rubber from a fixed catalog, expects order receipt acknowledgment within a business day and goods delivery within 3 business days. While our rubber provider (the supplier) may occasionally notify the manufacturer of a delay, this notification always occurs within the first business day after Rob receives the order. Under the terms of their agreement and while both Rob and Pen may cancel and Rob may refuse an order within that important first day, neither may modify an order. The companies are using Evaluated Receipt Settlement (ERS), meaning Rob never sends invoices and Pen sends good receipts. The actual payment involves direct deposits their banks handle directly, out of band with respect to this business document exchange.

The particular business documents involved in this relationship include purchase order, cancel order, shipment advice, goods receipt and acknowledgments. Rob sends the acknowledgment and shipment advice documents, receives all of the others. The high level business process outline appears in Figure 1.

Overall relationship between the buyer (Penny) and seller (Robert)

Robert and Penny have heard a great deal about service oriented architectures and the web services implementation of that model. They want to get on this wonderful bus. What should they do?

Message correlation

During a business activity such as that with Rob and Pen, a given process will often interact with many different partners in order to conduct work. Those interactions may be based on various transport mechanisms. However, the typical interaction pattern is based on one way messages, rather than the traditional synchronous remote procedure call paradigm, because this allows loose coupling of application entities; the sender of a given message that requires a response need not be the same as the ultimate receiver of that response. This allows for great flexibility in choosing service deployments, particularly in environments that may be error prone, require dynamic changes to roles and responsibilities, or support entities that assume several roles in related interactions.

However, if interactions are structured as one-way messages, some means of tying a response to a request is required obviously required. Furthermore, in some situations it may be a requirement for multiple requests to be sent to a service but only one response is required. Rob's online computer ordering service may, for example, combine a day's worth of Pen's orders (N*purchase orders) until the requested goods are finally dispatched (one shipment advice). In this case, Rob chooses when to combine requests into fewer responses. Pen would be driving a similar choice if our use case involved change orders (initial order + N*refinements resulting in a single shipment).

These requirements can be summarized as requiring messages to be contextualized: Additional information must be associated with a message to enable the infrastructure to “route” the message (physically or logically).

An obvious way in which this matching could be done would be through the use of additional information associated with the messages (e.g., a message sequence number). However, this has the following disadvantages:

• It requires support (and agreement) from all parties involved. For instance, do we use a string, a URI or an integer for this information?
• It’s an ad hoc solution implemented each time an application has this kind of requirement. Although it will work for perhaps one or two interactions, it but may not scale as the number of interactions and services increases.

For example, let’s return to Rob's order processing scenario and look at the possible message interactions between the various processes, as shown via the UML interaction diagram in Figure 6. Here we’ve added an Order Process Orchestrator, which is meant to represent the overall controlling aspect of the flow. As you can see, in this example we’ve modeled all interactions as one-way operations.

Because we are using one-way operations, it’s necessary to correlate requests and responses. For example, if you look at the interaction between the Order Process Orchestrator and the Order Authorization Process you can see the getOrderAuthorization request and the orderAuthorization response. The order process workflow will probably be dealing with many client order requests concurrently, so the Orchestrator will be sending and receiving many getOrderAuthorization and orderAuthorization messages.

Message interactions for the process order example

More than just correlation data could be carried in the context. For example, some applications may find it beneficial to include frequently changing data (e.g., a shopping cart) within the context, rather than having to access this information through an explicit lookup or some other mechanism. However, if this information is large (e.g., bitmaps, documents etc.), it may be a performance penalty to include this information directly in the context; the context information could end up dominating the message transmission time. Therefore, some way of passing context information "by reference" in these situations would be beneficial.

Coordination

The coordination aspects of our example business interaction are obvious: driving the process flow from order authorization, through a decision point to final product shipment requires some form of coordinator/orchestrator process. In a failure free environment this can be fairly simple and straightforward to achieve, but requires substantial infrastructure support otherwise. For example, in order to tolerate failures, the coordinator must durably remember the participants in the flow (the processes/services to invoke); where the flow has reached in the overall application and how to deal with lost or duplicate messages.

Likewise more than one type of coordination protocol may be required. For instance, the flow in the above example shows a relatively simply set of interactions between singleton processes, i.e., each message is sent to only a single recipient. However, there are situations were a more complex interaction pattern may be required; for example where orderAuthorization and checkStock must both occur or neither occur. In this case the coordination protocol used would have to be multi-phase in order to achieve consensus between the processes involved.

The coordination protocol could ensure the checkStock occurs for the order to be initiated and continued. In specific context, the order may not be initiated if the stock is not available. In a broader sense, coordinating across multiple entities may require a corresponding protocol to accommodate, for example, the distributed choice of each and their influence on the process outcomes.

Transactions

The concept of atomic (ACID) transactions has played a cornerstone role in creating today's enterprise application environments by providing guaranteed consistent outcome in complex multiparty business operations and a useful separation of concerns in applications. However, it has long been realized that traditional transactions by themselves are not adequate for structuring long-lived applications like that which Rob and Pen epitomize (). Most business-to-business applications require transactional support in order to guarantee consistent outcome and correct execution. These applications often involve long running computations, loosely coupled systems and components that do not share data, location, or administration and it is thus difficult to incorporate traditional transactions within such architectures.

Given that the traditional ACID transaction model is not appropriate for Web services, let’s pose the question, “what type of model or protocol is appropriate?” The answer to that question is that that no one specific protocol is likely to be sufficient, given the wide range of situations where Web service transactions are likely to be deployed.

The problem with this answer for the likes of Rob and Pen is that they aren’t transaction experts and have more pressing things to do, like implement the functional aspects of their new Web services application. What they need is support from the infrastructure so that transactions are simply an all pervasive fact of life, something which they can choose to use without too much effort. The mechanisms used to compose, correlate and constrain the execution and coordinating their processes may not be visible to these two partners, but the capability and flexibility to meet their changing business obligations are. A similar requirement arose in other environments, such as CORBA OTS and J2EE JTS.

Correlation

In order to correlate the work of distributed participants within the same activity, it is necessary to propagate additional information (the context) to participants. The context contains information such as a unique ID that allows a series of operations to share session data. For example, a SOAP header block might contain context information that is propagated when interacting with a service, or when multiple participants exchange SOAP messages in order to create a larger interaction such as a process flow or other aggregation of Web services.

Context propagation is a fundamental requirement of many distributed systems, including Web services MCL04. However, the type of context information that is used may vary depending upon the circumstances, e.g., in an atomic transaction system it may be a URI for the coordinator; whereas for secure data interchange it may be the sender’s public encryption key. In the business process arena, execution of a business process and handling the complexity of multi-party collaborations also requires careful context management. Therefore, what is needed is standardization on a context framework that allows services to register with it and customize it on a per activity basis.

The WS-Context specification defines such a context service. It can be used by arbitrary Web services to form composite applications. Contexts are first-class elements, i.e., the context information is represented as a Web resource, accessible via its URI. Contexts may flow implicitly (transparently to the application) with normal messages sent to participants/endpoints during Web service execution, or may need an explicit action on behalf of a participant.

WS-Context defines the notion of an abstract activity to which the context is bound: the lifetime of the activity is the lifetime of the context. So, we can (for example) use an activity to model a session: all interactions on a session-oriented service in the scope of an activity will be uniquely and unambiguously tied to that activity through the context. An activity may also model a business process instance, a conversation, and other concepts.

One of the common features of all middleware systems is support for the session concept. A session is a mechanism for correlating multiple messages in order to achieve some application-visible semantic. This is typically done on behalf of a client within a service endpoint. In general, middleware systems decouple session association from specific communication channels to improve robustness. To achieve this, the session model is layered on top of a communication channel that links the client to network-visible application services. Many middleware systems advertise the session model explicitly as a mechanism for client applications to manage stateful conversations or communicate with stateful “resources”. In other cases, the session concept is maintained less explicitly to support system services that are provided to applications.

For example, a context might begin:

<context>
	<type=MyContext/>
	<context-identifier>
		http://www.webservicestransactions.org/example/XTECH2005
 	</context-identifier>
</context>
       		 

The activity might require user authentication. For example, as we mentioned, the interactions between Bob and Pen require some kind of authentication information. To facilitate single sign-on throughout the composite application, the context might be extended to include user information and provided as an input to the first Web service in a WS-BPEL defined flow. The first Web service in the flow would check the username and password (the asterisks are used to indicate opaque data in the example below) and generate an authentication token. Such an authentication token would be placed back into the context data structure, augmenting the original structure. This token (rather than the username and password) is used for subsequent checks of whether the user is authorized to access other Web services in the flow.

The augmented context might contain the following:

           <extended-context>
            <user-name>Rob</user-name>
            <AuthToken>********</AuthToken>
           </extended-context>

As illustrated, the context is a living data structure; the results of a security sign on (or other operations pertinent to the contents of the context) would typically be added for propagation to the next Web service in the flow. For example, a single sign-on system bridging multiple security domains could add another token to the context.

Another potential way of achieving the session concept would be through the use of WS-Addressing ADDR ReferenceProperties/ReferenceParameters. Unfortunately this approach tightly couples sessions to endpoint references. Clients cannot switch or alter the interaction semantic with respect to the service. Clients must maintain a special reference on a per-relationship basis with each service, further coupling the service client and the service itself. This has two important consequences: it creates a brittle relationship between the client and the network service in which the client’s understanding of the service is limited to a particular session. Termination of that session invalidates the client’s communication channel to the service. Secondly, this results in a scalability problem: clients must contain special reference-pointers to services for each relationship that is linked by the session. Often this results in the unnecessary management and storage of redundant data.

As in other distribution environments where the reference session model is used (e.g., CORBA or J2EE), the remote reference (address) that the client has to the service endpoint must be remembered by the client for subsequent invocations. If the client application interacts with multiple services within the same logical session, then it is often the case that the state of a service has relevance to the client only when used in conjunction with the associated states of the other services. This necessarily means that the client must remember each service reference and somehow associate them with a specific interaction; multiple interactions will obviously result in different reference sets that may be combined to represent each sessions.

On the other hand, WS-Context allows a service client to more naturally bind the relationship to the service dynamically and temporarily. The client’s communication channel to the service is not impacted by a specific session relationship. This has special implications as we consider scaling Web services from intra-domain deployments to general services offered on the Internet.

Coordination

WS-CF is the middle layer in the WS-CAF set of specifications whose aim is to provide an extensible framework that supports a wide range of different coordination protocols (e.g., two- or three-phase commit).

The fundamental idea underpinning WS-CF is recognition of a shared and generic need for propagating context information in a Web services environment, irrespective of the applications involved. The WS-CF specification defines a framework that allows different coordination protocols to be plugged-in to coordinate work between clients, services and participants, as shown in Figure 7.

WS-CF Architecture

The WS-CF specification talks in terms of activities, which are distributed units of work, involving one or more parties (which may be services, components, or even objects). At this level, an activity is minimally specified and is simply created, made to run, and then completed.

Whatever coordination protocol is used and in whatever domain it is deployed, the same generic requirements are present:

• Instantiation (or activation) of a new coordinator for the specific coordination protocol, for a particular application instance;
• Registration of participants with the coordinator, such that they will receive that coordinator’s protocol messages during (some part of) the application’s lifetime;
• Propagation of contextual information between Web services that comprise the application;
• An entity to drive the coordination protocol through to completion.

The first two of these points are directly the concern of WS-CF, the third is obtained through the use of WS-Context, while the fourth is the responsibility of a third-party entity, usually the client application that controls the application as a whole.

Transactions

We’ve already seen that the structuring mechanisms available within traditional atomic transaction systems are not sufficient for all of the complex business interactions that are likely to arise (for Pen and Bob for instance) and that multiple transaction models are necessary. As a result, WS-CAF builds on the extensibility aspect of WS-CF with the WS-TXM specification, which defines the following models:

• ACID transaction: This model is designed to support interoperability of existing transaction processing systems via Web Services, given such systems already form the backbone of enterprise class applications. Although ACID transactions may not be suitable for all Web Services, they are most definitely suitable for some, and particularly high-value interactions such as those involved in finance.

• Long running action: An activity, or group of activities, which does not necessarily possess the guaranteed ACID properties. With this model, all work performed within the scope of an application can be compensated through some other activity (work). How a Web service performs its work and ensures that it can be undone if compensation is required, is an implementation choice. The model simply defines the triggers for compensation actions and the conditions under which those triggers are executed.

  In the LRA model, each application is bound to the scope of a compensation interaction. For example, when a user reserves a seat on a flight, the airline reservation centre may take an optimistic approach and actually book the seat and debit the users account, relying on the fact that most of their customers who reserve seats later book them; the compensation action for this activity would obviously be to un-book the seat and credit the user’s account. Work performed within the scope of a nested LRA must remain compensatable until an enclosing service informs the individual service(s) that it is no longer required.

  There is a caveat to this model though, where application services may not be compensatable (e.g. an application-level service that prints and mails cheques), or the ability to compensate may be transient. The LRA model allows applications to combine services that can be compensated with those that cannot be compensated Obviously by mixing the two service types the user may end up with a business activity that will ultimately not be undone by the LRA model, but which may require outside (application specific) compensation.

• Business process transaction: This model is specifically aimed at tying together heterogeneous transaction domains into a single business-to-business transaction. So, for example, it’s possible to have a long-running business transaction span messaging, workflow and traditional ACID transactions, allowing enterprises to leverage their existing IT investment.

  Each domain may represent a different transaction model if such a federation of models is more appropriate to the activity. Each business task (which may be modeled as a scope) may provide implementation specific counter-effects in the event that the enclosing scope must cancel. In addition, periodically the controlling application may request that the entire business domains checkpoint their state such that they can either be consistently rolled back to that checkpoint by the application or restarted from the checkpoint in the event of a failure.