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

[Sazi Temel <sazi.temel@bea.com>]

Some comments on Issue 25.

--Sazi

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

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.

 

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 ]

Yes.

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

Yes.

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.

Yes.

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

------------------------------------------

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]

---