Re: interposition requirements

[Mark Little <mcl@arjuna.com>]

 

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