Re: interposition requirements

[Sazi Temel <sazi.temel@bea.com>]

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:mark@arjuna.com>mark@arjuna.com)
>Transactions Architect, HP Arjuna Labs
>Phone +44 191 2064538
>Fax   +44 191 2064203
>
>