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 62 : Names of the relationships

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


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


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


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

Powered by eList eXpress LLC