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] Checked transactions


My apologies, I sent the email on this prematurely.  I think Mark's view
on a kind of compromise sounds correct.  Specify a lightweight but
optional checking mechanism....

-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com] 
Sent: Tuesday, July 26, 2005 9:14 AM
To: Greg Pavlik
Cc: Green, Alastair J.; ws-caf
Subject: Re: [ws-caf] Checked transactions



Greg Pavlik wrote:

> We've had some vigorous discussions in this area. In order to advance 
> things, we need to make a decision on how to proceed.
>
> 1) We could determine what MEPs we care to provide either guidance or 
> normative rules for checking around. We might as well defer to WSDL 
> and WS-Addressing to help us nail down the MEPs. As it stands, 
> request-response, synchronous (in-out) and asynchronous (correlated in

> messages) have been discussed as important. Are there other MEPs we 
> want to consider?
>
> 2) The flip side the question: do we want to divorce ourselves from 
> worrying about MEPs and layer semantics on the enlistment messages and

> optimization?

In every specification and implementation I've come across that defines 
checked transaction semantics, there is either a way of disabling it or 
it is optional. The reason for this is that although you really do need 
to have checked transactions in general, in some situations it is simply

too much of an overhead and checking can often be dealt with at the 
application level. With that in mind, I think we need to provide the 
capabilities for checking, but we shouldn't mandate that they are used. 
In my experience, lightweight/narrowly focussed, easy to use 
capabilities are more likely to be used well and correctly than 
something that is heavy-handed and overly capable.

I don't see any disadvantage to tying checking to MEPs.

>
> 3) Or do we want to leave this to implementors?

I don't think we want to leave it to implementors. We'll end up having 
non-portable, non-interoperable implementations.

Mark.

>
> Greg
>
>

-- 
Mark Little
Chief Architect
Arjuna Technologies Ltd
www.arjuna.com




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