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
