1 / 38

Multi-Party Coordination Protocol for Commercial Collaborations

Oasis Business Transaction Protocol is a guide for inter-organizational coordination, accommodating long-running transactions, and XML-based communication over multiple protocols to facilitate commercial collaborations. It focuses on multiple successful outcomes, relaxed isolation, and using contracts for governance. The document explains the key BTP roles, transaction phases, provisional, final, and counter effects, demonstrating examples of confirmations and cancellations in transactions. It also explores compensation strategies and XA RM implementations. The protocol outlines participant relationships and transaction tree structures for seamless coordination in complex business scenarios.

nairi
Télécharger la présentation

Multi-Party Coordination Protocol for Commercial Collaborations

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. OASIS Business Transaction Protocol:Multi-party Coordination for Commercial Collaborations peter.furniss@choreology.com alastair.green@choreology.com tony.fletcher@choreology.com March 2002

  2. Goals • Inter-organizational multi-party coordination • Targetting Web Services, but not only WS • Accommodate Long-running Transactions

  3. Requirements • Coordination of autonomous parties • Relationships are governed by contracts, rather than the dictates of a central design authority • Drop less ACID • Multiple possible successful outcomes to a transaction • Relaxed isolation, volatile results  • Interoperation • Using XML, over multiple communications protocols • Discontinuous service • Work unit lifespans exceed sub-system MTBFs 

  4. The key BTP roles Client side Service side Client Service Initiator/Terminator Application Enroller Protocol Factory Transaction Decider(Composer or Coordinator) Participant

  5. Ask Factory to Create top coordinator Client side Service side Client Service Initiator/Terminator Application BEGIN / BEGUN&CONTEXT Enroller Protocol Factory creates Coordinator Participant

  6. Send Application Message with CONTEXT Client side Service side Client Service CONTEXT Initiator/Terminator Application Enroller Protocol Factory Coordinator Participant

  7. Service creates and causes ENROL of Participant Client side Service side Client Service Initiator/Terminator Application Enroller Protocol ENROL / ENROLLED Factory creates Coordinator Participant

  8. Send Application Reply with CONTEXT_REPLY Client side Service side Client Service CONTEXT_REPLY Initiator/Terminator Application Enroller Protocol Factory Coordinator Participant

  9. CONFIRM_TRANSACTION Client side Service side Client Service Initiator/Terminator Application CONFIRM_TRANSACTION Enroller Protocol Factory Coordinator Participant

  10. Two-phase Confirmation: PREPARE phase Client side Service side Client Service Initiator/Terminator Application Enroller Protocol PREPARE / PREPARED Factory Coordinator Participant

  11. Two-phase Confirmation: Outcome phase Client side Service side Client Service Initiator/Terminator Application Enroller Protocol CONFIRM / CONFIRMED Factory Coordinator Participant

  12. TRANSACTION_CONFIRMED Reply Client side Service side Client Service Initiator/Terminator Application TRANSACTION_CONFIRMED Enroller Protocol Factory Coordinator Participant

  13. Cancellation • Example showed CONFIRM/CONFIRMED • Terminating application can also issue CANCEL_TRANSACTION • Or the CONFIRM_TRANSACTION can fail, leading to TRANSACTION_CANCELLED • CANCEL/CANCELLED exchange with Participant

  14. Service and Participant: Provisional effect and Counter-effect • Forward Operations create a provisional effect… • … and durably record information needed by Participant • Participant uses log to perform final effect or tocounter-effect Client side Service side Service A (provisional) Log of A finalise A CONFIRM counter A CANCEL Participant

  15. Provisional, final and counter effects • Provisional effect • Apparently – the application’s forward operation • Really – just do what is needed to do either final or counter • Do something, log (persist) information for final or counter • Final effect – action on CONFIRM • Final effect is action on CONFIRM • Complete the operation so it did happen • Use the information in the log, discard log • Counter effect – action on CANCEL • Counter-effect is action on CANCEL • Make it that the application did not happen (or unhappened) • Use the information in the log, discard the log • May be perfect or have side effects

  16. 2PC  ACID • Example #1: Compensation strategy • Provisional Effect includes committed database updates or message enqueues • E.g. debit credit card account • Final effect is no-op • Counter-effect involves compensatory action • E.g. contra-credit credit card • In whole or in part depending on business contract • Example #2: XA RM • Provisional Effect posits but does not commit database updates or MQPUTs • Final effect invoke xa_commit • Throw away RM undo logs • Counter-effect is to invoke xa_rollback • Process RM undo logs

  17. Service decides what a Participant covers • Service can combine provisional effects into one Participant • Single confirm or cancel signal • Application specific • Service had the right to create and enrol two participants Operation Group Client side Service side Service A B Log of A, B finalAB CONFIRM counterAB CANCEL Participant

  18. Superior-Inferior Relationship - outcome Superior PREPARE CONFIRM CANCEL Inferior ComposerCoordinatorSub-composerSub-coordinator PREPARED CONFIRMED CANCELLED Sub-composerSub-coordinatorParticipant

  19. Transaction Tree - 1 Inferior [Participant] Superior [e.g. Coordinator] Inferior [Participant] Inferior [Participant]

  20. Transaction Tree - 2 Inferior [Participant] Superior [e.g. Coordinator] Inferior/Superior [e.g. Sub-coordinator] Inferior [Participant] Inferior [Participant]

  21. Transaction Tree - 3 Inferior/Superior [e.g. Sub-coordinators] Inferior [Participant] Superior [Composer] Inferior [Participant] Inferior [Participant]

  22. Coordination Hub: control and outcome relationships Client Service Client Service Application Initiator/Terminator control Enroller outcome Protocol Transaction Decider(Composer or Coordinator) Participant Factory Coordination Hub

  23. Shipping Atom  Goods Atom  Cohesions: The Concept Buyer Services Inferior Coordinators Superior Cohesion Terminator Superior Composer #1 Inferior Participant #2 Inferiors Participants

  24. Shipping Atom  Goods Atom  Cohesions: PREPARE both Atoms Buyer Services Inferior Coordinators Superior Cohesion Terminator Superior Composer #1 PREPARE P PREPARE_INFERIORS #1, #2 Inferior Participant P #2 PREPARE PREPARE Inferiors Participants

  25. Shipping Atom  Goods Atom  Cohesions: both are PREPARED Buyer Services Inferior Coordinators Superior Cohesion Terminator Superior Composer #1 P’d #1 PREPARED P’d INFERIOR_ STATUSES Inferior Participant P’d #2 P’d #2 PREPARED PREPARED Inferiors Participants

  26. Shipping Atom  Goods Atom  Cohesions: CONFIRM #1 (  CANCEL #2) Buyer Services Inferior Coordinators Superior Cohesion Terminator Superior Composer CONFIRM #1 CONFIRM CONFIRM_TRANSACTION #1 Inferior Participant CANCEL #2 CANCEL CANCEL Inferiors Participants

  27. Shipping Atom  Goods Atom  Cohesions: #1 CONFIRMED, #2 CANCELLED Buyer Services Inferior Coordinators Superior Cohesion Terminator Superior Composer #1 CO’d #1 CONFIRMED CO’d INFERIOR_ STATUSES Inferior Participant CA’d #2 CA’d #2 CANCELLED CANCELLED Inferiors Participants

  28. Cohesions rely on “Open-top” Coordinator “Open-top” Atom Coordinators Cohesion Terminator Cohesion Composer #1 PREPARE / PREPARED CONFIRM_TRANSACTION #1 CONFIRM / CONFIRMED #1 CO’d INFERIOR_ STATUSES PREPARE / PREPARED #2 CA’d CANCEL / CANCELLED #2

  29. S S S S O O O O Example: Cross-company Securities Trading Stock and option – from different market makers Hedge Fund ABN Amro Nomura Commerz DKB

  30. S S S S O O O O Example: Cross-company Securities Trading Each market maker makes two guaranteed time-qualified quotes = PREPARED, from 2 participants each Hedge Fund ABN Amro Nomura Commerz DKB

  31. S S S S O O O O Example: Cross-company Securities Trading Hedge fund chooses one of each, cancels the others (or lets them timeout) Hedge Fund         ABN Amro Nomura Commerz DKB

  32. Participant time-out • Inferior can limit duration of its preparedness • Inferior threatens to auto-cancel or confirm after (at least) n seconds • Inferior qualifies the PREPARED message • Prevents coordinator hogging service provider’s resources • Independent organization likely to demand this power • Risks contradiction – which will be reported • Superior can negotiate the time limit • Superior qualifies the PREPARE message • Prevents service wasting coordinator’s time

  33. Failure Recovery • Protocol incorporates recovery after failure • Superior system, Inferior system or network may fail • Must try to re-establish Superior-Inferior relationship • Allows outcomes to be replayed • Standard “presumed abort” protocol • No durable record (log) equals absence of decision • Default decision (in absence of evidence to contrary): CANCEL • Bi-directional recovery initiation • Superior can attempt to contact logged Inferiors • Inferior can attempt to contact logged Superior

  34. Active phase recovery • Allows Superior/Inferior re-synch after failures • Standard 2PC protocols allow recovery only after prepared • BTP treats failure as a potential interruption • Standard 2PC protocols treat any failure as cause to cancel • Permitted, not required • Presume-abort still applies – just it isn’t compulsory • Useful for long-running transactions • Useful with interruptible communications

  35. Messaging • All BTP messages are XML documents • Can be compounded for optimization • “One-shot requests”: only 2 WAN messages instead of 6 • Application response + ENROL/PREPARE • “One wire” application topologies • All traffic between two business entities over a single, authenticated link • Binding of abstract set to SOAP • Defined in the specification • Other bindings are possible • To any underlying communications protocol stack

  36. Qualifiers • Qualifiers can be embedded in messages • Some are defined within BTP specification • Implementers/applications can define their own • Identified by URI • Allows extensions to protocol messages • trading parties could use to add security data • Implementor could use to add full nested transactions • Allows application data to travel with protocol • Example: confirm a two-way quote • Must include “buy” or “sell” in CONFIRM

  37. Business Transactions and Business Process • BTP complements BP/Collaboration frameworks • A coordinated, mutually understood outcome requires • Special messages and acknowledgements • Consistent, durable record of decisions • Asynchronous failure recovery operations • These features are tricky, error-prone and intrusive • “Build or buy” • BTP lets business people concentrate on business process • Puts housekeeping work in the background • Minimizes application exchanges • Reduces complexity of collaborative process schemas or scripts • Reduces conformance testing • Deploy new trading protocols or conventions more quickly

  38. Internal Business Process Internal Business Process Collaboration Process BTP BTP Collaboration Process Do Business Together with Business Transactions • Ensuring Collaboration for XML Services

More Related