Re: interposition

[Alastair Green <alastair.green@choreology.com>]

Mark,

One meta-comment. I feel that this whole business of hinting or insisting on interposition may be just plain excessive. In other words, I could easily be persuaded that we should just steer clear of this kind of adornment on the context.

I'm going to excise all the parts of your summary that I broadly agree with, with one prefatory exception. I think we are talking about presumed abort, as you presume. My comments in bold.

* * *

The work that AP must do when it receives the termination message from C0 now depends upon which category it falls into. If it is 2, then it must prepare its own local work before forwarding the prepare to all locally registered participants (e.g., B).

It must record sufficient recovery information for its own work as a participant *and* additional recovery information for its role as a coordinator. If it is case 3 then it need only do the latter.

To be pedantic, it cannot return a vote in response to the prepare delivered to it until a) it has received all of its participants' votes, and b) is sure of its own local work, and then it must record its participants' addresses, and its coordinator address, before sending its vote to the superior coordinator.  The point is that the branches below it in the tree must be ready before it can go ready, not the other way around.

As I understand it, because your scenario 3) does not _necessitate_ any kind of participant registration, all mentions of logging for case 3) to refer to the situation where an interposed coordinator has by design been created, even though there are no local participants. A router might simply route (i.e. have no participant or coordinator function at all).
 What are the requirements for not doing interposition? (i) coordinator global knowledge: a coordinator (or more likely the business logic which created it) may want to know the identities of all participants (e.g., for audit trail purposes).(ii) ?? Perhaps the only system trusted (or equipped in terms of system admin or monitoring capability) to carry out coordination is a hub or central counterparty of some kind. Perhaps the coordination software from HP is very expensive, while being a participant is very cheap (or even free).

They may be a performance argument for avoiding interposition, based on reduction in number of messages or sloth of fan-out etc. I'm personally unconvinced, but production deployments do funny things, and others may have experience that contradicts my prejudice.

It is my belief that using interposition should be up to an individual web service.

I think this is overstating the case. If the individual web services congregate in a community (or are forced into one by ownership or economic force majeure) then they may agree (or "agree") to rules of engagement that cause the coordinator to become a "desired overlord", responsible for "ensuring" that the rules are observed.
 Therefore, having another external entity force (by default) interposition to be disabled is not the right choice. In addition, it can never be enforced or fully policed: since a sub-coordinator is a participant as far as it's coordinator is concerned, a sub-coordinator could lie and say it had disabled itself when in fact it had not. To prove otherwise would require going outside the protocol (e.g., an administrator examining logs after the fact) and may still be impossible if sufficient audit trails are not kept.

This gets to the nub of the teleconference discussion. It might be the right choice, if the community/owner wish it. It can never be enforced or fully policed (short of someone certifying all code everywhere) -- absolutely true. But forget fraud and impersonation. We're quite happy to have contracts which are strictly unenforceable. The 2PC protocol is one such. It contains rules such as "a participant will send a vote in response to a prepare". Nobody can force a participant to keep its side of the bargain. Worse, the coordinator might agree to "return a vote which is confirm if all voters say yes, and a cancel otherwise", and then fail to deliver accurate results. The participant has no idea whether it's being misled. All messages are accurately sent in the right order, and have plausible contents.

The point is that protocols are agreements, and agreements only work when there is enough trust (and punishment for violators) to keep things going. We suspend unwitting or corrigble offenders, and we expel incorrigible offenders from our trust communities by simple dint of refusing to deal with them, or by complex dint of hauling them up before disciplinary panels. This kind of background radiation trust is good enough for many purposes, including this discussion, in my view.
 Likewise, a MustInterpose option would not work because an ordinary participant simply cannot supply the required functionality.

In which case the service should fault on reception, because it can't provide the facility requested.
 Rather than introduce many flags (c.f. EJB) that have no proven requirements at this stage, and which may therefore restrict us in future, let's try to keep things simple initially. Unless there are well proven use cases for doing something in a given way (e.g., MustNotInterpose) and someone cares to outline them, I'd like to see us consider only the "hint" option at this stage. If later users come back and say that they require this, this and this, then we can add them to a future version of BTP. At the end of the day it's the business and security cases that will impose requirements on us from above.

I'd like to reiterate what I said in the call. It's not a matter of forcing or enforcing, it's a matter of helping and facilitating. If the trust community wants a single coordinator, then a "MustNotInterpose" flag from above provides a very simple mechanism for enforcing that (mutually desired) rule (helps work round service implementation bugs). If there is a clash between the benevolent dictator and the willing but errant subject then the problem is brought to light quickly. The difference between "hint" and "insist" is don't get an exception/get an exception, which doesn't seem like a big deal to me in terms of implementation cost.

Is it worth putting in the protocol? I'd go with the flow on how useful it's likely to be, because it is a requirement-driven issue.

A final point on the matter raised by Keith in the call. If you send a single app message to a service, saying "MustInterpose" then you will only ever get back one enrollment (if it's well-behaved, and capable). If you send two messages, each of which causes enrollment, then you will not have a single point of coordination for the service. That is why I believe you cannot imbue MustInterpose with the necessary implication of "SingleParticipant".

Alastair
 

begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard