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] discussion on approaches for web services/ business transaction


Just to follow-up on Eric's points: WS-CAF shouldn't be seen as a
revolutionary approach, but more an evolutionary approach. The collective
experiences of the original authors span many proprietary interoperability
stacks, standards (such as Additional Structuring Mechanisms for the OTS,
BTP, OTS, X/Open, to name but a few), and experiences of using
implementations of these standards. In many ways we've covered the bases
from specific protocol to generic protocol and back again and the current
WS-CAF specifications reflect these experiences and allows users to support
both generic and specific interaction patterns.

By generic I mean that a single message can contain arbitrary payloads that
are not semantically interrogated by the delivery mechanism or necessarily
by the initial receiver. I can certainly cover this next week, but just in
case people have missed this point: all protocol messages using the WS-CF
interaction pattern are AssertionTypes. What this means is that a service
can elect to receive only AssertionTypes without the lower levels of the
protocol stack determining their specific meaning and impose semantics on
them upon receipt.

This has the benefit of allowing a service to not have to expose the
protocols it supports directly. There are obvious disadvantages that we
(Eric, myself and Greg) have covered elsewhere so I'm not going to go into
them again. The other advantage is that AssertionType doesn't imply
two-phase. Although some people believe that a generic two-phase protocol is
sufficient today, we don't and certainly didn't want to build that
restriction into WS-CAF: retro-fitting when something that doesn't quite fit
comes along doesn't fill me with glee.

Mark.

P.S. WS-T has its Notification for some similar reasons.

----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.

www.arjuna.com

----- Original Message -----
From: "Newcomer, Eric" <Eric.Newcomer@iona.com>
To: "Haugen Robert" <Robert.Haugen@choreology.com>; "WS-CAF"
<ws-caf@lists.oasis-open.org>
Sent: Tuesday, November 25, 2003 9:36 PM
Subject: RE: [ws-caf] discussion on approaches for web services/ business
transaction


> Bob,
>
> Again, I have to apologize for not agreeing that there's an issue, or
perhaps just not understanding that there's an issue.
>
> The sub-protocols represent existing environments and potentially new
environments that need to be bridged for the simple reason that all
environments (current and potential) do not use the same protocol.
>
> The ACID and LRA tranasaction models in WS-TXM are optional, as is the BP
model.  So the ACID and LRA protocols can be sub-protocols to the BP model,
as can legacy protocols, WS-T, or BTP.  The ACID, LRA, and BP protocols are
not required.  They do not replace anything, and are intended as
complementary protocols instead of replacement protocols.
>
> I'm sorry, but I still do not see the issue.  This is how WS-CAF is
designed.
>
> Thanks,
>
> Eric
>
> -----Original Message-----
> From: Haugen Robert [mailto:Robert.Haugen@choreology.com]
> Sent: Tuesday, November 25, 2003 12:38 PM
> To: Newcomer, Eric; WS-CAF
> Subject: RE: [ws-caf] discussion on approaches for web services/
> business transaction
>
>
> Eric Newcomer wrote:
> > the point of WS-CAF is to define a protocol complementary
> > to the lower level protocols, not a replacement for them.
>
> I can understand that assertion re WS-Context and WS-CF (Coordination),
> but the issue Peter and I and others have raised is about WS-TXM.
>
> When I read WS-TXM, I see a suite of new business transaction protocols:
> ACID, LRA and BP, where BP itself decomposes into a suite of
> sub-protocols.
>
> How do I correlate the suite of new protocols in WS-TM with your
> statement above?
>



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