Process Coordination in BPEL Issues and Recommendations Satish Thatte

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

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

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

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

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

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