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 ()
Transactions Architect, HP 
Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203