12.6 Business Process Management | Programming Web Services with Perl

Businesses are changing rapidly and becoming increasingly complex with even less clear boundaries between (and inside) companies. Most of the business interactions are complex in structure, transactional, stateful, and asynchronous; some of them are long-lived, with complex relationships between their participants .

While this section is called "business process management," there are several terms that are often used in the same context but still have slightly different meaning: orchestration, choreography, conversation, composition, coordination, collaboration, workflow, and business process management. A few are defined here to minimize the confusion:

Orchestration (also composition and workflow ): Defines a composition of smaller services into a larger service. It describes how services get called including specific order of interaction, and addresses the possible dependencies between those services.
Choreography: Defines an interaction script ”a message exchange between different services. Even though it may indicate the sequence of messages and identify trading partners and their roles in the interactions, it isn't an executable logic; it's a contract all participants are compliant with.
Coordination: Defines a contract for distributed synchronization.
Collaboration: Defines a contract or agreement over the technical aspects of the relationship.

Before diving into the conversation about specifications that describe some of these aspects of business process management, two important topics have to be discussed: document style and distributed transactions.

12.6.1 Document and RPC Styles

Most of the discussions so far were focused on the RPC style of method execution and the document style was only briefly discussed in a previous chapter. Here is a quick remainder for those who skipped some of them: document (also called messaging) style means that an XML document is sent as the payload of the SOAP message. For many people, RPC and document styles are like two different sides of a coin: RPC style is associated with the message signature and data types, whereas document style is associated with the document structure and XML processing. The reality is that the wire representation doesn't dictate a programming model. It's one of the things people frequently confuse when comparing document and RPC styles. Two others are granularity of interfaces and synchronous versus asynchronous messaging models.

The representation on wire and a programming model are orthogonal to each other; both RPC and a document style can be programmed using object-oriented and XML approaches. Although there are some differences, they are minimal: RPC style tends to provide more methods and work with simpler data, whereas document style operates mostly on rich data using no methods at all (it's also possible to look at it as if it's using only one method, send ). The diagram in Figure 12-1 illustrates this.

Figure 12-1. RPC, REST, and document styles

Granularity of interface generally refers to the level of detail provided by the interface. Fine-grained (also called chatty) interfaces provide high level of details, whereas coarse-grained (or chunky ) interfaces provide low level of details. RPC methods are often associated with fine-grained interfaces and document style with coarse-grained interfaces, but as with programming models, in reality they are orthogonal; messages implemented using both RPC and document styles can be coarse- or fine-grained. Examples of fine-grained RPC request include getAccountBallance and getInterestRate , which return the account balance and interest rate, respectively. Coarse-grained getAccountSummary requests return the account balance, current interest rate, and five last transactions. Object-oriented style encourages fine-grained interfaces with better flexibility and maintainability; the very nature of distributed applications prescribes coarse-grained interfaces.

The difference between asynchronous and synchronous messages is a different story. It has to be emphasized that in most cases when people make the distinction, they are talking about real-time and deferrable interactions. The difference between these two is clearer: if a real-time message can't be sent immediately, this is an error and the client has to be notified. This is a business-oriented rather than a technical distinction. Both real-time and deferrable interactions can be implemented using synchronous (request/response) or asynchronous paradigm; for example, clients may send a POST request, get back a 202 Accepted code with a new URI included in the Location header, and then come back later to send a GET request to that URI to get a response.

The point of the discussion is that even though RPC-style messages tend to be real-time, fine-granular requests mapped to object-oriented methods for execution, they could be something else too. In the same sense, document-style messages tend to be deferrable, coarse-grained messages, associated with document processing but could be something else.

The interesting question to consider is: how does the receiver know what to do when the document style is used; in many cases there is no action included with the message, only data. The answer is that there are always some semantics associated with the message; in some cases this knowledge is transferred out of band . Semantics is the understanding of the intent of a thing or a concept. When an application receives a "purchase order" or "request for comment," it knows what to do with it (if not, a fault message is returned or there is a problem with the application). If two different responses are returned for the same data, there are two different semantics associated with that data. Even when the REST style is used semantics are present; for example, the DELETE request for the order resource can mean "cancel the order."

12.6.2 Distributed Transactions

A business transaction is an interaction in the real world, usually between a business and an individual or another business, where the state of one of the object changes. Transactions have four critical properties (also known as ACID properties):

