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: Fwd: RE: [ws-caf] Statement for WS-Transactions workshop


Hi Eric,

I guess I was assuming that in any merger there is an acquirer and a
target. 
What would be left from WS-CAF? WS-CTX and WS-TXM BP, at most. That was
the basic message I got. 

No issues were raised with respect to specific WS-AT/Acid or WS-BA/LRA
differences, or points made about the distinctive contributions or
features of those two specs that would add to or alter the shape of
WS-AT and WS-BA, other than the need for heuristic reporting in WS-AT
(which I certainly agree with).

I'm actually very interested in canvassing opinion in the CAF group
about the key points I highlighted in my additional notes on the
Feedback workshop, with respect to WS-BA (see my earlier message in this
thread). 

Are these seen as important, correct, incorrect and/or inconsequential? 

Obviously it's the start of a process with WS-C+T, so we'll have to see
what happens. The biggest question in my mind is: how open to
well-founded, informed argument will the author companies be? I think
that a successful standard in this area needs the backing of the WS-C+T
author companies, and it would be good to see what is valuable and
distinct in the prior work in BTP, and the current work in CAF,
reflected.

My final point would be that the field of business transaction
management, application coordination, call it what you will, is
emerging. In this field the existence of multiple protocols is going to
confuse and hamper, rather than foster, market development. We think
WS-BA, appropriately modified in a rather incremental way, and kept
relatively narrow, can provide the platform for a wide spread of
applications and models, going well beyond the (important but limited)
role of support for BPEL compensations.

Alastair

-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
Sent: 17 March 2004 16:16
To: Green, Alastair J.; Pete Wenzel
Cc: ws-caf@lists.oasis-open.org
Subject: RE: Fwd: RE: [ws-caf] Statement for WS-Transactions workshop

Alistair,

I'd like to be clear on these points.  What I said was the question of
authorship should be considered in any discussion about merging the
specs.  

I did not suggest that any specs be dropped.  The suggestion was to look
at merging the similar specs and add new specs where similarities don't
currently exist (i.e. in WS-Context and the BP transaction model).

Thanks,

Eric

-----Original Message-----
From: Green, Alastair J. [mailto:Alastair.Green@choreology.com]
Sent: Wednesday, March 17, 2004 10:25 AM
To: Newcomer, Eric; Pete Wenzel
Cc: ws-caf@lists.oasis-open.org
Subject: RE: Fwd: RE: [ws-caf] Statement for WS-Transactions workshop


Eric suggested that the primary authors of the WS-CAF specs would like
to become authors of WS-C+T in the process of bringing WS-TXM BP into
the fold. The indication was that WS-TXM Acid and LRA are duplicative of
AT and BA, and would be dropped. WS-Context was suggested as an aspect
to be retained, by contrast.

In his statement he suggested that pretty much all of the original
author companies of CAF were supportive of this approach.

We in Choreology made the statement that we considered BTP to be dead,
i.e. not a contender as leading specification for Web Services
transactions. (We have held this view since it became clear that IBM and
Microsoft introduced their own specs in this space, but now seems like a
sensible time to emphasize the point. We believe BTP is like a
transition relationship: it's necessary in the absence of more durable
or authorative solutions; it's good while it lasts, it fills the gap
while the other solution gets sorted, and it's not going to last. We
would like to see WS-BA emerge as the vanguard spec, drawing on other
and prior work, e.g. BTP and CAF.)

We raised a whole series of issues relating to details of WS-AT, and
more substantive methodological ones relating to WS-BA. There was not
time to discuss or even raise all of our points and we were invited to
submit a detailed, prescriptive account in writing for further
consideration, which we will do. The key items are: need to align
business promises (e.g. reservations) with protocol promises (PREPARED);
equality of treatment for the positive and negative final signals
(CONFIRM/CANCEL in BTP-speak, CLOSE/COMPENSATE in WS-BA speak); need to
allow selective confirmation of prepared participants (do not introduce
a rule that ensures a uniform outcome across the whole pool). We also
believe that an interoperable control protocol (terminator-coordinator)
protocol is very important (although not strictly critical) for a
selective confirmation protocol.

We are also interested in the checkpointing and notification aspects in
WS-TXM BP.

Alastair
 

-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
Sent: 17 March 2004 13:50
To: Pete Wenzel
Cc: ws-caf@lists.oasis-open.org
Subject: RE: Fwd: RE: [ws-caf] Statement for WS-Transactions workshop

Pete,

My apologies to you and everyone else on the list.  I should have
thought to send an email right after the meeting.

There was no formal reaction to our statement.  The workshop was set up
as a feedback workshop, and the WS-CAF statement was taken in that
context.  We (Mark Little and I) also proposed a "straw horse" proposal
for merging WS-CAF with WS-AT, WS-BA, and WS-C.  I understand it's being
evaluated.

Overall the meeting consisted primarily of presentations on the
BEA/IBM/MSFT specifications with some discussion about them that
resulted in about a dozen issues being raised.  

I think it was a good opportunity to let everyone know what's going on
in WS-CAF, make the point about common ancestry and technical
similarities, and highlight where WS-CAF provides extensions to the
BEA/IBM/MSFT specs, especially around generic context management and the
business process transaction model.

We will have to wait for a more formal reaction.

Eric

-----Original Message-----
From: Pete Wenzel [mailto:pete@seebeyond.com]
Sent: Tuesday, March 16, 2004 2:10 PM
To: Newcomer, Eric
Cc: ws-caf@lists.oasis-open.org
Subject: Re: Fwd: RE: [ws-caf] Statement for WS-Transactions workshop


Eric, are you able to report anything about the workshop, or was it
held under nondisclosure?  Any response to your proposal?  Thanks.

--Pete
Pete Wenzel <pete@seebeyond.com>
Senior Architect, SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)

Thus spoke James Bryce Clark (jamie.clark@oasis-open.org) on Mon, Mar
08, 2004 at 10:36:30PM -0800:
> >> --- Below this line is a copy of the message.
> >>
> >> Date: Mon, 8 Mar 2004 19:24:08 -0800 (PST)
> >> From: Eric Newcomer
> >> Subject: RE: [ws-caf] Statement for WS-Transactions
> >> workshop
> >> To: ws-caf@lists.oasis-open.org
> >>
> >> Apologies - I typed this in much earlier today, but
> >> our email system has been out since noon, and is
> >> apparently still down.  So I'm posting from my
> >> private account.  Eric
> >> ------
> >>
> >> Hi,
> >>
> >> Per today's concall, here is the edited version of the
> >> statement I plan to give on behalf of the WS-CAF TC at
> >> the Microsoft/IBM/BEA WS-Transactions feedback
> >> workshop Wednesday March 10.  Please let me know if
> >> there are any further comments or suggestions.
> >>
> >> The WS-CAF TC would like to recognize the common
> >> ancestry and technical similarities across the WS-T,
> >> WS-C, WS-BA and WS-CAF sets of specifications.  During
> >> our work we've discovered the benefits of separating
> >> out context management as a generic mechanism, and
> >> have developed a key additional protocol called the
> >> Business Process transaction model.  We think the
> >> WS-T, WS-C, and WS-BA specifications would benefit
> >> from including these major concepts.
> >>
> >> We propose a discussion on finding the best way to
> >> move forward and bring our work together.
> >>
> >> Thanks -
> >>
> >> Eric


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