RE: [business-transaction] HPs position onBEAsproposalandtheChoreology response

[Mark Potts <mark.potts@talkingblocks.com>]

My aplogies to Asaf - my spell checker converts you ASAP  - sorry......

-----Original Message-----
From: Mark Potts [mailto:mark.potts@talkingblocks.com]
Sent: Thursday, October 25, 2001 8:45 AM
To: 'Alastair Green'; 'arkin'
Cc: 'Pal Takacsi-Nagy'; 'Cho, Pyounguk'; 'Mark Little'; 'btp'
Subject: RE: [business-transaction] HPs position on BEAsproposalandtheChoreology response

All;

 I am at a conference all week so am catching up on all the mails when I get home each day so forgive me if we are further ahead towards agreement than I think...

 

This is starting to fall out to be a couple of proposals for finding some middle ground... I think that many parties are looking at this from a black and white perspective and I would urge us to look for some grey, but equally effective, middle ground;

 

After reading the two proposals and the concerns of others expressed on the mail list I would suggest the following ( very rough here so I have not completely thought this through but hopefully its a way forward).

 

Conformance levels look to be surrounding three levels of complexity;

1) BTP Atom Transaction

2) Third Party Coordination (includes 1)

3) BTP Cohesive Transactions (includes 1 and can include 2)

 

These conformance levels are very sketchy and as such it seems to me that we need some people to step up and be in charge of a conformance subcommittee so the roles and responsibilities as well as features of each level are well defined - if its well defined enough then maybe we get enough separation between layers without having two completely separate protocols for each level.

 

Now to address the concerns raised by ASAP and I think BEA I would suggest ( and I am making a lot of work for others here including myself so we need to consider this carefully ) 3 primer documents for each conformance level based on the spec as a whole; We would obviously need an intro paper to define the overarching goals of BTP and the different conformant levels.

 

This would give BEA there ability to implement BTP at the level of functionality and simplicity called for by their customers (level 1) and any other companies to make a choice about what level of conformance they want to engineer to.

These are simply thought and my only concern again with this proposal is the amount of work and what it does to our schedule - however if it means agreement across the TC then I think we have to do it , or something along these line... Like I said at the beginning we need to look for some common ground and solutions here... that's why we have a committee and members with different view points we need a common ground, that offers benefit to as many people as possible such that adoption will be significant.

 

This approach is similar to other initiatives such as JCA in terms of conformance levels and I think with a primer to support each we have a real chance at mass adoption.

Anyway - I am sure many will disagree, but there it is.....

-----Original Message-----
From: Alastair Green [mailto:alastair.green@choreology.com]
Sent: Thursday, October 25, 2001 7:45 AM
To: arkin
Cc: Pal Takacsi-Nagy; Cho, Pyounguk; Mark Little; btp
Subject: Re: [business-transaction] HPs position on BEAsproposalandtheChoreology response

Hi Arkin,

I am looking at the BTP specification from the perspective of the BPML
specification, and one possible implementation. Since BPML can describe
the actions that make up a transaction, and where to draw transaction
boundaries within an encompassing process, while BTP specifies the
process for achieving reliable completion of the transaction, we see a
strong connection between these two specifications.

Good news.

In BPML we distinguish between atomic transactions and extended
transactions. We expect BPML-compliant implementations to use BTP,
alongside OTS, X/Open XA and TIP, for the purpose of demarcating and
coordinating atomic transactions. We would like to refer the reader of
the BPML specification to the relevant transaction protocol
specification that discusses atomic transaction, and would favor BTP as
the source for concepts and terminology.

More good news.

At the moment BPML does not deal with cohesive transactions, this is
reserved for a later version. Specifing support for atomic transactions
within BPML and assuring vendor conformance over four different
protocols is not a trivial manner, and we would like to complete this
part of the specification before proceeding.

It is extremely hard to reference the atom part of the BTP specification
as it currently stands, since the BTP specification is not broken into
two separate layers. To understand the atomic behavior, one must talk
about concepts and messages that are not relevant in the scope of an
atomic transaction, even if one is not required to implement them
(assuming conformance levels).

I disagree with this. The BTP specification 0.9 draft allows you to discuss things in terms of Atom Coordinators, Sub-coordinators and Participants (as did the previously published early draft 0.6).

What are the concepts and messages that are specific to Cohesions? Here is a list of the messages in BTP:

CONTEXT
CONTEXT_REPLY
BEGIN
BEGUN
ENROL
ENROLLED
RESIGN
RESIGNED
PREPARE
PREPARED
CONFIRM
CONFIRMED
CANCEL
CANCELLED
HAZARD
CONTRADICTION
SUPERIOR_STATE
INFERIOR_STATE
CONFIRM_ONE_PHASE
REQUEST_CONFIRM
REQUEST_STATUSES
INFERIOR_STATUSES
REQUEST_STATUS
STATUS
REDIRECT
FAULT

