Process Coordination in BPEL CounterProposal Bob Haugen

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  But the abstract protocols are very similar

What can be done in BPEL? We cannot take a dependency on any context-based coordination specification  There is no commonly agreed dependence target  But all current candidates are sufficiently similar to be plug-compatible Cross process coordination is a common design pattern already for BPEL processes, using ordinary Web service operations across partnerLinks  See next slides… 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)  See also counter-example

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

Alternative Pattern

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 It is recommended that we remove the instance level compensation handler since we do not provide a way to make it useful  Agreed. But add Confirm and Cancel handlers.

What is lost by not adding any features? 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, we would need to take a dependency on some external specifications  For BPEL purposes, all candidate external specs are plug- compatible We neither have any such dependency available nor does our charter include this type of work  Re dependencies: since all candidates are plug-compatible, BPEL can safely add minimal hooks.  Re charter: BPEL usage scenarios consistently require coordination. We must therefore limit the scope of our work in this area to what BPEL can do with existing features

Ok, so there’s two ways to do coordination in bpel: Code-your-own coordination logic in each bpel process Put in hooks to delegate the completion phase of the coordination problem to business transaction managers Two phases:  Active phase: application messages  Completion phase: protocol messages

Recommended hooks for coordination: Final Cancel/Confirm Request completion Context Participant registration Create context

Do we really have to be dependent on a particular coordination protocol ? bpel participant behaviour can only be  give up before initial work completes  confirm initial work beyond threat of negation  negate initial work beyond threat of confirmation Some differences may be visible in the coordination side  all-or-none, selection Most differences are at global level  Q: protocol does/does not need to reflect this  that’s a binding question, so not our problem Issue 2 coordination doesn’t need a standard protocol anyway

On WS-Atomic Transaction It is important to note that the atomic, two-phase model is only with respect to the services involved. Sites or infrastructure offering services may advertise two-phase commit, but use some other intra-enterprise model like compensation or versioning. This freedom makes a simple two-phase commit model more useful for long-running Internet computations.  from “Secure, Reliable, Transacted Web Services” - Ferguson, Storey, Lovering, Shewchuk

Where do app-specific protocols break down? One coordinator, many participants:  Different protocol for each participant? Composition of prebuilt participants:  Same question Zero or minimal configuration B2B ecommerce:  Different protocol for each trading partner? Economic networks (e.g. supply chains):  Different protocol for each node?

What do you lose without a business transaction manager? Throw coordination work on application programmer  E.g. need to re-invent transaction state machines in BPEL Process controlling multiple participants gets very complicated  numerous clean-up paths some have accepted, some in-flight when decide to reverse  recovery and state re-alignment Something has to tie the message and state changes together  reliable messaging manipulation inside a transaction