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