Not one of these messages exists because of Cohesions. If you pushed the point to the limit you could argue that REQUEST_STATUSES and INFERIOR_STATUSES are related to Cohesions, but they are usable (and add functionality) in an atomic Coordinator context.

Unfortunately, that means that we must still rely on OTS and/or X/Open
XA as the primary source for defining atomic transactions.

Why?

I would be more than happy to add a short section to the overly compressed "Overview of BTP" section in the current draft that explicitly and clearly discussed atoms and cohesions, and showed how BTP can be used at both levels. Here is what it would say:

"Earlier protocols for intra-organizational distributed transaction management such as X/Open DTP and the OMG Transaction Service are largely posited on the assumption of strict ACID behaviour, where all the parties to a transaction receive a single outcome (commit or rollback) instruction from a coordinator, and where the resources (persistence stores such as databases and queue managers) used by those parties to create effects block concurrent access before the transaction outcome is delivered. In this conventional model each party to the transaction can force a rollback by reporting to the coordinator that it is not prepared. Each Inferior and its associated operations can therefore safely share data with other Inferiors/associated operations that are part of the same transaction, as data changes that are exposed to other parties will either all be given final effect, or will all be counter-effected. In a conventional atomic coordination protocol it is also assumed (often implicitly) that "counter-effect" has one meaning: precise inversion of any state changes provisionally effected within a persistence store.

BTP provides a more flexible and extended approach to the completion of business transactions. BTP supports two types of business transaction: the Atomic Business Transaction (Atom) and the Cohesive Business Transaction (or Cohesion, for short).

An Atom is a business transaction which is managed by a specialized Superior called a Coordinator. A Coordinator is bound to deliver a single, common outcome to all of its enrolled Inferiors. It is bound to deliver CANCEL to each of them, if any one of them responds to a PREPARE message by sending a CANCELLED message. If all of its enrolled Inferiors respond to PREPARE by sending either PREPARED or RESIGN then it is bound to deliver CONFIRM to all of the Inferiors who sent PREPARED. Once a Coordinator has decided to deliver CONFIRM in this way it must preserve the ability to replay that delivery over failures of any component in the underlying networked computer systems, assuming access to durable secondary storage after recovery from that failure. The algorithm for deciding the outcome of an Atom is defined by this specification, and cannot be altered by a conformant implementation, or be interfered with by an application.

A Cohesion is a business transaction which is managed by a specialized Superior called a Composer. A Composer may deliver different outcomes to each of its enrolled Inferiors. It may deliver a common outcome (CANCEL or CONFIRM) to all of its Inferiors, in which case it has a similar final effect to an Atom. A Cohesion's behaviour is therefore a superset of the behaviour of an Atom.

If a Composer delivers CONFIRM to a subset of its Inferiors then it must deliver CANCEL to the rest, at the same time. It must preserve its ability to replay that delivery to the confirmed subset over failures of any component in the networked computer systems, assuming access to durable secondary storage after recovery from that failure. The decision of a Composer as to which Inferiors will become part of the confirmed subset (and therefore which will be part of the cancelled subset) can be made using any algorithm that the implementer or application may decide to offer or use. The purpose of a Cohesion is to allow dynamic modulation of the membership of a transaction, utilizing arbitrary business logic to reduce, over time and in reaction to application events and state values, the set of candidate Inferiors to a subset whose members are to be sent CONFIRM. The final confirmation subset receives an internally consistent outcome, i.e. in the last analysis it is an atomic set.

A Coordinator's Atom is identifed by a CONTEXT message, which contains a value that marking the CONTEXT as representing an Atom. A Composer's Cohesion is identified by a CONTEXT message, which contains a value marking the CONTEXT as representing a Cohesion. If an application operation that is party to a business transaction receives an atomic-valued CONTEXT it can safely share provisional state changes with an operation which has received the same atomic-valued CONTEXT. This assumption of safe provisional state sharing cannot be made if two operations receive the same cohesion-valued CONTEXT.

An Inferior enrols with a Coordinator in exactly the same way that it enrols with a Composer. An Inferior cannot tell from the messages it sends and receives (in terms of their values, sequence or its own resultant state changes) whether its Superior is a Coordinator or a Composer. An Inferior may also act as a Superior to its own set of enrolled Inferiors (i.e. act as an inner node in a tree of Inferiors which is rooted at a Superior), but its own Superior is ignorant of that fact.

An actor playing the double role of Inferior and Coordinator is termed a Sub-coordinator. An actor playing the double role of Inferior and Composer is termed a Sub-composer.

