WS-BPEL - Web Services Business Process Execution Language

BPMWS-BPELBPMN

Our submission to the WS-BPEL Technical Committee on support for Business Transaction Management in BPEL and the accompanying articles in Web Services Journal (September 2003 and November 2003) remain valid in their overall thrust; providing for full distributed transaction support within and across business processes. However, after participation in technical committee discussions, we believe that an approach based on “contingent scopes”with confirm as well as compensation handlers would be more in tune with BPEL principles and simultaneously more powerful in applying BTM to business processes.

WS-BPEL is probably the leading candidate for a workflow standard. BPEL is not an interoperability spec, it is a programming language. Some companies like IBM and BEA believe that BPEL can be a portable language, able to be deployed in multiple environments. Others, like Microsoft, believe that BPEL’s value is not portability, but its characteristics as a special-purpose language for process flow control.

BPEL is an attempt at a common workflow language in a world without common languages. Specifically, BPEL is a combination of Microsoft’s XLANG and IBM’s WSFL, which does not require Microsoft to adopt Java nor IBM to adopt C#.

BPEL provides means for:

• defining control flow, and
• defining how to interact with services and other processes by sending and receiving messages.

You may note that BPEL is completely silent about the need for recoverability – the main benefit of workflow engines. In practice, however, BPEL engines will need to provide recoverability if they are to be useful.

BPEL provides one other interesting feature: Long Running Transactions, or LRT. These transactions are defined and controlled by a nested scope structure which employs “compensation handlers”.

Without LRT, BPEL is just a process flow language. But LRT makes BPEL interesting to us. The LRT piece of BPEL is a hint at an interesting set of features. Unfortunately, BPEL has stunted its LRTs such that they will likely frustrate business users.

Two ways BPEL is stunted:

1. Only offering compensations , a very limited transaction pattern. We have found three main patterns for long-running business transactions: DO-COMPENSATE, VALIDATE-DO, and PROVISIONAL-FINAL. We describe these in greater detail on our BTM Spectrum page. For this topic, let us just say that DO-COMPENSATE is the only pattern that BPEL supports, and DO-COMPENSATE poses some major risks for business transaction users. The short explanation (again, in more detail on the BTM Spectrum page) is that often when you DO something in business, it becomes increasingly difficult to COMPENSATE for it as the ripple effects explode over time.
2. No distributed transactions. BPEL LRTs cannot be distributed: that is, one BPEL process cannot enlist services or other BPEL processes in the same transaction. In other words, BPEL cannot do cross-company or cross-application business transactions.

What users require from BPM is recoverability, distributed transactional behavior and conversational capability. BPEL contains features partially addressing these latter two needs.

Choreology Cohesions software can be integrated into the products of BPM vendors to provide full distributed transactional behaviour, notwithstanding the limitations of the planned BPEL specification.