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)
- From: Peter Furniss <peter.furniss@choreology.com>
- To: bt-spec@lists.oasis-open.org
- Date: Thu, 07 Feb 2002 03:06:46 +0000
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC