Process Coordination in BPEL Issues and Recommendations

1. Process Coordination in BPELIssues 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 53-59 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. Process the PO ReturnToInventory CancelOrder Anatomy of a Subordinate Process EH Application Specific portType for Coordination scope ProcessPO 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