Updated soap12-part3

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Updated soap12-part3

David Orchard

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

Reply | Threaded
Open this post in threaded view
|

Re: Updated soap12-part3

noah_mendelsohn

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" <[hidden email]>
Sent by: [hidden email]
08/09/2006 04:23 PM
 
        To:     <[hidden email]>
        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


Reply | Threaded
Open this post in threaded view
|

Re: Updated soap12-part3

David Hull
In reply to this post by David Orchard
This looks pretty good.  The one thing that jumps out at me is that the table doesn't distinguish sender properties from receiver properties.  Specifically (as I understand it):
  • The OutboundMessage only matters to the sender.
  • The InboundMessage only matters to receivers
  • Absent intermediaries, at least, ImmediateDestination may be redundant for a receiver (or may be quite important?).
  • Absent intermediaries, at least, ImmediateSender may be redundant for the sender, and may not be available to the receiver in some bindings (e.g., decoupled pub-sub).  But maybe that's why we have wsa:From.
  • Personally, I'm not clear on how we're modeling intermediaries (e.g., is the ImmediateDestination the ultimate receiver or the first intermediary, or does it depend?  Put another way, does the MEP extend end-to-end or one hop?  If it's end-to-end, each intermediary will have its own copy of all the properties).  Maybe we've covered this already and I just haven't swapped it back in.
Obviously, we'll have to come to some sort of resolution on multicast.  It may well be that Noah and I have equally powerful ways of expressing the same constraints, in which case we can probably avoid a steel cage match.  Otherwise, I'll point out that Noah can't hit me because I wear glasses.


David Orchard wrote:

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


Reply | Threaded
Open this post in threaded view
|

Re: Updated soap12-part3

noah_mendelsohn

David Hull writes:

> Personally, I'm not clear on how we're modeling intermediaries (e.
> g., is the ImmediateDestination the ultimate receiver or the first
> intermediary, or does it depend?  Put another way, does the MEP
> extend end-to-end or one hop?  If it's end-to-end, each intermediary
> will have its own copy of all the properties).  Maybe we've covered
> this already and I just haven't swapped it back in.

Well, I think we badly dropped the ball on this in the original Part 2,
and I would have loved to see us do it more carefully.  Still, I don't
think that the one way MEP, which is supposed to be a simple building
block with limited WG time investment, is the umbrella under which to
tackle intermediary-enabling MEPs.  Should we ever wish to invest in that,
I think we should evaluate that as a separate item, make sure the
membership is ready to commit the necessary resources and that
implementors will actually do something with the results, and then do it
for Request/Response first. So, I'd prefer to leave intermediaries in the
same somewhat vague state for one-way that they are for req/resp.

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