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.
Yes, my description was in no way meant to be a complete failure
scenario - there are several things left out that are required for an
implementation. It's only an overview. However, if you would like such a
scenario then I can certainly go into the necessary details.
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).
Yes, a router take *no* part whatsoever in the protocol, whereas a
"pure" sub-coordinator has no local work it also does.
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).
The issue of security does certainly cut both ways. However, as
we've said before we are not in the position (because of time) to address this
adequately, in my opinion. In the above, for example, if I as an implementer
decide that I don't want to expose my internal web services to *anyone* then why
should I accept some override from "above"? The answer certainly isn't
clear-cut, because if "above" is my manager (for example) then perhaps I should.
However, if I'm being invoked from elsewhere then perhaps I shouldn't. Currently
a web service doesn't have sufficient information to make that distinction, and
rather than see us rush headlong into overloading (say) the context with lots of
superflous information, I'd rather we started with something simple, and build
it up over time.
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.
My experience in building transaction systems, and
also independently group (replication) communication infrastructures
indicates that if you only have a couple of participants then doing something
like an interposition fan-out is not going to give you much (though it
probably won't adversely affect performance). However, once you get past that
threshold, it does help a lot.
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.
I can see that there may be occasions where an implementer has
included interposition as an option that may not be used in certain
environments. However, I still contend that this is not going to be the majority
use situation. See above as well.
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.
While this is true up to a point, not abiding by the two-phase
commit protocol rules is much more likely to be shown up later, e.g., by data
corruption. Doing interposition when you are asked not to is less likely to
cause problems that will be seen. I agree that doing (or not doing)
interposition is another agreement, but just as agreeing to do 2PC is typically
done at bind-time (the client looks for BTP-aware services), I'd rather see this
route taken if we have to address this at all. If I, as a business-logic
implementer, want to force interposition (or vice versa) I would like to do this
at composition time by agreeing a priori with the various participants. However,
see below.
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.
When constructing the web services for a given application "run" I
expect to have to go through some level of negotiation (e.g., find the right
UDDI service) to select the right services. It's at this point that I want to
know whether its worth going on, not 10 minutes down the line when I've
basically gone and wasted that effort. However, if we are not going to say that
the transaction must abort in this situation (and I haven't heard anyone say
that), then there's nothing preventing the invoker sending the message again
without MustInterpose, assuming it can a) change the flag, and b) it makes sense
to do so in this context.
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.
I'm more interested in the model-view of this at the moment. If
there is a real requirement for it then it should be in, regardless of the cost.
If there's not, then why start with it.
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.
Agreed.
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".
If you send two messages with the same context to the same service
then why would you expect to get two enlistments? There's been an implicit
assumption on my part that a service will only register a single participant for
each transaction. Are you saying this is not the case?
Mark.
---------------------------------------------- Dr. Mark Little
( mark@arjuna.com) Transactions
Architect, HP Arjuna Labs Phone +44 191 2064538 Fax +44 191
2064203
|