OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: interposition


 

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
 
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC