OASIS Business Transaction Protocol A Tutorial presentation for

OASIS Business Transaction Protocol A Tutorial presentation for the GGF Transaction Management Research Group Tony Fletcher tony. fletcher@choreology. com 8 November 2004 Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Target • Appropriate transactionality for loosely-coupled systems • Loosely-coupled = autonomous, but cooperating § Inter-enterprise • Obviously autonomous – different owners § Intra-enterprise • Linked applications have different purposes Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Functional parts of coordination protocols PROPAGATI ON ENROLLMENT CONTROLLING APPLICATION SERVICE . APPLICATION BT # INITIATION participant coordinator Coordination Service CONTROL (factory) OUTCOME Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

BTP coverage • Initiation • defined with Control § Initiator: Factory – BEGIN, BEGUN • Propagation • details are application’s problem § Application: application – CONTEXT, CONTEXT-REPLY • Enrollment • defined with outcome § Enroller: Coordinator – ENROL, ENROLLED • Control § Terminator: Coordinator - lots • Outcome § Superior: Inferior - lots Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Protocol specification • The outcome protocol is fully specified by state tables • The other protocols are essentially request - response Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

One outcome protocol • Each branch of a business transaction involves § service asked to do some work, under control of the business transaction § service/participant promises to abide by the decision of the coordinator § coordinator makes the decision to confirm or cancel § outcome protocol is used to tell the participant § participant applies decision and replies Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

3 participant implementation patterns #1 Do-Compensate PREPARE = do + log parameters, CANCEL = reverse, CONFIRM = forget #2 Validate-Do PREPARE = validate + log parameters, CONFIRM = do, CANCEL = forget #3 Provisional-Final PREPARE = do, mark pending, CONFIRM = mark final, CANCEL = delete Pattern #3 permits “probabilistic inventory management” Market-sensitive, rule-driven inventory commitment • ACID is a pure form of Provisional-Final Copyright © 2004, Choreology Ltd Distributed, recoverable business • XA is an interesting use of Provisional-Final transactions

provisional, final and counter effects Forward Operations create a provisional effect … … and durably record information needed by Participant uses log to perform final effect or to counter- Service application message A (provisional) Log of A CONFIRM CANCEL finalise A counter A Participant Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Spectrum of approaches to Isolation… The BTM Spectrum Do-Compensate Validate. Do Provisional-Final ACID BTP WS-AT, WS-TXM ACID Copyright © 2004, Choreology Ltd WS-BA, WS-TXM LRA Distributed, recoverable business transactions

Compensation • appropriate where § early visibility has no bad external effects § system cannot handle provisional states… § and provisional states cannot be managed by adapters. • inappropriate where § irreversible external effects § pending is a distinct, visible state Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Explosion of external effects… effects Compensate that? ? ? Copyright © 2004, Choreology Ltd

Cohesions and atoms • Controlling application wants a consistent result • Perhaps not all the candidates are included • BT can be cohesive § controlling application will decide the final confirm set when it requests confirmation § prior to that can tolerate or force exclusion • BT can be an atom § every participant that enrols is in the final confirm set § All or none – each has veto power • Confirm sets are always internally atomic Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Implications of autonomy • Participants (or their owners) might have to break a promise § applies an “autonomous decision” to its resource • BTP § participant can inform superior immediately • If autonomous decision = correct (superior) decision, treat as response before request § reports broken promises (“hazard” = heuristic) § has qualifiers to state time limit on promise Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

