|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] RE: Checked transactions|
|From:||Newcomer, Eric (Eric...@iona.com)|
|Date:||Aug 1, 2005 7:25:30 am|
I am sorry to have been away on vacation for this discussion and therefore it's a bit hard to catch up in retrospect.
However it occurs to me that checking might be something we could rule outside the scope of the spec, i.e. as an implementation optimization. Has anyone debated this question?
-----Original Message----- From: Green, Alastair J. [mailto:Alas...@choreology.com] Sent: Monday, July 25, 2005 11:04 AM To: Greg Pavlik Cc: Mark Little; ws-caf Subject: [ws-caf] RE: Checked transactions
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.
-----Original Message----- From: Greg Pavlik [mailto:greg...@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
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?