1 / 7

Process Coordination in BPEL Issues and Recommendations

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

derry
Download Presentation

Process Coordination in BPEL Issues and Recommendations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related