RE: [ws-caf] Checked transactions

["Green, Alastair J." <Alastair.Green@choreology.com>]

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