Insulation from standards flux

How Cohesions insulates you from standards flux

Choreology is committed to implementing any viable, freely implementable, truly open standard for business transaction management that is demanded by our customers.

Choreology Cohesions is engineered to support multiple coordination protocols. The software industry has not yet settled on a single, universally accepted standard protocol for two-phase outcome coordination--and indeed it may never do so (although we think it should).

Cohesions 2.0 supports three coordination protocols: OASIS Business Transaction Protocol 1.0 (BTP), and the August 2002 edition of WS-Coordination+WS-Transaction/AtomicTransaction (AT), and WS-Coordination+WS-Transaction/BusinessActivity (BA).

Owing to the relative immaturity of the AT and BA protocols (which have already been revised by their authors, IBM, Microsoft and BEA, and which in March 2004 commenced review in a proprietary multi-vendor "workshop" process), and owing also to the licensing conditions attached to these specifications, we can only provide these implementations for the purposes of research and analysis. Our product is therefore only licensed for commercial use when using OASIS BTP 1.0. Users can switch the run-time protocols in use by configuration.

Use of the Cohesions API is not currently affected by the selection of underlying run-time coordination protocol. This fact powerfully demonstrates the functional closeness of these alternate protocols. (Generally speaking, with some minor exceptions, BTP can be viewed as superset of WS-AT and WS-BA.)

BTP was designed to be a multi-transport generic two-phase outcome coordination protocol. It allows for bindings to different message encoding schemes and underlying carrier protocols. The official specification currently only defines a binding to SOAP 1.1/HTTP 1.1, using an XML schema to define the message format. Cohesions also implements a proprietary binding of BTP to Java RMI. In future releases we expect to run BTP over JMS and other carrier protocols, in accordance with customer demand. Different participants may use different carriers concurrently, allowing disparate services to be brought together within the span of a single business transaction. OASIS BTP is being revised with the goal of producing OASIS BTP 1.1. This minor revision of BTP will likely incorporate bug fixes and small enhancements resulting from implementation experience since BTP 1.0 was approved in June 2002. We currently plan to implement BTP 1.1 in a future release of Cohesions, as and when it has been adopted as an OASIS Committee Draft. We anticipate very minor, additive effects on our current API as a result.

We apply similar principles to our use of WS-AT and WS-BA. As the standard specifications picture resolves, we intend to implement useful and viable specifications (which may be de jure or de facto standards) within our product. We will generally use extension features of more limited specifications to ensure a common level of functionality. Over time it may be necessary to disable particular aspects of our API when using a particular limited protocol.

We aim to minimize and if possible eliminate the effect of standards flux on customer applications, while working towards the ultimate goal of interoperation using standard protocols, as the category of Business Transaction Management software becomes firmly established.

Choreology technical staff participate actively in all current standards initiatives within the BTM arena, with a broad goal of achieving convergence between competing, but functionally close, specifications.