1 / 13

Process Coordination in BPEL CounterProposal

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

caron
Télécharger la présentation

Process Coordination in BPEL CounterProposal

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 BPELCounterProposal Bob Haugen

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

  3. 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 53-59 can in fact be very conveniently accomplished with no new features using ordinary Web service operations (see example next slide) • See also counter-example

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

  5. Alternative Pattern

  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 • 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.

  7. 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

  8. 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

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

  10. 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

  11. 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

  12. 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?

  13. 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

More Related