The world around BTP • Legacy applications need to be linked and coordinated • Not all applications will be web-service enabled • BTP is: § web-service capable § but not web-service exclusive • Does not assume rich underlying function § Does not rely on ws-* § provide necessary mechanisms within BTP • Exploit underlying function if available § BTP mechanisms can be dropped if the infrastructure does provide Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Message set • Abstract definition § parameters § semantics • XML representation • Binding proforma § states what must be specified for a binding to any carrier protocol § which BTP mechanisms would be dropped – no limits • soap/http binding § a particular completion of the proforma § minimal assumption – doesn’t use other ws-*, so uses BTP mechanisms for final “routing”, redirection … § request/response exploitation Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Bindings and transport optimisations • Binding proforma allows explicit statement § doesn’t indirect through wsdl and wsdl binding § not limited to wsdl-expressible • only BTP implementations need to know (for which the wire format is the easy bit) • Transport optimisations § piggy-backing BTP messages on application traffic • “one-shot” exchange § request/response exploitation • multiple addresses in a role § different carriers (bindings) • “BTP address” is very like WS-Address, but identifies the binding intended § primary and back-up • “last resort” and redirection Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Other bindings • Revision process § § WSDL-compatible (BP compliant) soap binding everything is one-way less efficient than “soap-http-1” binding Also cover https Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Status • Many meetings March 2001 – May 2002 • Committee Specification 1. 0, 3 June 2002 • TC decided not seek OASIS std until implementation/deployment experience • Kept revision issue lists • All issues for 1. 1 now resolved • Planning to approve CD 1. 1 very soon Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Implementations • HP WST • Objectweb § treat as just another atomic • unpublished Australian group • Choreology Cohesions • Correctness proof using pi-calculus § Laura Bocchi, Univ of Bologna Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Revision issues • Bug fixes § § State table over-restrictions Mis-alignments – xml informal : schema Clarifications – things should be stated, not just assumed Missed parameter (only matters in an error case) § § § Different qualifiers for each inferior Late enrolment Automatic completion of empty cohesion Inferior identification with application work Interim acknowledgement for long-running transactions • Minor improvements/bug fixes Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Revision issues (2) • Web-service friendliness • claim against BTP “it isn’t web-service friendly” § no WSDL • • • Existing soap/http binding is difficult for wsdl Define a simpler binding WS-I BP-compliant Providing WSDL for that for both control and outcome Implementation can mix-and-match in different roles WSDL for control more useful Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

BTP 1. 1 • Into ‘last call’ in the committee now then to immediate vote - Should be ready in December 2004 • Won’t be directly interoperable with BTP 1. 0 § Minor differences in some messages § Deliberate difference in namespace • Will continue to be multi-carrier § Further bindings as people please • OASIS standard. . . Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

BTP roles Client side Service side Client Service Initiator/Terminator Enroller Factory Participant Transaction Decider (Composer or Coordinator) Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

BTP binding to SOAP/HTTP Client side Service side Client header – BTP body - app Service Initiator/Terminator Enroller body – BTP Factory Participant Transaction Decider (Composer or Coordinator) Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Application, as initiator, asks for creation of transaction Client side Service side Client BEGIN Service Initiator Factory Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Coordinator creation by Factory Client side Service side Client Service Initiator creates Factory Coordinator

CONTEXT supplied to Initiator Client side Service side Client Service BEGUN&CONTEXT Initiator Factory Coordinator Begun contains address and identifier of Coordinator used by Terminator Context contains address and identifier of Coordinator used from Distributed, recoverable business transactions Participant Copyright © 2004, Choreology Ltd

CONTEXT propagated with application message Client side Service side Client CONTEXT Service Initiator Factory Coordinator Context contains address and identifier of Coordinator Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Service chooses to create a Participant Client side Service side Client Service Initiator creates Factory Participant Coordinator Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Enrollment of Participant requested Client side Service side Client Service Initiator ENROL Enroller Factory Participant Coordinator Enroller may be part of application, part of Participant or a kind of factory Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Participant has been enrolled Client side Service side Client Service Initiator ENROLLED Enroller Factory Participant Coordinator Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Service replies Client side Service side Client CONTEXT_REPLY Service Initiator Enroller Factory Participant Coordinator

Repeat to other services as needed Client side Service side Client Initiator Factory Coordinator

Application, as Terminator, requests confirmation Client side Service side Client Service Terminator CONFIRM_TRANSACTION Enroller Factory Participant Coordinator Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Coordinator asks participant(s) to be prepared Client side Service side Client Service Terminator Enroller PREPARE Factory Participant Coordinator Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Participant makes the promise Client side Service side Client Service Terminator PREPARED Factory Coordinator Enroller Participant Don’t send PREPARED until sure the promise can be kept and is recorded Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

After promises from all, Coordinator tells Participant(s) to confirm Client side Service side Client Service Terminator Enroller CONFIRM Factory Participant Coordinator Don’t send CONFIRM until decision is recorded Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Participant reports it has confirmed Client side Service side Client Service Terminator Enroller CONFIRMED Factory Participant Coordinator Remove record of promise (or mark it as done) before sending CONFIRMED Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

After all reports in, tell the terminator Client side Service side Client Service Terminator TRANSACTION_CONFIRMED Enroller Factory Participant Coordinator Can remove record of confirm decision (or mark it as done) Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Terminator can ask for cancel instead Client side Service side Client Service Terminator CANCEL_TRANSACTION Enroller Factory Participant Coordinator Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Coordinator orders cancellation Client side Service side Client Service Terminator Enroller CANCEL Factory Participant Coordinator Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Participant reports cancellation Client side Service side Client Service Terminator Enroller CANCELLED Factory Participant Coordinator Copyright © 2004, Choreology Ltd Nothing has to be recorded Distributed, recoverable business transactions

After all reports in, tell the terminator Client side Service side Client Service Terminator TRANSACTION_CANCELLED Enroller Factory Participant Coordinator Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Cohesions: The Concept Buyer Cohesion Terminator Superior Composer Inferior Coordinators Superior Services Inferiors Participants #1 #2 Goods Atom Inferiors Participants Shipping Atom Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Cohesions: The Concept Buyer Cohesion Terminator Superior Composer Inferior Coordinators Superior Services Inferiors Participants PREPARE_ INFERIORS(1, 2) PRP #1 PREPARE Goods Atom #2 PREPARE Inferiors Participants Shipping Atom Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Cohesions: The Concept Buyer Cohesion Terminator Superior Composer Inferior Coordinators Superior Services Inferiors Participants PREPARED INFERIOR_STATUSESPRP’d #1 PREPARED Goods Atom #2 PREPARED Inferiors Participants Shipping Atom Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Cohesions: The Concept Buyer Cohesion Terminator Superior Composer Inferior Coordinators Superior Services Inferiors Participants CONFIRM_ TRANSACTION(1) CNF CAN #1 CONFIRM Goods Atom #2 CANCEL Inferiors Participants Shipping Atom Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Cohesions: The Concept Buyer Cohesion Terminator Superior Composer Inferior Coordinators Superior Services Inferiors Participants CONFIRMED TRANSACTION_ CONFIRMED CNF’d CAN’d #1 CONFIRMED Goods Atom #2 CANCELLED Inferiors Participants Shipping Atom Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Cohesion example – stock and option from multiple market makers Hedge Fund S O

Each make two time-limited binding quotes Hedge Fund S O ABN Amro O S

Hedge fund selects best of each, others are cancelled Hedge Fund S O ABN

Summary – BTP Characteristics 1 • Agree and know § what is meant or promised by sending a message • Do not need to agree or know § what motivated the sending of the message § how a promise will be kept • The cooperating systems are treated as autonomous – may use different techniques • Permits heuristic decisions § Time qualification of the ‘prepared’ promise Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

Summary – BTP Characteristics 2 • Defines messages abstractly then in XML • Supports application qualification • 5 sub-protocols and counting § Initiation, Control, Propagation, Enrolment, Outcome • Recovery and logging specified § uses repeating messages rather than special messages • Multi transport Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

BTP 1. 1 additions (1) Main change • Web-service friendly bindings. There is a new alternative protocol binding to http, which omits the btp: messages construct, and just puts the particular message in as a direct child of soap: header or soap: body. It does not support one-shot, but the use of it for the control relationship should make it easier to implement a. net thin client. Other changes are relatively minor fixes SOAP/HTTP binding now includes HTTP/SSL HAZARD after receiving CANCEL Qualifiers for each inferior on CONFIRM_TRANSACTION Allow repeat CANCELLED Minor state table corrections Superior identifier on other messages to inferior Bug fixes such as differences between xml schema and informal message description § Address priority attribute § § § § Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions

BTP 1. 1 additions (2) § avoid sending Fault when there superior_state/unknown or inferior_state/unknown should be sent § Allow late enrollments § CONFIRM_ONE_PHASE against autonomous confirm § report-hazard removed from CONFIRM_ONE_PHASE § Qualifier to allow automatic completion of all-cancelled cohesions § CONTEXT used only with application msgs, not with BEGIN, BEGUN - the previous combination BEGIN&CONTEXT is now done by embedding the context in the BEGIN § participant identification in context-reply § acknowledgements for LRT - there a set of new values for inferior_status, superior_status, which allow a node to reply that it has received a substantive message (prepare, confirm) but is not yet able to reply (with confirm/cancel or confirmed/hazard). § the XML namespace identifiers are all changed, including that on the qualifiers. Copyright © 2004, Choreology Ltd Distributed, recoverable business transactions