Re: Updated soap12-part3

Thanks, David.  I think this is very close.  Honestly, I'm not happy with 
the change that says that the MEP covers multiple receiving nodes.  The 
draft at [1] says:

"The scope of a one-way MEP is limited to the exchange of a message 
between one sending and one receiving SOAP node. "

The current draft [2] says:

"The scope of a one-way MEP is limited to the exchange of a message 
between one sending and zero or more receiving SOAP node(s). "

Did we formally agree on this change?  I know that David Hull has been an 
advocate for it, but I have been consistently and strongly against.  If 
the group has made this decision, so be it, but if not I think we should 
stick with the status quo until a decision to the contrary has been 
agreed.  I do understand, I think, why he prefers this, but I think it's 
against our existing precedent.  The fact is that request/response could 
have allowed for sending the request to multiple nodes, and folding or 
delivering all the responses.  Lots of fault tolerant systems implement 
request/response this way, and we made what I think is the right choice to 
not explicitly model that complexity in the request/response MEP.  Smart 
people can adapt this stuff as they see fit, but I think the MEPs should 
tell the basic story.  After all, nothing in SOAP says what a node is, and 
if you want to do a distributed implementation of your receiver over 
multiple machines that's a fine thing to do, and especially easy with 
one-way.  I think that particularly the one-way MEP benefits from being as 
simple and obvious as possible.  Send one message, to one (logical) place. 
 Period.  There are lots of games you can play under that abstraction if 
you wish to.

If I should lose on this, and we stick with mutliple destinations, then I 
think the table description of ImmediateDestinations needs to say 
something about potentially multiple destinations, how they're 
represented, etc.  I think we need some statements about what to do if 
transmission to one destination is seen to fail -- should we try others? 
As I say, I'd prefer to avoid such complexity, but if we go there, we 
should be clear on which choices are locked down, and on which things you 
have lattitude.

Also, a nit:  "The description is an abstract presentation of the 
operation of this MEP. It is not intended to describe a real 
implementation or to suggest how a real implementation should be 
structured."  I know what's intended, but this implies that the spec has 
no bearing on what makes a good or a bad implementation.  Of course, it 
does.  An implementation that doesn't send an outbound message, is not a 
good implementation of a sender per this spec.  How about:  "This MEP 
provides a high-level description of the responsibilities of senders and 
receivers implementing this pattern;  this specification is not intended 
to constrain in other respects the details of any particular 
implementation."  Or some such.

Another nit:  In "[SOAP Part 1]Processing SOAP messages)"  I think you 
want a space after the "]".  I'm getting a word wrap that looks like:

see SOAP 1.2 Part 1 [SOAP Part
1]Processing SOAP messages

Otherwise, looks good to me.  Thanks!

Noah

[1] http://www.w3.org/2000/xp/Group/6/soap12-part3-20060804.html
[2] http://www.w3.org/2000/xp/Group/6/soap12-part3-20060809.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"David Orchard" <dorchard@bea.com>
Sent by: xml-dist-app-request@w3.org
08/09/2006 04:23 PM
 
        To:     <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Updated soap12-part3


Is available at http://www.w3.org/2000/xp/Group/6/soap12-part3
 
I believe this draft deals with all outstanding issues, specifically those 
from Noah and DavidH.
 
AFAIK, this is ready to move to WD.
 
Cheers,
Dave

Received on Wednesday, 9 August 2006 22:42:57 UTC