An Inferior that does not simultaneously act as a Superior is termed a Participant. Participants are leaf nodes in the tree previously described. In BTP the behaviour of Participants (their implementation of their required reaction to the receipt of PREPARE, CANCEL and CONFIRM) -- other than the recording of their Superior address for failure recovery before responding to PREPARE -- is entirely application-defined. While a Participant may use strict state undo and two-phase locking to produce fully serializable behaviour in conjunction with an Atom Coordinator, it may also use any other technique or type of state changing behaviour to reflect the needs of the application. This flexibility of implementation of Participants (allowing, for example, the use of compensating actions in reaction to the receipt of CANCEL), distinguishes BTP from earlier standardized distributed transaction protocols. It reflects BTP's cardinal premise that the parties to a business transaction can be autonomous business entities. In this case that premise translates into provision for reduced serializability.

BTP uses conformance profiles to allow implementers and their customers to select which features of BTP are made available for interoperation with the implementations of other vendors. A partially conformant BTP implementation can therefore offer atomic Coordinator capability, without offering the superset capability to compose Cohesions. Likewise, an implementation might offer only the ability to act as a Participant. Please refer to the section of this specification entitled 'Conformance' for more details."

It would be extremely helpful if a complete, self-contained discussion
of atomic transactions and specification of all actors, messages and
behaviors that only pertain to atoms was introduced as a standalone
document.

I think that this flows from a misunderstanding. I hope that the sections of my reply above will illustrate why I say this.

 

We will find this approach extremley helpful in building specifications
that leverage the work done on behalf of BTP, and would in fact allow us
to rely on the BTP specification for introducing terminology and
concepts.

I believe you will be able to do so easily, using the existing approach. In effect we have an inheritance hierarchy. The base interfaces Superior and Inferior can be specialized. A specialized Superior called a Coordinator interacts with a specialized Inferior called a Participant. A specialized Inferior called a Sub-coordinator is also a specialized Superior, because it acts as a Coordinator to its enrolled Inferiors. Etc.

In OTS terms the latter sentence reads: A specialized Resource called an interposed coordinator is also a Coordinator, which acts in that role with respect to its registered Resources.

In order to support this view, I would like to introduce as evidence
related specifications where the same approach has been taken. One is
the SOAP 1.2 specification, which has been broken off into two parts,
one dealing with the messaging framework [1] and one dealing with
encoding and protocol bindings [2]. The other is the XML Query
specification which consists of four different documents. XQuery itself
is fully specified in one document [4], while the XML syntax for XQuery
(XQueryX) is covered in another document [3]. (The other two specs deal
with the underlying model and function library)

I am fully aware that the separation into two documents will have an
affect on the work done by members of this group. At the very least it
will require the management of two separate documents. However, I urge
you to consider such a separation, for the benefit of a future body of
work that will rely on the BTP specification.

I just don't get it. We're now down to the level of presentation, pure and simple.

BPML can make statements like this:

"BPML uses the concepts and terminology of the OASIS Business Transaction Protocol to specify the use of atomic transactions. In this version BPML relies only on those features of BTP that are comprised within the Atomic Conformance Profile of the BTP specification. Therefore, BPML does not currently support the use of BTP Cohesive Business Transactions, nor does it support the concept of a Coordination Hub.

The following terms are used by BPML with the meaning ascribed to them by BTP:

Atom
Coordinator
Sub-coordinator
Participant

The following BTP messages are used by BPML:

CONTEXT
CONTEXT_REPLY
ENROL
ENROLLED
RESIGN
RESIGNED
PREPARE
PREPARED
CONFIRM
CONFIRMED
CANCEL
CANCELLED
HAZARD
CONTRADICTION
SUPERIOR_STATE
INFERIOR_STATE
CONFIRM_ONE_PHASE
REQUEST_STATUS
STATUS
REDIRECT
FAULT"

Or I can rephrase this as:

"BPML uses the concepts and terminology of the OASIS Business Transaction Protocol Specification Part I: Atomic Business Transactions to specify the use of atomic transactions. In this version BPML relies only on those features of BTP that are comprised within the Bilateral Conformance Profile of the BTP specification. Therefore, BPML does not currently support the concept of a Coordination Hub.

etc (identical to the previous edition)."

This seems to be a truly trivial difference for BPML. What is being proposed for BTP is quite a lot of work, for no real gain in understanding.

In fact, as Atoms are subsets of Cohesions, it would only make sense to write the "real BTP spec" in terms of Cohesions, and then write a two-pager that says: Here is a restricted Cohesion called an Atom. When we're in Atom land we call Composers Coordinators, etc etc. Otherwise we have the problem of describing a real car in terms of a toy car. (Fill the cavity under  the hood, with an Engine. An Engine is a ....)

Of course it can be done, but I think the case is not strong. We have a viable alternative approach.

I hope this answers your concerns,

Alastair