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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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


Subject: Re: [ws-caf] WS-ACID


+1

That's my recollection of statements made within the TC in the past as 
well. We could argue ourselves to a standstill (process not 
withstanding) about this - that discussion has been going on for at 
least 3 years, so I don't have any expectations of it being concluded 
any time soon (again, process not withstanding).

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), ...

I see nothing wrong with WS-CAF supporting WS-ACID, WS-LRA, WS-BP and a 
binding to BTP. WS-TXM as it was, was always intended to be a "live 
document". pushed primarily by user requirements. If someone wants to 
provide a mapping to the old XAML protocol that predates BTP, then that 
would be acceptable too.

Mark.


Newcomer, Eric wrote:

> I think absolutely it’s consistent with our intention, and hopefully 
> explicit statements somewhere along the line, that we’d be interested 
> in considering a mapping of BTP to WS-CF.
>
> Eric
>
> ------------------------------------------------------------------------
>
> *From:* Green, Alastair J. [mailto:Alastair.Green@choreology.com]
> *Sent:* Thursday, May 26, 2005 1:38 PM
> *To:* Newcomer, Eric; Martin Chapman; Mark Little; ws-caf
> *Subject:* RE: [ws-caf] WS-ACID
>
> I'm sorry but this feels like form and procedure are impeding content.
>
> What exactly did the TC F2F decide about this matter? When I read the 
> minutes it was not clear: did Greg’s motion mean that LRA and BP are 
> dead? Was it passed?
>
> If I see what has happened since and the responses from Eric and 
> Martin it looks as if some members believe that all three will be 
> discussed. But separately, one after the other? Are the requirements 
> that drove LRA and BP’s inclusion now deemed to be dead and buried, or 
> wrong?
>
> * * *
>
> I am uninterested in one document or three (other than ease of use) -- 
> if it makes sense to have three protocols.
>
> Should there be three? Why should there be three? What are the 
> requirements and purposes of these three? Can they be achieved by one 
> protocol, or two, or three? I think these basic questions deserve a 
> bit more consideration, including e-mail discussion that can be 
> assimilated properly.
>
> The history of this TC, to repeat, is that a genuine step back and 
> review of principles has simplified and reduced the output relative to 
> the input.
>
> Technically, there is no reason why the goals of all three of these 
> specs cannot be met by one spec whose overlap of content with respect 
> to the goals of each will be about 95%. But perhaps the TC now longer 
> wishes to accommodate any goals other than XMLization of flat-model 
> OTS, in the transaction arena?
>
>
> * * *
>
>
> Let me raise another question, while we are on this subject, measuring 
> against the TC's charter --
>
> The WS-CAF TC will accept as input the WS-Context, WS-Coordination 
> Framework and WS-Transaction Management specifications [1] published 
> by Arjuna, Fujitsu, Iona, Oracle, and Sun Microsystems on July 28 
> 2003. Other contributions in addition to WS-CAF will be accepted for 
> consideration without any prejudice or restrictions and evaluated on 
> their technical merit, as long as the contributions conform to the 
> goals and scope of this charter.
>
> The benefits and results of this work will be standard and 
> interoperable ways to:
>
> Demarcate and coordinate web service activities
>
> Propagate and coordinate context information
>
> Notify participants of changes in an activity
>
> Define the relationship of coordinators to each other
>
> Recover transactions predictably and consistently in a business 
> process execution.
>
> Interact across multiple transaction models (such as are used in 
> CORBA, CICS, Enterprise JavaBeans? or .NET environments).
>
> OASIS BTP is capable, with some slight modifications, of being bound 
> to WS-CAF Context and CF. It would allow you to handle any of the 
> goals specified in the charter -- you can run distributed ACID over it 
> (we do); you can use it to handle nested scope compensations and other 
> models of BPM transactions (we have designed this in great detail and 
> it is on our product roadmap), and you can bridge similar protocols 
> (e.g. WS-AT and WS-BA, or WS-Acid and WS-LRA) using it (we do in the 
> case of the two former).
>
> So why are we fixing on the original three inputs in this rigid way? 
> Or only one of them?
>
> I believe that as we now come to the discussion about transactions, we 
> need to precisely evaluate the technical merits of all available 
> inputs. We also need very clear and well-argued (and properly 
> considered) motivations if we are going to make decisions to drop 
> elements laid out in the charter.
>
>
> 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)
>
> -----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)



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