At 10:48 AM 5/1/01 +0100, Mark Little wrote:
>
>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;
Per f2f definitions a service and a participant are different interfaces
(they may be the same entity - implemantation detail) , a service has a
business function interface while a participant has a BTP interface.
> 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.
It simply invokes a new service (depending on the context the
sub-coordinator of service invoked may register with the root coordinator
or with our 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.
Whether the service invoked implements both a business service interface
and a BTP interface depends on the implementation but as far as BTP
concerened there is an interface to coordinate the transaction, it might be
the service it self - we don't know.
>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 (<mailto:>)
>Transactions Architect, HP Arjuna Labs
>Phone +44 191 2064538
>Fax +44 191 2064203
>
>
