OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [bt-spec] BTP Issue 25 : Clarity needed between atomic and cohesion

Some comments on Issue 25.


At 06:03 PM 11/19/01 +0000, Peter Furniss wrote:
This relates to several of the other issues too.
 BTP Issue 25 : Clarity needed between atomic and cohesion
Category: technical
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue D
Greater clarity needed between atomic and cohesion--the terminology for cohesion makes the terminology for atomic less clear

Detail: The draft attempts to reconcile two different levels and kinds of protocols: one where the action fails or succeeds (Atomic), and another where a higher level protocol (Cohesion) deals with the recovery from failures while working toward a more complex goal. Abstract terms (e.g. superior/inferior) require confusing "mental casting," especially since an actor can be either of those roles in a binary interaction.

Proposed Remedy: Define conformance so that "core conformance" is all and only what is needed for atomic. Creating separate sections for Atomic BTP and Cohesion BTP would clarify. Ensure that Atom can stand alone.
The point has been stated before, but I believe there is no layering between cohesion and atom. There *is* a layering in btp, with the client: coordination facility relationship layered on the superior:inferior relationship.  Since the cohesion or atom distinction is only marginally (but importantly) visible in the superior: inferior, but conspicuous in the client:coordination relationship, the second layering looks a bit like the first, but is really very different.


I belive there is a very clear layering between these two. Composer (or Subcomposer) only deals with Coordinators. You may call them superior or inferior relationship but the only answer for the question of "who are the inferiors of Composers or Subcomposers?" is always the Coordinator. Is there any other answer? Now, that clearly indicates that superior:inferior relationship between Composer/Subcomposer and Coordinator hides this fact of clear layering between Cohesion and Atom.

The basic relationship is of Superior to Inferior. 

This is true for any binary relationships between any BTP actors. But it is one view of how we look at the relationship in general. One cannot get much information on a particular relationship by just defining it superior:inferior relationship, in fact almost all the relationship amongst BTP actors are superior:inferior relationship. On the other hand a relationship between Coordinator and Participant is very clear and definite one. I am afraid using only one view (superior:inferior) will not give a complete picture..
An Inferior does not, via the protocol, know if there are any other Inferiors,

I think (if I do remember correctly) coordinator sends the list of the participants in one of the message sent to participant thus in some cases some inferior knows other inferiors...
or what will happen to them. Nor does it know if the Superior is the "top of the tree" or if the Superior itself has a Superior to which it will send PREPARED and from which it will be told the outcome to pass on to this Inferior. Similarly, the Superior does not know what lies behind the Infeiror -whether it is directly responsible for applying confirm/cancel to some local resource, or is itself a sub-coordinator or sub-composer that will propagate the outcome.

That is good and correct.

In this light,  all a Composer knows about it's Inferiors is that they are its Inferiors - it will eventually deliver to each an outcome appropriate to that Inferior. It cannot tell whether they are Participants, sub-coordinators or sub-composers.

As explained above, I think there is only one possibility for the inferior of Composer (and Subcomposer), that is the coordinator! I don't think Composer/Subcomposer deals with any other actors other than Coordinator. I think "knowing only that they are inferiors" is almost saying "knowing nothing!", I belive there are limited possibilities of relationships, a composer knows that its inferiors are coordinators, and a coordinator knows that its inferiors are participants (but does not know what lies behind the participant) etc.
But that's all a coordinator knows about its Inferiors as well.  The only difference is that a Coordinator will deliver the same decision to all its Inferiors, and a Cohesion won't (or at least, might not).

Earlier on, we did talk about a Cohesion being made up of Atoms, but in doing so we went beyond what the protocol actually communicates.

This still holds.. Cohesion are made up of Atoms.
Each Inferior does get a single outcome delivered to it, but what it then does with it is not the Cohesion's problem. (it can even be a sub-composer, which might decide very late which of *its* inferiors will actually be used to deliver on the confirm it had already promised to its superior [think contracts - an analogy might be the car rental company which promised to get you a class C vehicle but doesn't decide which one until confirmation ]

Vital to Cohesions is that once it has been decided which of its Inferiors will be its confirm-set, the subsequent behavior is fully atomic - t

he Composer must log the identities and addresses of the Inferiors in the confirm-set and must do the regular recovery sequence with them (obviously if they are co-located some of this folds together, but the logical relationship is there).  Recovery from failures after the confirm-set is decided is identical between Cohesions and Atoms.

Rather than Cohesions being layered on Atoms, an Atom is just a special case of Cohesion - one in which the algorithm for deciding the confirm-set is that anything that enrols (and doesn't resign) is in the confirm set.

I think both are correct depending on where you are looking from.. Cohesion is layered on Atoms (the fact), a Cohesion cannot exist without Atom. And if one look at Cohesion and Atom from the termination protocol point of view, one sees that cohesive transaction needs thus includes the atomic transaction but atom does not need thus does not include cohesive transactions.


Peter Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX

Sazi Temel
Principal Consultant,
eCommerce Services,
bea Systems, inc. [www.bea.com]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC