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


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
Summary:
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.

 

The basic relationship is of Superior to Inferior.  An Inferior does not, via the protocol, know if there are any 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.

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. 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. 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 - the 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.

 

 

Peter

------------------------------------------
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



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


Powered by eList eXpress LLC