RE: interposition requirements

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

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... 

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..

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).. 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)

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?

--Sazi

At 12:08 PM 4/30/01 -0700, Mark Potts wrote: 
>>>>
> Mark (1)
>   
> I agree with most of the mail and as long as we can agree that the subcordinator has the ability to either propagate its own coordinator, and thus hide the subsequent invocations, or the root then I think this gives the most flexibility. I agree with your comments on performance with regard to the intranet example but in a private trusted federation of services then registration back to the root from all participants in the chain is appropriate, and even registration to a separate transaction coordination service for the federation of services. It also means that performance is better and the latency that will be evident in "walking the tree" will avoid the possibility of failure scenarios corrupting the coordination of the termination.
>   
> Mark (2)
> > -----Original Message-----
> > From: Mark Little [mailto:mcl@arjuna.com]
> > Sent: Monday, April 30, 2001 4:28 AM
> > To: bt models
> > Subject: interposition requirements
> >
> >  I've been talking to Jim Webber and Savas P. who attended last weeks face-to-face. From their notes, and from little I could hear on the teleconference, it would appear that there was some discussion about sub-participant registration. In this email I'll term the web services that a client interacts with directly the root-participants, and any web service that those services talk to the sub-participants.
> >
> >
> > Now, a root participant receives a context it must be BTP-aware (and I think we agreed on this at the meeting). Therefore, at some point in its life it will register with the coordinator as a root-participant that can be driven during the termination protocol. If during the course of an application invocation a root participant needs to contact another BTP-aware service, the question is, where does the sub-participant register?
> >
> >
> > In a traditional TP environment, if all participants had to register with the root coordinator then performance would typically be in the drain, especially if one node has lots of participants. Therefore, the typical way to get round this is to use interposition, whereby a proxy for the transaction manager (a sub-coordinator) is registered with the root, and local participants register with the sub-coordinator. The advantage to performance is obvious. However, interposition is not mandated, and a participant that wants to register back with the root coordinator is (usually) free to do so.
> >
> >
> > So, do we want something like this in BTP? From what I've heard, the answer was no. I disagree with this for several reasons:
> >
> >
> > (i) performance: see above.
> >
> >
> > (ii) trust: the root coordinator may only trust requests (e.g., registration) from the root services.
> >
> >
> > (iii) connectivity: there may be no direct route to the root coordinator for the sub-participants, e.g., an intranet with only a few external ip addresses, but which has lots of internal web services.
> >
> >
> > What I would suggest is that we allow interposition, such that if a sub-participant receives a context, it is up to the service that sent it whether or not it wants to modify the context to point to a sub-coordinator and not directly back to the root coordinator. The sub-coordinator piece to this puzzle is not web service specific, so we're not putting a burden on the application developer; it's something that can be developed once for all time.
> >
> >
> > Mark.
> >
> >
> > ----------------------------------------------
> > Dr. Mark Little (<mailto:mark@arjuna.com>mark@arjuna.com)
> > Transactions Architect, HP Arjuna Labs
> > Phone +44 191 2064538
> > Fax   +44 191 2064203
<<<<