Mark,
One
thing I forgot to include in my original reply. There are two places that
BTP might be used. To coordinate calls among disparate, external web
services and to coordinate calls to XML based services within an organizational
boundry. The registration of sub-participants with the root
coordinator was being proposed as an optimization for the
latter.
=bill
-----Original Message-----
From: Mark Little
[mailto:]
Sent: Monday, April 30, 2001 11:34
AM
To: Bill Pope; bt models
Subject: Re: interposition
requirements
I
believe what was discussed at the face-to-face was disallowing or
restricting the ability of a sub-participant to register
with the root coordinator. Is that the point that you're
addressing? The other side of the coin, dis-allowing
registration of a sub-participant with a sub-coordinator isn't really
possible. A root participant may initiate back end transactions,
either BTP or other, without the root coordinator being
aware.
I think we're talking about the same thing. A
sub-participant may not be able to register with the root coordinator (and I
think the majority of the time won't want to). Typically only those web
services that the initiator talks to directly will register with the root
coordinator.
One of the issues raised was the trust issue.
It is difficult to establish trust from a sub-participant back to
the root coordinator when the only context
information is a transaction identifier.
Agreed, and this is what I said in the last email.
However, (and perhaps there was a misunderstanding about what was discussed),
I was under the impression that all web service participants were going to be
forced to register with the root coordinator.
One of the arguments favoring registration of a
sub-participant with the root coordinator was performance. Would the
proponents of this please correct me if I get this
wrong. The position was that flattening the coordination space
provided more control of the participants. Any time
delays were minimized because messages were sent to all participants,
including sub-participants at the same time rather
than requiring a sub-coordinator to act as an application
proxy and forward any commit or cancel
requests.
If people are saying that sending (for example) 1000
SOAP requests over the internet is more performant that 2, and 998 over a LAN
then I'd like to see some justification for this. Unless you can use a
broadcast medium, and even then it would have to be over something like
dedicated ethernet with more than 4 participants, then flattening the tree
will not give you better performance. What we're talking about is trading
internet calls for intranet calls whenever possible. Obviously there may be
cases where sub-coordinators talk to "locally" registered participants over
exactly the same network as the root coordinator would, but that's not always
going to be the case. Interposition has been used in many systems (not just
transactions) for years, and its used precisely because it typically improves
performance.
I heard that there was some attempt to justify this
root-registration policy on the grounds of removing a bottleneck from the
sub-coordinator? So, let's just get this straight: we're trading the perceived
bottleneck of the sub-coordinator for the definite bottleneck of the network?
Again, if someone's got some good figures showing that sending 1000 requests
from, say, NY to LA is less of a bottleneck than sending 2 messages I'd love
to see them.
My
opinion is that this breaks down completely for orchestrated
transactions. Even for a transaction set where all of the root
participants are atomic, individual sub-participant failures may be
recoverable if the coordinator knows the context/semantic/business function
in which the sub-participant is called. For sub-participants this is
not knowable at the root coordinator. Even if the root coordinator
knows the kind of thing that is to be called e.g., parcel delivery service,
it will not know the business policies at the sub-participant site that
define what thing to call in different situations. This information
could (and should IMO of application design) reside in the
sub-coordinator.
Agreed. I'd like to see that sub-participants have to
register with sub-coordinators. As you say, there's the separation of
concerns issue, and definitely the performance/trust
issue.
Mark.
----------------------------------------------
Dr.
Mark Little ()
Transactions Architect,
HP Arjuna Labs
Phone +44 191 2064538
Fax +44 191
2064203