Atomicity: The transaction executes completely or not at all (all-or-nothing execution). The successful completion of a transaction is called commit and the failure of a transactions is called abort (or rollback ). Atomic transaction implementations typically hold data resources (e.g., locking) and physical resources (e.g., connections, threads, memory) and assume short time duration and high trust.
Consistency: Internal consistency of the affected resource (for example, database) is preserved (unaffected properties don't change).
Isolation: The transaction executes as if it were running alone, with no other transactions. Effects of the execution aren't visible until the transaction commits; as the result, transactions appear to be executed serially (one by one), even if they are performed concurrently.
Durability: All changes caused by the transaction execution are stored in persistent storage, and results will not be lost in the failure.

When a transaction updates data on two or more systems in a distributed environment, atomicity of a transaction still has to be ensured. This may pose a significant challenge, because, as was discussed in the section on reliable messaging, a system may fail for different reasons, and multiple systems may fail and recover independently. One solution that deals with such problems is the two-phase commit (2PC) protocol. All actions taken prior to commit or abort aren't visible to other activities and are stored in persistent storage; they get committed as soon as participants vote to complete successful execution.

Commit is an irrevocable action: a transaction can't be aborted once it's committed. However, it's possible that, for whatever reason, a transaction has to be reversed even after it's already committed. The transaction that reverses the action of some previous transaction is called a compensating transaction. The example of the compensating transaction would be the delivery of the luggage to the right address after it was mistakenly routed to the wrong airport (it isn't always possible to cancel or roll back that activity). In some cases, the compensating transaction is simply a recording of the fact that something wrong happened .

12.6.3 Transactions and Coordination

This section describes protocols that describe managing the business interactions in a loosely coupled , asynchronous environment. These include WS-Coordination and WS-Transaction, jointly developed by Microsoft, IBM, and BEA; and Business Transaction Protocol developed by OASIS.

12.6.3.1 Web Services Coordination (WS-Coordination)

The Web Services Coordination specification can be found at:

http://www.ibm.com/developerworks/library/ws-coor/

It defines an extensible framework for coordinating activities that defines a set of coordination protocols and enables participants to reach consistent agreement on the outcome of distributed activities. The coordination protocols that can be defined in this framework can accommodate a variety of activities, including protocols for simple short-lived operations and protocols for complex long-lived business activities.

The framework is described by defining a coordination service that consists of the following elements:

An activation service: Defines a CreateCoordinationContext operation that enables an application to create a coordination instance or context. The activation service isn't required to be supported; the exact semantics are defined in the additional specification.
A registration service: Defines a Register operation that enables an application to register for coordination protocols. The registration service must be supported by a coordination service.
A coordination type: Describes specific set of coordination protocols; one coordination type may have multiple coordination protocols that define the coordination behavior and the message exchange between the participants. The definition of coordination protocols are provided in an additional specification (for example, WS-Transaction specification discussed next ).

Because of the simplicity of WS-Coordination specification, it's quite reasonable to expect that its functionality will be used not only by WS-Transaction but also by other specifications to establish context for business interactions.

12.6.3.2 Web Services Transaction (WS-Transaction)

The Web Services Transaction specification can be found at:

http://www.ibm.com/developerworks/library/ws-transpec/

It leverages WS-Coordination specification by using it to define two coordination types to support atomic transactions (AT) and business activities (BA). It does this by defining the behavior and messages required by the respective coordination protocols.

The WS-Coordination protocols are used for transactions to create a new atomic transaction context, to propagate that context in messages between web services, and to register for participation in coordination protocols, depending on the participant's role in the activity. Each protocol is one of the coordination protocols of the atomic transaction coordination type defined in the specification. These protocols include Completion, CompletionWithAck (completion with optional notification), 2PC (two-phase commit), PhaseZero (notification that is sent before the 2PC protocol started), and OutcomeNotification (notification on completion of a transaction).

While atomic transactions are important building blocks, they aren't sufficient for the overall coordination. Responding to a request may take a very long time. Human approval, assembly, manufacturing, or delivery may have to take place before a response can be sent. Business activities require resources to be shared prior to completion.

The Business Activity protocols handle long-lived activities and compensating transactions (business logic to handle business exceptions). There are only two coordination protocols for business activities defined by WS-Transaction specification: BusinessAgreement and BusinessAgreementWithComplete.

Note that even though it isn't stated by the specification, reliable messaging is required to deliver messages "at least once" (or better "exactly once").

Overall, even though are WS-Transaction specification lacks some features presented in other transaction protocols (like BTP, which will be briefly covered next) it looks simpler than its predecessors. This makes it easier to implement and lowers barriers for adoption.

12.6.3.3 Business Transaction Protocol (BTP)

The Business Transaction Protocol specification can be found at:

http://www.oasis- open .org/ committees /workgroup.php?wg_abbrev=business-transaction

Developed by OASIS, it defines an XML-based protocol that supports business transactions constituting units of work across multiple loosely coupled, distributed parties. There are several types of transactions defined in the specification:

Atomic transactions produce the atomic outcome, such that all of the participants will either confirm or cancel.
Cohesive transactions, as defined by the specification, relax the isolation property ("effects of the transaction aren't visible until the transaction commits"). Cohesive interactions are allowed to be externally visible before the interaction is committed. In addition, a cohesion may deliver different termination outcomes to its participants such that some will confirm, and the rest will cancel; it allows the initiator to select a final subset of participants to commit. Finally, consistency is determined by agreement and interaction between the participants.
Compound transactions are simply defined as a combination of atomic and cohesive transactions (they can be compounded or nested) to support more complicated scenarios such as supply chain and intermediaries.

BTP also provides a great deal of flexibility by including the concept of "conditional commitment" that allows the participant application to associate a timeout value with the "prepared" response. On the whole, it enables sophisticated workflows, including reliable aggregation of multiple steps into a single unit of work. The specification defines XML messages that can be exchanged over many carriers , but it also provides binding to SOAP 1.1, thus allowing transaction coordination for web services.

12.6.4 Business Process Specifications

There are several standards in the general area of business process management:

Business Processing Execution Language for Web Services (BPEL4WS), developed by Microsoft, IBM, and BEA
Business Process Modeling Language (BPML), developed by the Business Process Management Initiative
Web Service Choreography Interface (WSCI), developed by BEA, Intalio, SAP, and Sun
Business Process Specification Schema (BPSS), proposed by the UN/CEFACT Business Transition Working Group as part of the ebXML specification
Enterprise Distributed Object Computing (EDOC), proposed by the Object Management Group
XML Processing Description Language (XPDL), proposed by the Workflow Management Coalition

Because there is no single standard that the majority of vendors agree to support, it isn't clear at this moment what specification will dominate the web-services field. The latest development in this area is BPEL4WS (or shortly BPEL) specification covered in this section.

One reason for covering BPEL is its relative simplicity compared to other specifications. History suggests that large and complex "once-and-for-all" standards, such as ebXML, even if better in some aspects, eventually lose out to simpler standards such as the growing web services protocol stack. Simple standards have a huge advantage over the complex ones: they are simple. While XML Schema, UDDI, and BPEL specifications aren't recommended as a bed-time reading, most other standards and specifications covered in this book are pretty simple. A specification has to pass a one-man test (one person can comprehend, explain, and implement the specification if needed) or it's unlikely that it will have a bright future ("deep pockets" can marginally compensate the one-man test failure for some specifications).

12.6.4.1 Business Process Execution Language (BPEL)

The Business Process Execution Language specification can be found at:

http://www.ibm.com/developerworks/ webservices /library/ ws-bpel /

Codeveloped by IBM, Microsoft and BEA, it's a long-awaited result that converges two previously competing standards: Web Services Flow Language (WSFL) from IBM, and Microsoft's XLANG, used as a XML business process language in BizTalk Server.

The BPEL specification provides a standard programming language businesses can use to define how to combine web services to accomplish tasks and relies on other specifications (like WS-Coordination, WS-Transaction, WS-Security, and the rest) to support it. The WS-Coordination specification describes how the individual web services interact within that task. The WS-Transaction specification ensures that all the transactions are either successfully completed or fail as a group. The WS-Security specification can provide the message integrity and protect semantically significant headers (like a message timestamp) and the message body.

The specification describes two approaches:

The executable process: Defines the process model that reflects the actual behavior.
The abstract process: Specifies the message exchange resulting from the process model. The business protocols that comprise abstract processes don't reveal the internal behaviors and process maps of a particular model.

BPEL documents are executable scripts that can be interpreted by business process engines to implement the described process, which makes them portable across environments that support BPEL (in a way similar to XSLT scripts, which can be executed in Perl, Java, C#, or other environments).

The specification defines a process as a combination of activity, a number of partners and containers, with specific correlation sets, fault handlers, and compensation handlers attached.

The control flow is defined as a mix of block structured and state transition control flow definitions, which use links to connect a source and a target activity (if an activity has incoming links associated with it, then it doesn't start until the status of all those links has been determined). There are sequence , switch , while , pick , flow , assign , throw , compensate , terminate , wait , and empty activities. When a fault occurs, normal processing is terminated , and control is transferred to the correspondent fault handler. The specification also supports the compensating actions through the compensation handlers. Both fault handling and compensating are supported recursively by introducing the notion of scope, which is an execution context for each activity, with the fault handlers and a compensation handler associated with it.

The message flow is implemented using receive , reply , and invoke activities; when executed in the same business context these activities can be correlated using properties combined in the correlation sets. Input messages are consumed by the receive activity, and output messages are produced by the reply activity (always in response for a request previously accepted through a receive activity). Consequently, the invoke activity is used within the process that produces the synchronous request or asynchronous response (the original requester will use a receive activity to consume the delivered response).

The data is passed between the different activities in an implicit way through the sharing of globally visible data containers. Containers represent data that is important for the correct execution of the business process and exchange specific data elements via the use of assign statements.

The interesting aspect of BPEL implementation is that trust becomes even more important as the interdependencies between participants grow: companies not only expose their interfaces but also share their process models with one another (even though distinction between private and public processes can be made); that poses new security risks and make companies not only more flexible in their interactions and adaptable in their processes but also more vulnerable.