RE: [bt-spec] BTP Issue 30 : Assume that coordinators are potentialsub-coordinators. (also issue 2)

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

This is effectively the question of whether a coordinator, created by BEGIN/BEGUN, and offering the Decider interface, can then become a Sub-coordinator by being enrolled in as Inferior with some pre-existing Superior, or if the only way to get a sub-coordinator is to make it such from its beginning, by issuing BEGIN & CONTEXT to the Factory.

 

First, some scoping points:

this only concerns us if the standard control relationship is in use. An implementation offering its own API to create and manipulate coordinators etc. will be free to do what it likes. It doesn't affect the Superior:Inferior relationships at all.

 

the answer will be the same for Composers/Sub-composers as for Coordinators/Sub-coordinators. (But I'm using Coordinator in this discussion for simplicity)

 

On the main point, there are three possible answers to the question:

   

But, on the main point, on reflection, it seems it would be rather more complicated to

    1) all Coordinators, created using BEGIN (no context), can subsequently be enrolled if the application desires

    2) the standard control mechanisms do not provide *any* support for enrolling an existing coordinator as an Inferior

   3) there is a standard mechanism, but not all Coordinators can be enrolled - this could be an implementation limitation; a choice indicated on the original BEGIN or similar.

 

However, on thought and discussion in Choreology, we realised that if it is to be 2) or 3), we need to define some more messages. When first created the Coordinator will think it is the Decider - it expects to receive CONFIRM_TRANSACTION from the Superior, at which point it (after soliciting PREPAREDs as needed) will make the confirm decision. But if it is to become an Inferior, it needs to know who and where it's new Superior is, since it will have to send PREPARED to it. So there would need to be either an "ENROL_YOURSELF" message with a related CONTEXT, requiring the Coordinator to issue ENROL, or a "YOU_ARE_ENROLLED", telling it that something else (the application), has done the ENROL for it) The coordinator would then switch behaviour. (the one-shot style of enrollment would also be possible)

 

This could be worked out, and it is possible to imagine uses for the ability, but they are distinctly exotic.  Almost the only use we've thought of is where a service pre-creates sub-trees, waiting for an incoming application request & CONTEXT, then links the sub-tree in. But this, and either of the approaches outlined, are getting into the service:participant interface area that we're avoiding at this stage becuase there are too many possibilities.

 

Having a standard mechanism also forces answers to several questions that we don't otherwise need to deal with (equals reduces implementation flexibility) - especially whether an address-as-decider can also be assumed to be an address-as-inferior, or if there can be different ones.

 

So, we propose that answer 1) is chosen.  A Coordinator, once created by BEGIN (no CONTEXT) will be a Decider. Sub-coordinator's are created with BEGIN & CONTEXT.. There is no "late enrollment".- sub-coordinator knows who its Superior is from the beginning.

 

Late enrollment could be added in a later version in a back-compatible manner, especially if answer 3) was adopted for version N > 1.

 

Which leads us to the following proposed solution. This includes some bits of issue 77's application that were not done originally because they depended on this. It also changes the phrase "top-level transaction" to "top-most transaction" to avoid confusion with nest building.

 

Proposed solution

 

In abstract message for BEGUN

 

Move address-as-inferior to follow address-as-decider

 

Change parameter inferior-handle to inferior-identifier, and change its type

 

In address-as-decider, change "top-level" to "top-most"

 

Change description for address-as-infeior to

address-as-inferior  for a non-top-most transaction (a CONTEXT was related to the BEGIN), this is the address-as-inferior used in the enrolment with the Superior identified by the CONTEXT related to the BEGIN. The parameter is optional (implementor’s choice) if this is not a top-most transaction; it shall be absent if this is a top-most transaction this parameter.

 

Change description for transaction-identifier to the following and add the note:

transaction-identifier  if this is a top-most transaction, this is an globally-unambiguous identifier for  the new Decider (Composer or Coordinator). If this is not a top-most transaction, the transaction-identifier shall be the inferior-identifier used in the enrolment with the Superior identified by the CONTEXT related to the BEGIN.

 

Note – The “transaction-identifier” may be identical to the “superior-identifier” in the CONTEXT that is related to the BEGUNThou

 

Delete inferior-handle desription

 

Delete the word "inferior" in the penultimate line of the penultimate paragraph of the abstract message description.

 

Align the XML, including making transacton-identifier always present .

 

 

Peter, on behalf of Choreology

 

 

 

 

 

 -----Original Message-----
From: Peter Furniss [mailto:peter.furniss@choreology.com]
Sent: 17 November 2001 01:51
To: bt-spec@lists.oasis-open.org
Subject: RE: [bt-spec] BTP Issue 30 : Assume that coordinators are potential sub-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
Detail:
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.

 

Peter