Business Transaction Management Software for Application Coordination OASIS BTP scope, status and directions Peter Furniss Choreology Ltd Oasis Symposium, New Orleans, 26 April April 2004 Copyright © 2004, Choreology Ltd

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination CONTROLLING APPLICATION. SERVICE APPLICATION Coordination Service (factory) participant coordinator CONTROL OUTCOME PROPAGATIONENROLLMENT BT # Functional parts of coordination p’cols INITIATION

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination Spectrum of approaches to leakage of effect The BTM Spectrum ACID Do-Compensate Provisional-Final Validate-Do BTP WS-AT, ACID WS-BA, LRA

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination Explosion of external effects… effects Compensate that???

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination 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)

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination 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

Business Transaction Management Software for Application Coordination Implementations HP WST Objectweb –treat as just another atomic unpublished Australian group Choreology Cohesions Correctness proof using pi-calculus –Laura Bocchi, Univ of Bologna

Business Transaction Management Software for Application Coordination WS-BA flexibility: or a completely separate specification ?

Business Transaction Management Software for Application Coordination The cost of bespoke coordination protocols Coordinator A Specific Participants Coordinator B ABC PQR App X App Y App Z Specific Protocols

Business Transaction Management Software for Application Coordination 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