business transaction management software for application coordination oasis btp scope, status and...

Business Transaction Management Software for Application CoordinationBusiness Transaction Management Software for Application Coordination

OASIS BTPscope, status and directions

Peter FurnissChoreology Ltd

[email protected]

Oasis Symposium, New Orleans, 26 April 2004

26 April 2004Copyright © 2004, Choreology Ltd


origins

• OASIS Business Transactions TC– First meeting march 2001– Initiator BEA– Initial submissions BEA, HP, Choreology

• BEA – outline based on product• HP – ancestor of WS-CAF• Choreology – requirements outline

– Protocol designed from scratch– Microsoft and IBM weren’t involved


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


CONTROLLING

APPLICATION

.

SERVICE

APPLICATION

CoordinationService(factory)

participant coordinator

CONTROLOUTCOME

PROPAGATION ENROLLMENT

BT #

Functional parts of coordination p’cols

INITIATION


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


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


Spectrum of approaches to leakage of effect

The BTM Spectrum

ACIDACID

Do-CompensateDo-Compensate

Provisional-FinalProvisional-Final

Validate-DoValidate-Do

BTPBTP

WS-AT, ACIDWS-AT, ACID

WS-BA, LRAWS-BA, LRA


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

• XA Emulation is an interesting use of Provisional-Final


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


Explosion of external effects…

effects

Order

Order

Compensate that???


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 always have uniform outcome


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


The world around BTP

• Legacy applications need to be linked and coordinated• Not all applications will be web-service enabled• BTP needs to be:

– web-service capable– but not web-service exclusive

• Do not assume rich underlying function– don’t rely on ws-*– provide necessary mechanisms within btp

• Exploit underlying function if available– btp mechanisms can be dropped if the infrastructure does provide


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


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


Other bindings

• Proposed in current revision– WSDL-compatible (BP compliant) soap binding– everything is one-way– less efficient than “soap-http-1” binding

• Choreology Cohesions also does– BTP over Java RMI– BTP over Corba– BTP over JMS– developing an optimised binary format (non-xml)


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

• Currently resolving issues• Planned CD 1.1 soon


Revision issues – not finalised yet

• Bug fixes and minor improvements• 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


Implementations

• HP WST• Objectweb

– treat as just another atomic• unpublished Australian group• Choreology Cohesions

• Correctness proof using pi-calculus– Laura Bocchi, Univ of Bologna


WS-BA flexibility: or a completely separate specification ?


The cost of bespoke coordination protocols

Coordinator A

Specific Participants

Coordinator B

ABCABC

ABC

PQR

PQR

PQR

AppX

AppY

AppZ

Specific Protocols


Convergence ?

• Who is as important as what !• Alternative binding could use WS-C or WS-CTX in place of

own context, enrollment• If WS-BA becomes more flexible

– It does full BTM spectrum – not compensations only– BTP is history

• If WS-BA stays compensation-only– Three competing standards– BTP supports the full BTM spectrum with one protocol– WS-CAF needs three or more

• WS-AT or WS-TXM ACID have a market role

business transaction management software for application coordination oasis btp scope, status and...

Documents