33 messages in org.oasis-open.lists.ws-cafRE: [ws-caf] Checked transactions| From | Sent On | Attachments |
|---|---|---|
| Green, Alastair J. | Jul 11, 2005 11:46 am | |
| Mark Little | Jul 12, 2005 3:55 am | |
| Greg Pavlik | Jul 12, 2005 8:28 am | |
| Mark Little | Jul 12, 2005 8:35 am | |
| Green, Alastair J. | Jul 12, 2005 9:26 am | |
| Greg Pavlik | Jul 12, 2005 12:42 pm | |
| Mark Little | Jul 12, 2005 1:21 pm | |
| Greg Pavlik | Jul 15, 2005 10:37 am | |
| Green, Alastair J. | Jul 18, 2005 3:15 am | |
| Greg Pavlik | Jul 18, 2005 5:45 am | |
| Mark Little | Jul 18, 2005 6:36 am | |
| Mark Little | Jul 18, 2005 6:56 am | |
| Mark Little | Jul 18, 2005 7:47 am | |
| Greg Pavlik | Jul 19, 2005 10:43 am | |
| Green, Alastair J. | Jul 19, 2005 1:29 pm | |
| Mark Little | Jul 20, 2005 1:09 am | |
| Mark Little | Jul 20, 2005 1:10 am | |
| Mark Little | Jul 20, 2005 2:02 am | |
| Greg Pavlik | Jul 20, 2005 8:29 am | |
| Green, Alastair J. | Jul 20, 2005 9:23 am | |
| Greg Pavlik | Jul 20, 2005 12:21 pm | |
| Green, Alastair J. | Jul 20, 2005 1:00 pm | |
| Green, Alastair J. | Jul 20, 2005 1:00 pm | |
| Mark Little | Jul 21, 2005 12:50 am | |
| Mark Little | Jul 21, 2005 1:05 am | |
| Mark Little | Jul 21, 2005 1:14 am | |
| Greg Pavlik | Jul 21, 2005 6:23 am | |
| Greg Pavlik | Jul 25, 2005 7:44 am | |
| Green, Alastair J. | Jul 25, 2005 8:03 am | |
| Mark Little | Jul 26, 2005 6:14 am | |
| Green, Alastair J. | Jul 26, 2005 7:18 am | |
| Mark Little | Jul 27, 2005 7:40 am | |
| Newcomer, Eric | Aug 1, 2005 7:25 am |
| Subject: | RE: [ws-caf] Checked transactions | |
|---|---|---|
| From: | Green, Alastair J. (Alas...@choreology.com) | |
| Date: | Jul 26, 2005 7:18:21 am | |
| List: | org.oasis-open.lists.ws-caf | |
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...@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