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