[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]