[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf] Splitting and lumping protocols (was RE: [ws-caf] WS-ACID)
Furniss, Peter wrote: >I agree that, in so far as there is a perceived need for a ws and xml >version of the extant >acid/atomic protocols, WS-ACID or WS-AT do have an ecological (or >marketecture) niche. So >pulling WS-ACID out from the soup of the possible is reasonable. Whether >its technically >necessary to split it is another question, but one that is clearly going >to be ignored >(One might consider that no customer ever bought a protocol - they buy >the implementation >and the bit they are interested in is the api plus the knowledge that it >sends/receives >the protocol understood by some other implementation) > > Peter, we're never going to agree on this particular aspect, so I still think the compromise (BTP-binding) is the only way forward. It gives you exactly what you want and if the community adopts that binding when using WS-CAF to the detriment of the other protocols, then sobeit. That would be a clear indicator. I have my doubts, but I'm willing to wait and see. >What is far less clear, and from your message is still an open issue, is >what comes out >of the soup next. Although there are other interaction patterns that >would deserve a >different protocol (in a narrow sense), I don't think the range of >function raised in >ws-caf so far needs more than one. But, for now, the important point is >that we >agree that this question has NOT yet been answered in the TC - and, for >example, we >won't just split out WS-LRA in a few months because it was there, >without looking >at the problem domains in sight and working out what if the partitioning >is sound. > > I don't think that was implied in anything I said. I also think what you are asking for is consistent with what Martin said yesterday: "So lets debate/design each one based on the goals each is trying to achieve." The goals of WS-ACID are well understood: interoperability with existing TP systems in (typically) closely coupled environments. >However: >We really would be doing ourselves, and the community, a service if we >did this with >ws-acid too. > We've done that. The result (withing WS-CAF) is WS-ACID. The same route taken by IBM et al resulted in WS-AT. Seems like a fairly consistent story and one that is right for the community. > There is a fundamental difference between splitting and >lumping protocols >and splitting and lumping implementation functionality. Your useful >comment in one of the >other messages is: > ><mark> >As I've said on several occasions though: we've had experience of >selling (to customers, partners and analysts) a BTP product and a >product based on the "micro-protocol" approach. It was nearly impossible > >for the former, even with (or is that despite?) the HP publicity machine > >in full swing. The latter is a different matter: people just "get it": >you get the separation of concerns, the core competency, the dedicated >solution without impact on others, the leveraging of existing >infrastructural investments (IMO this is critical to the uptake of any >solution in this area, and is why we should concentrate on WS-ACID >firstly), ... ></mark> > >the thing is the latter part of that message is irrelevant to the >question of >splitting and lumping protocols. > We'll have to agree to disagree on this :-) > A protocol, with possible markers or >qualifiers, that >can choose things (as, on a small scale, the alternative registrations >of WS-ACID or WS-AT >for synch/normal or volatile/durable) is more flexible than one that >forces choice >a priori - why aren't there separate contexts for synch and normal ? >Because it would >be uneccessary and complicate things. > "unnecessary and complicate things"? Hmmm, let's see: a protocol that works precisely for its intended problem domain (say A) and does not have to worry about someone elses problem domain (say B), precisely because changes to the protocol because of A don't have any impact on B, is somehow more complex than one that tried to be everything to everyone? I don't buy it. Analysts don't buy it. Customers don't buy it. Experience doesn't back it up either. I am proud to say that I was actively involved with BTP from the start (http://lists.oasis-open.org/archives/business-transaction/200103/pdf00001.pdf), but I'm also realistic enough to admit that we got it wrong within the TC. That experience, coupled with building and selling the world's first BTP implementation when with HP, have shaped things in my mind. >Does (to take another example) a >WS-BA registration >need to declare whether it will demand a Prepare or can volunteer ? I >don't see why - if >the coordinator has received a Prepared, it needn't prompt, and if they >cross the >participant can ignore the surprise Prepare. There is no "need to know". >Widening, and heading >for the contentious area, how will the behaviour of the >service/participant be affected by the >knowledge that other participants are using locking ? Locking against >what - their concept of transaction (in general) may be quite different >from this systems. Does it even matter that >all of them will get the same outcome ? (yes, but only in some cases). >The behaviour of the >service is much more likely to be affected by expected duration of the >transaction, likelihood >of it being asked to rollback etc. But those would obviously be >qualifiers of a protocol - I >doubt anyone would suggest completely different sets of messages for >those cases. > > This is opening up the discussion I don't think either of us can convince the other of. >Using a single protocol as the intercommunicating underlay for a RANGE >of implementations, which >are indeed oriented on different purposes allows those implementations >to interact directly when >their purposes touch. The alternative is to divide the domain up more or >less arbitrarily. > > It's not arbitrary. It is based on experiences, which include customer deployments. > > >Peter > >ps - btw, the approved minutes for the New Orleans meeting say, on >transactions: ><quote> >Transactions > >Mark gives presentation on transactions. > >Mark motions that TXM be split into separate, independent >specifications. Greg Pavlik seconds. Martin asks if TXM disappears. > >Greg Pavlik motions we move forward with ACID model and leave the other >two alone. Mark seconds. AI to editors to adopt the broken out ACID >model to use the Context/CF updates. ></quote> > >There is no mention of anything like "It was also > > >>agreed (again by vote) that the concept of transaction >>"micro-protocols", or more specifically protocols that would be >>targetted at specific use cases and not the "one size fits all" >>approach, would be taken." >> >> > >there is no mention of any discussion of this long-contentious point, >let alone a vote. > > As I said in a reply to Alastair, the minutes don't reflect in detail what happened IMO. If others agree with my recollection, then we should update the minutes. It would have been nice if Choreology had attended the New Orleans f2f (even if by teleconference), so that you could have argued at that point. For whatever reason, you didn't. But the meeting was quorate and as far as I can tell, correct process was followed. I'm not happy to have this discussion derail our progress towards finalising WS-ACID. Ideally I'd like to have the majority of WS-ACID finished by the end of the next f2f. I think that is possible and it would be a good contribution for this TC to make to the community as a whole. Mark. > > > > >>-----Original Message----- >>From: Mark Little [mailto:mark.little@arjuna.com] >>Sent: 27 May 2005 09:49 >>To: Furniss, Peter >>Cc: Newcomer, Eric; Martin Chapman; Green, Alastair J.; ws-caf >>Subject: Re: [ws-caf] WS-ACID >> >> >> >> >>Furniss, Peter wrote: >> >> >> >>>The documentation relationship of the things is not at >>> >>> >>issue. Separate >> >> >>>documents for separate protocols is generally the current >>> >>> >>direction of >> >> >>>things (and historically, different standards groups have gone >>>different ways in splitting and lumping). >>> >>>The point is, why these three ? >>> >>> >>> >>We're not saying there are three. What we are saying is that >>there will >>(probably) be at least two: one for interoperability with existing TP >>systems, and one for long duration interactions. What we >>agreed in New >>Orleans was that the first of these we would address would be WS-ACID. >> >> >> >>>Are each useful separations AS PROTOCOLS >>>from >>>each other, addressing different requirements that cannot be >>> >>> >>met by use >> >> >>>of each other or by some other arrangement of functionality. >>> >>> >>Given the >> >> >>>range of function of the set, is there a need for more than >>> >>> >>one protocol >> >> >>>? >>> >>> >>> >>> >>Yes. Without opening up the discussion again (I keep coming >>back to this >>point: we were quorate at New Orleans and voted to take this >>approach), >>it appears that the majority of the industry (including those players >>not within this TC) agree from experience and customer input, >>that the >>approach of protocols-per-problem-domain is the right one. We've seen >>the almost complete failure of adoption of any other approach >>time and >>time again, for many reasons (technical included). >> >>But, we're not ruling out a binding to BTP for those vendors who >>strongly believe that it is the right approach. I fail to see >>how this >>is a bad compromise, since it gives all parties what they want. Since >>we'll probably be defining a conformance statement for >>CAF/TXM that says >>(and I paraphrase): "you don't have to support all protocols to be >>conformant", it also means that a vendor who is only >>interested in, say, >>the BTP binding, can support that to total exclusion of the >>other protocols. >> >>Mark. >> >> >> >>>(not entirely exact comparison: there is one IP, and for a long time >>>there were only two general-purpose transport protocols on it. All >>>sorts of higher uses could have invented their own >>> >>> >>equivalents to UDP >> >> >>>and TCP, but didn't. Eventually the range of applications expanded >>>beyond that (e.g. VOIP). Is the range of function covered by >>> >>> >>the input >> >> >>>TXM set analogous to transport requirements of Telnet to >>> >>> >>SMTP, or does >> >> >>>it range wider (c.f. DNS and VOIP)) >>> >>>Peter >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] >>>>Sent: 26 May 2005 13:55 >>>>To: Martin Chapman; Green, Alastair J.; Mark Little; ws-caf >>>>Subject: RE: [ws-caf] WS-ACID >>>> >>>> >>>>I don't consider whether the models/protocols are in one spec >>>>or three to be a technical issue. I think we are happy to >>>>debate the merits of the various models at the upcoming face >>>>to face. My understanding is the decision was made during >>>>the previous F2F to separate the content, not change it. >>>>Whether or not it makes the discussion easier or more >>>>difficult is certainly a matter of opinion but I would say >>>>the more substantive issues relate to the content rather than >>>>the form of the specs. >>>> >>>>I believe we also said during this week's call that we'd >>>>start the discussion on WS-TXM etc. during the next concall. >>>>Email debate on them is of course fine in advance. >>>> >>>>But I don't think that was meant to reopen the decision about >>>>splitting up the spec(s). My understanding was the >>>>discussion would start from where we are following the >>>>results of previous F2F. >>>> >>>>Eric >>>> >>>>-----Original Message----- >>>>From: Martin Chapman [mailto:martin.chapman@oracle.com] >>>>Sent: Thursday, May 26, 2005 8:34 AM >>>>To: 'Green, Alastair J.'; 'Mark Little'; 'ws-caf' >>>>Subject: RE: [ws-caf] WS-ACID >>>> >>>>Alastair, >>>> >>>>TXM is just a collection of different TX models. There is no >>>>real design philosophy that binds them aside from >>>>being built on context and CF. Hence the decision to separate >>>>and let them have independent existence. So lets >>>>debate/design each one based on the goals each is trying to >>>> >>>> >>achieve. >> >> >>>>Cheers, >>>> Martin. >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Green, Alastair J. [mailto:Alastair.Green@choreology.com] >>>>>Sent: Thursday, May 26, 2005 10:34 AM >>>>>To: Mark Little; ws-caf >>>>>Subject: RE: [ws-caf] WS-ACID >>>>> >>>>> >>>>>Hi Mark, >>>>> >>>>>I think that we should take a step back. Why are there >>>>> >>>>> >>three specs in >> >> >>>>>the WS-TXM family? Are they actually needed, or the right >>>>> >>>>> >>ones? What >> >> >>>>>are we trying to achieve/what are the underlying >>>>> >>>>> >>requirements? This >> >> >>>>>is very major phase of work, and not one to be rushed at. >>>>> >>>>>The history of this TC is that a review of fundamental >>>>>principles/model/architecture has usefully led to simplification >>>>>towards the genuinely general, both with Context and WS-CF. >>>>> >>>>>I would like to propose a full discussion of the model and >>>>> >>>>> >>principles >> >> >>>>>behind the current WS-TXM input documents and their separation of >>>>>powers at the face to face. I think I am right in saying that you >>>>>have raised, for example, the question as whether WS-TXM >>>>> >>>>> >>BP is useful >> >> >>>>>as an independent spec. >>>>> >>>>>In my view the WS-TXM specs as they stand are a very >>>>> >>>>> >>complicated way >> >> >>>>>of achieving a set of fairly-well understood goals. They >>>>> >>>>> >>also raise a >> >> >>>>>couple of interesting new ideas (or at least not so generally >>>>>accepted ideas). >>>>> >>>>>If WS-TXM is to be a useful competitor to WS-BA/AT then it >>>>> >>>>> >>should be >> >> >>>>>helpfully different (better, simpler, more functional etc). >>>>> >>>>>If WS-TXM is heading for the fate of WS-Reliability, then >>>>> >>>>> >>it might be >> >> >>>>>more apposite to seek emulation, rather than competition >>>>> >>>>> >>-- i.e. get >> >> >>>>>the capitulation over with quickly, and provide some helpful >>>>>additional features that the WS-TX TC will be able to take >>>>> >>>>> >>note of as >> >> >>>>>it spits and polishes the >>>>> >>>>> >>>>> >>>>> >>>>BA/AT specs. >>>> >>>> >>>> >>>> >>>>>Per se, I have no objection to a legacy-adaption spec >>>>> >>>>> >>which enables >> >> >>>>>OTS vendors to respray the wire in XML colours, but I think we are >>>>>jumping ahead too fast. >>>>> >>>>>Parenthetically, it seems that the difference between ACID >>>>> >>>>> >>and AT is >> >> >>>>>the difference between OTS and OLE-Tx. >>>>> >>>>>Heuristics are quite traditional, and I suspect the lack of >>>>>heuristics wouldn't survive an open standardization of >>>>> >>>>> >>>>> >>>>> >>>>WS-AT, if/when. >>>> >>>> >>>> >>>> >>>>>Alastair >>>>> >>>>>Alastair J. Green >>>>>CEO and CTO >>>>>Choreology Ltd >>>>>68 Lombard Street >>>>>London EC3V 9LJ >>>>>www.choreology.com >>>>> >>>>>+44 870 739 0050 >>>>>+44 870 739 0051 (fax) >>>>>+44 795 841 2107 (mobile) >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Mark Little [mailto:mark.little@arjuna.com] >>>>>Sent: 25 May 2005 20:29 >>>>>To: ws-caf >>>>>Subject: [ws-caf] WS-ACID >>>>> >>>>>Ignoring the differences in WS-Context and WS-CAF that may impact >>>>>WS-ACID, does anyone have any issues with the protocol or >>>>> >>>>> >>>>> >>>>> >>>>model as it >>>> >>>> >>>> >>>> >>>>>currently stands? >>>>> >>>>>I can summarise the differences between it and traditional ACID >>>>>transactions if needed. If you're looking for major differences >>>>>between WS-ACID and WS-AtomicTransaction then they >>>>> >>>>> >>probably come down >> >> >>>>>to: WS-ACID uses a synchronization protocol, whereas WS-AT uses >>>>>volatile 2PC >>>>> >>>>>for "volatile" pre/post commit processing, and WS-AT >>>>> >>>>> >>doesn't support >> >> >>>>>heuristic outcomes (there's an "protocol violation" error message >>>>>which isn't quite useful enough). >>>>> >>>>>Mark. >>>>> >>>>>-- >>>>>Mark Little >>>>>Chief Architect >>>>>Arjuna Technologies Ltd >>>>>(www.arjuna.com) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>-- >>Mark Little >>Chief Architect >>Arjuna Technologies Ltd >>(www.arjuna.com) >> >> >> >> -- Mark Little Chief Architect Arjuna Technologies Ltd (www.arjuna.com)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]