oasis business transaction protocol: multi-party coordination for commercial collaborations

Copyright © Choreology Ltd. March 2002

Choreology® The Interplays of

Commerce

OASIS Business Transaction Protocol:

Multi-party Coordination for Commercial Collaborations

[email protected]@[email protected]

March 2002

Choreology® The Interplays of Commerce

2 www.choreology.com

BTP Overview – OMG Web-services. Copyright © Choreology Ltd. March 2002

Goals

Inter-organizational multi-party coordination

Targetting Web Services, but not only WS

Accommodate Long-running Transactions




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




The key BTP roles

Application

Client side Service side

Protocol

Client

Initiator/Terminator

Service

Transaction Decider(Composer or Coordinator)

Participant

Enroller

Factory




Ask Factory to Create top coordinator

Application


Protocol

Client


Service

Coordinator Participant

Enroller

Factory

BEGIN / BEGUN&CONTEXT

creates




Send Application Message with CONTEXT

Application


Protocol

Client


Service


Enroller

Factory

CONTEXT




Service creates and causes ENROL of Participant

Application


Protocol

Client


Service


Factory

Enroller

createsENROL / ENROLLED




Send Application Reply with CONTEXT_REPLY

Application


Protocol

Client


Service


Enroller

Factory

CONTEXT_REPLY




CONFIRM_TRANSACTION

Application


Protocol

Client


Service


Factory

EnrollerCONFIRM_TRANSACTION




Two-phase Confirmation: PREPARE phase

Application


Protocol

Client


Service


Factory

EnrollerPREPARE / PREPARED




Two-phase Confirmation: Outcome phase

Application


Protocol

Client


Service


Factory

EnrollerCONFIRM / CONFIRMED




TRANSACTION_CONFIRMED Reply

Application


Protocol

Client


Service


Factory

EnrollerTRANSACTION_CONFIRMED




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




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 to counter-

effect

A (provisional)

finalise A

counter A

Log of A

Participant

Service

CONFIRM

CANCEL

Service sideClient side




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




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




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

A

B

finalAB

counterAB

Operation Group

Log of A, B

Participant

Service

CONFIRM

CANCEL

Service sideClient side




Superior-Inferior Relationship - outcome

Superior

InferiorPREPARECONFIRMCANCEL

PREPAREDCONFIRMEDCANCELLED

ComposerCoordinatorSub-composerSub-coordinator

Sub-composerSub-coordinatorParticipant




Transaction Tree - 1

Superior[e.g. Coordinator]

Inferior[Participant]







Superior[e.g. Coordinator]




Inferior/Superior[e.g. Sub-coordinator]





Superior[Composer]




Inferior/Superior[e.g. Sub-coordinators]




Coordination Hub: control and outcome

relationships

Application

Client

Service

Protocol

Client


Service

ParticipantFactory

Enroller

Coordination Hub

Transaction Decider(Composer or Coordinator)

controloutcome




Cohesions: The Concept

SuperiorComposer

InferiorParticipant

ShippingAtom

InferiorsParticipants

ServicesBuyer

GoodsAtom

InferiorCoordinators

Superior

CohesionTerminator

#1

#2




Cohesions: PREPARE both Atoms

SuperiorComposer

InferiorParticipant


ServicesBuyerInferior

CoordinatorsSuperior

CohesionTerminator

P

P

PREPARE

PREPARE

PREPARE

#1

#2

PREPARE_INFERIORS#1, #2

ShippingAtom

GoodsAtom




Cohesions: both are PREPARED

SuperiorComposer

InferiorParticipant




CohesionTerminator

INFERIOR_STATUSES

#1 P’d

#2 P’d

P’d

P’d

PREPARED

PREPARED

PREPARED

ShippingAtom

GoodsAtom

#1

#2




Cohesions: CONFIRM #1 ( CANCEL #2)

SuperiorComposer

InferiorParticipant




CohesionTerminator

CONFIRM

CANCEL

CONFIRM

CANCEL

CANCEL

CONFIRM_TRANSACTION#1

ShippingAtom

GoodsAtom

#1

#2




Cohesions: #1 CONFIRMED, #2 CANCELLED

SuperiorComposer

InferiorParticipant




CohesionTerminator

INFERIOR_STATUSES

#1 CO’d

#2 CA’d

CO’d

CA’d

CONFIRMED

CANCELLED

CANCELLED

ShippingAtom

GoodsAtom

#1

#2




Cohesions rely on “Open-top” Coordinator

CohesionComposer

“Open-top”Atom

Coordinators

CohesionTerminator

CONFIRM / CONFIRMED

#1

CONFIRM_TRANSACTION#1

INFERIOR_STATUSES

#1 CO’d

#2 CA’d

PREPARE / PREPARED

CANCEL / CANCELLED

PREPARE / PREPARED

#2




Example: Cross-company Securities Trading

Hedge Fund

ABN Amro

Nomura Commerz DKB

O SO S O S O S

Stock and option – from different market makers





Hedge Fund

ABN Amro

Nomura Commerz DKB

O SO S O S O S

Each market maker makes two guaranteed time-qualified quotes = PREPARED, from 2 participants each





Hedge Fund

ABN Amro

Nomura Commerz DKB

O SO S O S O S

Hedge fund chooses one of each, cancels the others (or lets them timeout)




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




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




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




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




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




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




Do Business Together with Business Transactions Ensuring Collaboration for XML Services

Internal Business Process

Collaboration ProcessBTP

Internal Business Process

Collaboration ProcessBTP

oasis business transaction protocol: multi-party coordination for commercial collaborations

Documents