Mark (2)
I always assumed that different web services sites has
different participants (sub-coordinator), at least one, but might have more.
Looks like it is one of the condition to be a BTP aware site (application)
thus I do not see a sub-coordinator propagation, may be I misunderstand what
you mean by sub-coordinator propagation...
Not sure which Mark you mean, but I'll take a stab at it: first I don't see
that the participant and the sub-coordinator have to be different; if a
participating web service wants to propagate the context to other, back-end (for
example) web services then as well as doing it's own work when it's told to
"prepare" it sends this message to those back-end services, i.e., it acts like a
sub-coordinator. However, in order to do this, when it propagates the context to
these additional services it needs to re-write the context slightly so that the
coordinator URL is no longer the one that it received, but itself. Obviously
this means that the web service must support the coordinator interface and
appropriate functionality; if it can't then it can't do interposition - it's as
simple as that.
We (at the f2f meeting) almost agreed on that there are interfaces for
the roles such as initiator, coordinator, participant (sub-coordinator) and
the service then it is up to the application (and web service site) to
implement these interfaces as a single entity or different
entities..
I don't think a participant *has* to be a sub-coordinator. If it's a leaf
node, and does no further invocations to other BTP-aware services, then it's not
coordinating anything other than its own work. Even if it does propagate the
context, it may be physically unable to act as a sub-coordinator anyway.
Looks like there are pros and cons for both approach (flat structure
or tree like structure for coordination), may be it is better to let the
initiator make known its wish whether it wants to flat or tree like structure
and let the participants try to do their best to obey this wish (propagate
this wish to other participants)..
I don't think this is a decision that the initiator can, or
should, make. It depends upon too many factors that the initiator can't and
shouldn't be aware of: implementation (does the web service support
sub-coordinator operations), business logic (what's going on at the back-end),
connectivity (can the root actually talk to all participants), ... I believe
this is a decision that only the propagating web service should make (possibly
with some configurable option based on the application.)
It is really not more than a wish to have a flat transaction hierarchy
from the initiators point of view since any of the sub-coordinators can always
hide the sub-transactions from the main coordinator easily without violating
any protocol syntax (if we make a rule that it will always be a flat
structure, participants will violate the rule but still working
ok)
OK, as long as the requirement from the initiator is only a hint, and can
be ignored by the participating web services, I don't have a problem with
this.
I also noticed that we have been using participant and sub-coordinator
interchangeable (which is ok since they are the same entity), can I suggest to
use the sub-coordinator (and/or local coordinator) in the body of the protocol
doc as an alias for participant?
I've tried to use participant (web service) and sub-coordinator separately,
because one may not be the other.
Mark.
----------------------------------------------
Dr. Mark Little ()
Transactions Architect, HP
Arjuna Labs
Phone +44 191 2064538
Fax +44 191 2064203
