RE: [bt-spec] BTP Issue 62 : Names of the relationships

[Peter Furniss <peter.furniss@choreology.com>]

Sazi sent

Peter,
I agree that a diagram showing the actor/roles relationships as well as control and outcome flow will be useful. However I have found the two diagrams, although possible according to the spec, not very common. For example a coordinator:composer relationship where coordinator is a superior cannot be too common.  

 

A sub-composer (which is what that is) is certainly rather an odd beast - I sent some stuff on this last night on issue 69 (my thought was that something on that line should go in the document somewhere, at least at note status)

 

 I think, as far as Coordinator concerned the inferior is a participant and it does not know what else it is capable of doing.  

 

absolutely.   but there is some utility in having a distinct name for a "leaf" in the tree, that doesn't act as anyone's superior, even if this fact is unknown to its own superior.  So 0.9 uses "participant" for that, and just Inferior for an anything, as viewed from the superior.

 

 Beside a terminator:composer relationship is very different then a possible coordinator:composer relationship...  

 

Absolutely  - terminator:composer is the control relationship. A Terminator is a volatile, application-side entity - all it's messages are request/response pairs and it is always the requestor (so it's "client" to the Decider server, sort of). Coordinators and composers (of all subvarieties) are both persistent Superiors to some inferiors.

 

(the meaning of "Terminator" was modified slightly between 0.6 and 0.9. In 0.6, and the discussion in august on "volatile composer terminators", terminators were variously volatile application elements that requested confirmation of a transaction, persistent superiors that had logged the confirm decision and ordered the inferior, and might-have-been persistent superiors that turned out to have only one inferior so used REQUEST_CONFIRM to pass down a one-phase confirm semantic.  In 0.9 this was cleaned up - a Terminator is now always and only the application element that can REQUEST_CONFIRM of the top-of-the-tree (called a Decider as a term to cover both composers and coordinators that are not Inferior to anything). A persistent superior that orders its inferior to confirm is just a superior. In the special case of one-phase confirm where there is only one Inferior, the message was distinguished as ONE_PHASE_CONFIRM, which goes from the Superior to the Inferior.

 

 

 Do you think the coordinator will take a terminator role in this coordinator:composer (as superior:inferior) relationship?
 

 Not according to the current use of the word "terminator". The (sub)composer will send PREPARED to the coordinator, as inferior to superior, the coordinator then will send CONFIRM to the composer. What the composer then does with its own inferiors depends on application logic (see comment on issue 69 thread).

I have created a new diagram - modified one of yours - that I think shows the most possible relationships amongst the actors. It also shows the layered relationship where composer deals with coordinators and coordinator deals with participants only. In addition, I think there should be a link between the terminator and the coordinator (dashed lines in the diagram) so that in case there is no composer, the terminator can talk to coordinator (This could be another diagram too).
 

The diagram helps the discussion, thanks.  But it seems to use Participant effectively as a synonym for Inferior - what is the defining characteristic of "Participant" (it could be that it controls resources directly, not via further BTP branches, although it may have such (as superior) - that is a possible use, distinguishable from the one I've used, that it has no further BTP branches (and so would normal control resources directly)

 

But my diagrams were meant to show the relationships in a single static tree - the alternative possiblities at the top being shown by different diagrams. In any transaction tree there is at most one instance of the control relationship - everything below that is an Inferior to some Superior. If a coordinator has a superior, its Decider interface is switched off (at least as far as REQUEST_CONFIRM is concerned - some of the status commands might still apply)  (issue 30 is concerned about whether there it always has a Decider interface in the first place)

 

(the "at most" one instance of control is because the "terminator" might not be using the standard control operations, )

 

Peter

 
--Sazi

At 12:41 PM 11/26/01 +0000, Peter Furniss wrote:

Comment here affects several issues, some categorised as tech/minor tech. I'm using this issue just as a vehicle, though it is affected.
 
 
Several issues raised by various people suggest we need a diagram to explain the different relationships and the role names. Some of the role names have evolved a bit since the earlier discussions in the committee, and we sometimes are at cross purposes due to this.
 
I've done a little diagram that shows a couple of example trees, showing how the names are used in 0.9.
 
There are two distinct business transactions shown. The first one is a cohesion, run from composer b.  It has two inferiors (which thus may get different outcome decisions). One of these is a participant (d) (something that controls resource/data directly, without itself being a btp superior), the other is an atom coordinator (c) - since this is controlled via its inferior interface it is a sub-coordinator.
 
The second transaction is an atom, run from coordinator g. That has two inferiors - one is participant (i). The other is a cohesion - composer h, but which has two inferiors. Some piece of application logic related to h will decide which of its inferiors j and k will be its confirm-set (it could both or j or k or neither).
 
As shown, in both transactions the interoperable "control" sub-protocol is used by the (application-based) terminator to drive the business transaction - the control could be done with a proprietary mechanism).
 
This is a logical diagram, with no necessary relationship to where the actors are located (or indeed whether some of them might be the same program instance). For example, b and c may be in the same vm (in which case their b:c outcome (superior:inferior) relationship probably isn't really using the real interoperable protocol, though the logical relationship still exists.
 
 
I suggest that we include this diagram, or something like it, in the first part of the document. comments on it please, especially if it is contradicted by 0.9.   (I'm  not sure "participant" is consistently used in 0.9 to mean an inferior that has no inferiors of its own)
 
Peter
 
 

-----Original Message-----

From: Sazi Temel [mailto:sazi.temel@bea.com]

Sent: 21 November 2001 23:52

To: bt-spec@lists.oasis-open.org; bt-spec@lists.oasis-open.org

Subject: Re: [bt-spec] BTP Issue 62 : Names of the relationships

Do you think it may help to clarify if we use the concrete relationship names between the actors (or roles) such as Composer:Coordinator, Coordinator:Participant etc. I do not think there are too many of them. Then the more generic relationship such as inferior:superior or terminator:decider may be clearer. Perhaps we need a small section in the doc that explains these generic and more specific relationships.

--Sazi

At 04:35 PM 11/19/01 +0000, BTP issues maintainer wrote:

This issue has been added to the BTP issue list

BTP Issue 62 : Names of the relationships

Category: minor technical

Submitter: Alastair Green, Choreology

Description:

The two distinct relationships in BTP are called "Superior:Inferior" and "Terminator:Decider" in 0.9. These names are cumbersome, and in the latter case, not very accurate - the client-end application to coordination-facility relationship includes Initiator:Factory. Simple names would clarify.

The names "Control" relationship and "Outcome" relationship are suggested.

---

To comment on this issue, please follow-up to this announcement on the bt-spec@lists.oasis-open.org (replying to this message should automatically send your message to that list).

The current draft, with line numbers is available in pdf format and word format.

To add a new issue, please email to Peter Furniss peter.furniss@choreology.com. It helps if you propose a category (technical, minor technical, editorial, minor editorial).

---

Sazi Temel

Principal Consultant,

eCommerce Services, bea Systems, inc. [www.bea.com]

---

---

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

---