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

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

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. I think, as far as Coordinator concerned
the inferior is a participant and it does not know what else it is
capable of doing. Beside a terminator:composer relationship is very
different then a possible coordinator:composer relationship... Do you
think the coordinator will take a terminator role in this
coordinator:composer (as superior:inferior) relationship?

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

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

---

2001-11-26.btp.trees_diagram_layered.doc