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

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

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]

---

2001-11-26.btp.trees_diagram.doc