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 30 : Assume that coordinators are potentialsub-coordinators. (also issue 2)

 BTP Issue 30 : Assume that coordinators are potential sub-coordinators.
Category: technical
Submitter: Bill Cox, (for all BEA members)
Submitter's identification: issue I
Per Alistair Green's "wrinkle" in email on 20011023. We agree with him that all coordinators should be assumed to be potential sub-coordinators. This avoids a legacy integration problem that he points out, as well as simplifying the coordinator definition.
Proposed Remedy:
Add text to the Draft so stating.

 The "wrinkle" (from Alastair's email) was:

But, thereís one wrinkle, which Peter brought to my attention, and as heís half on holiday in South Africa, Iíll take it up. Iíve mentioned it already in an earlier posting. If you create a coordinator, and it doesnít have an open top, then it canít be a sub-coordinator, i.e. it canít be enrolled with an existing Superior. Do we always assume that coordinators are enrollable, i.e. are potential sub-coordinators? If we are covering legacy systems with a BTP Coordinator we might run into this issue. Iíd like to know what others think of this. (As there are no legacy composers and composers must be attacked two-phase, the issue doesnít arise for sub-composers.)

Actually, the legacy problem I thought might occur was the other way round - a coordinator that insisted on being top of the (recoverable) tree, and wasn't willing to send "prepared" to something outside.
In 0.9, the partial sentence in BEGUN (issue 2) was caused where I stopped writing to think about the question and I never got back to it.
The text that is there for BEGUN says that you must decide when the new node is created (i.e. when BEGIN is issued) whether this is to be a top-level Decider (confirm requested directly from a (volatile) Terminator, using REQUEST_CONFIRM) or an intermediate node (offers PREPARED to its Superior and hopes to receive CONFIRM from the Superior after it (the Superior) has logged confirm).  If it is to be top-level, BEGIN is issued without a related CONTEXT and the Factory supplies an address-as-decider on BEGUN, but no address-as-inferior (so you can't later enrol it). If it is to be an intermediate, BEGIN has a related CONTEXT (BEGIN & CONTEXT), the Factory does the enrol with the Superior, and BEGUN has no address-as-decider and need not have an address-as-inferior (because the enrollment has already been done, what are is anyone else going to send to it as an Inferior.
However, that concerns only the interoperable "control" relationship (Initiator + Terminator : Factory + Decider). If the creation and control of business transactions does not use the interoperable protocol, obviously the implementation can do what it likes. We are only talking about what a separate coordination hub would do.
there are three possibilities for the separate hub:
a)  all (top-level) coordinators also have an address-as-inferior and can therefore be enrolled with a superior after their creation
b)  it is optional
c)  top-level coordinators can never be enrolled as superior: something is either a top-level coordinator, with the decider "interface", or an intermediate with the inferior "interface"
0.9 says c), but that is restrictive. a) is really quite demanding (it also means you can grow a transaction tree "upwards"). If its an option, then is it an implementation option (some hubs do, some don't) or should there be a control.
Personally, I'm not sure which we should go for at the moment.

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

Powered by eList eXpress LLC