RE: Checked transactions

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

Greg,

1) I see no need (and lots of downsides) to tying checking capability to
a (sub)set of MEPs. I see value in describing how a general scheme
applies to those MEPs, to exemplify usage. A checking scheme should be
capable of handling any style of conversation.

2) I think that the alternate mode of checking (counting/identifying) is
very useful, and the service identity (id and name) issue needs to be
addressed to achieve this.

3) Vectorization of messages should in my view be a separate issue (at
least in the first instance, and conceptually/abstractly) from checking.
However, I believe there may be value in addressing the bundling of the
two, a la BTP.

4) If this is left to implementers then we are saying that these two or
three issues are non-interoperable optimizations/improvements. The
absence of optimizations is non-fatal functionally; the absence of
facilities for checking risks producing an extremely limited and/or
unsafe protocol with respect to a necessary feature (unofficial
reply-checking, even less specified than OTS).

Therefore I would identify these issues for vote in principle, in order
to work out what the work plan should be:

ISSUE A. Does WS-Acid support one or more facilities for checking?

ISSUE B. If A = yes, then does it do so by defining a CHECKED signal?

ISSUE C. If A = yes and B = yes, does CHECKED indicate "all enrolments
have occurred" or "all work has occurred"?

ISSUE C. If A = yes, then does it do so (instead of or in addition to B)
by defining sufficient identity of inferiors to allow counting/identity
of enlistments?

ISSUE D. If A = yes, does this facility belong in a WS-TXM general
layer, or is it specific to WS-Acid?

ISSUE E. Is the enlistment vectorization optimization worthwhile?

ISSUE F. If E = yes, then should E be addressed by a general message
vectorization or concatenation mechanism, or by one specific to E?

ISSUE G. If B = yes, and E = yes, is there a connection via bundling of
some kind to allow communication of a vector of enlistments in
conjunction with the CHECKED semantic?

ISSUE H. If B = yes, should the B solution apply only to a defined
subset of WSDL 2.0 MEPs, or should it be capable of fitting any pattern
of one-way conversation?

ISSUE I. If H = any pattern, then should it be exemplified against a
popular subset of WSDL 2.0 MEPs?

ISSUE J. Should semantic PREPARED obviate semantic ENROL?

If we knew the collective voted answer to these questions, then we would
be able to address potential solutions to the identified requirements.

Alastair 

-----Original Message-----
From: Greg Pavlik [mailto:greg.pavlik@oracle.com] 
Sent: 25 July 2005 15:44
To: Greg Pavlik
Cc: Green, Alastair J.; Mark Little; ws-caf
Subject: Checked transactions

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?

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

Greg