[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] Checked transactions
I agree with Mark: there should be no obligation to send a message meaning "checked", or "I have done all my enrolments". This is a supporting tool for the application, which will always have to make the decision. It is for similar reasons (app flex) that I would like to see sufficient information available to *allow* counting/identity approaches to checking. We have found this approach to be extremely useful in actual customer scenarios. The disadvantage of tying to MEPs is a) that it's liable to lead to overspecification as a result of over-speficity -- more work than is needed, and b) that checking semantics should be communicable over any MEP. 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: 26 July 2005 14:14 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]