1. Process Coordination in BPEL Issues and Recommendations
Satish Thatte

2. What is Process Coordination
Coordination is about enabling a collection of autonomous entities to perform joint work using predictable interaction patterns
Familiar example: Traditional ACID transactions
Process coordination differs from ACID transaction coordination in many respects
Coordination protocol signals in general carry application data
Work is very often initiated by the coordinator rather than the participant/subordinate in the coordination tree
Outcomes are not dictated by application agnostic standard coordination logic (e.g., all-or-none)
Coordination behavior is embedded in application context and is in fact a part of application behavior

3. What can be done in BPEL?
The BPEL TC is unlikely to take a dependency on any specific context-based coordination specification
Cross process coordination is a common design pattern already for BPEL processes, using ordinary Web service operations across partnerLinks
The coordination required for issue 2, and many variants of can in fact be very conveniently accomplished with no new features using ordinary Web service operations (see example next slide)
Especially given that application specific data and hence operations will be needed when performing coordinated work

4. Anatomy of a Subordinate ProcessEH
Application Specific
portType for Coordination
Process the PO
scope
ProcessPO
CancelOrder
ReturnToInventory
ConfirmAndShip
Pick

5. Notes on the Anatomy The example is based the following ideas
The sub-process provides its functionality through a set of application specific synchronous operations
ProcessPO invokes the initial work unit of the subprocess
But the work is tentative until confirmed
ReturnToInventory reverses the tentative work
It is the compensation handler for ProcessPO
ConfirmAndShip confirms and closes the work unit
It is the confirm handler for ProcessPO
CancelOrder is the only asynchronous operation
It is the cancel handler for ProcessPO
The scope of the cancel handler is limited to the scope of the initial work on ProcessPO
Clearly this is only one possible design pattern
For instance CancelOrder could return a response as well

6. Recommendation
BPEL has a notion of an instance-level compensation handler
But BPEL has no mechanism for invocation of this handler nor for its discharge
Moreover the handler has no parameters and hence cannot share state with the coordinator
We should simply remove the instance level compensation handler since we do not provide a way to make it useful
For the sub-process coordination case, where this type of mechanism would be useful, compensation handlers, as well as cancel and confirm handlers, can be modeled as explicit operations in application-specific portTypes that drive the top level behavior of a sub-process
One pattern to accomplish this is illustrated in the example

7. Conclusion
Certain kinds of infrastructure support can make the realization of some coordination patterns easier (e.g., participant/subordinate initiated work)
To make this useful and interoperable requires a lot of work beyond pure BPEL features
As a TC our charter precludes this type of work
We must therefore limit the scope of our work in this area to what BPEL can do with existing features