Re: Directions for SOAP One-Way MEP (Joint Note from David Hull & Noah Mendelsohn)

Well, it's been my opinion for several years that having introduced all 
the complexity of intermediaries into the processing model, we dropped the 
ball in not telling a story about them in MEPs.  I think the picture you 
paint is one of the ones we would want to consider seriously, but perhaps 
not the only one.   For example rather than having the sender and receiver 
disagree about the MEP in use, it's possible that the MEP could explicilty 
discuss the roles of intermediaries. 

Anyway, I don't think we want to back into trying to straighten this out 
now, because I think doing it right will take discussions that could 
easily dwarf the one way discussion.   I don't see much reason why the 
one-way MEP needs to say more about intermediaries than did the 
request/response, and while I would have preferred that they both tell a 
better story, this doesn't seem to me to be the time to dive deep.  I 
think I'd leave it alone.


In the particular case of Response-only, I think one way to look at it is 
that there's a distributed implementation of the responding node, I.e. 
including both the true response node and also its proxy. 

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








Yves Lafon <ylafon@w3.org>
09/28/2006 12:10 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     xml-dist-app@w3.org, David Hull <dmh@tibco.com>
        Subject:        Re: Directions for SOAP One-Way MEP (Joint Note 
from David Hull & Noah  Mendelsohn)


On Tue, 12 Sep 2006, noah_mendelsohn@us.ibm.com wrote:

When you are using the SOAP Response MEP in the HTTP binding, it is 
entirely possible that you may hit a HTTP proxy cache in the middle.
So a first request will go through the cache to the SOAP endpoint, while 
subsequent request may be served by the cache directly.
In that case, are we still using the SOAP Response MEP? From the 
originator, yes, as it is (mostly) transparent. For the receiver, no, as 
nothing is received in the subsequent calls.

In the case of the one way MEP, the story might be the same. There is a 
global assumption that from the sending and the receiving side we are 
observing one way messages, but only the binding implementation of that 
MEP would tell the story of "is it multicast-capable or not". So my 
preference to be as agnostic as possible about the support of multicast in 

the one way MEP definition, while keeping the spirit of the unicast 
definition in the MEP (one sender, one receiver).


> (This note is jointly authored by David Hull and Noah Mendelsohn)
>
> As you all surely could not fail to observe, the two of us have been
> particularly active and on somewhat different sides of the question: 
what
> should we do about multicast in the one-way MEP?  Over the past several
> days we've made some effort to resolve as many of those differences as 
we
> can manage, and we offer this status report in the hope that it will be
> useful to the rest of the working group in deciding what to do next.
>
> A few days ago, David posted a summary of what he took to be the open
> issues [1].   We are now in agreement that all of these can be 
reasonably
> easily resolved, regardless of whether we choose to do multicast or not. 
A
> few turned out to be misunderstandings, and on others we either can
> propose specific resolutions, or we believe that the remaining work to 
be
> done is unlikely to be seriously controversial.  A summary of the issues
> and their suggested dispositions is at the end of this note.
>
> That leaves the big question, which is whether to do multicast at all. 
Our
> preferences on this remain somewhat different, but we have agreed that
> each of our concerns has been amply communicated to the group, and that
> the remaining step is to find consensus with the other members of the
> workgroup.  As input to that, we suggest that the following options be
> considered.  For now, we assume that any MEP(s) to be published would be
> as W3C Notes.  With each option, our (somewhat differing) personal
> preferences are listed:
>
> Option 1:  Publish a single MEP to be named something like "One Way
> Point-to-Point SOAP MEP"  This would allow only a single message to a
> single destination.  (Noah's personal preference; David can't live 
with.)
>
> Option 2: Along the lines of our first working draft, a single MEP 
renamed
> to be something like "One Way Multicast-Capable SOAP MEP".  As in the
> first working draft , this would allow bindings to restrict themselves 
to
> a single message and destination, and would allow other conforming
> bindings to support multiple messages (but with identical envelopes) to
> multiple destinations (multicast.)  (Noah's 3rd choice.  David's first
> choice).
>
> Option 3: Publish two Notes, each with one of the MEPS.  In other words,
> publish both of the MEPs given in options 1 and 2. This is a new option
> the WG has not considered, but it may be an appealing compromise.  While
> it does involve publishing two Notes, we agree that once you do the
> multicast one, the diffs to create pt-to-point are measured in a few
> hours, if not a few minutes.  Both MEPs would be published at the same
> time.  (Noah's probable second choice, and his preferred way if we do
> multiast.  David's second choice, behind option #2).
>
> We suggest to the chair and the workgroup that the above be among the
> options considered.
>
> Regarding our personal positions:  David believes that, from the
> standpoint of applying SOAP to existing protocols, multicast and unicast
> are equally important primitives.  David's main priority is thus to have
> first class support for multicast, one way or the other, and while he 
has
> some preference for doing a single MEP with a switch (option 2), he can
> live with option 3.
>
> Noah believes that unicast is the more fundamental abstraction in 
computer
> networking.   He therefore feels it's desirable to have a pure 
exposition
> of unicast in a separate MEP.  He believes that such an MEP will be the
> natural one for UDP, IP (should we wish to put SOAP directly in IP), and
> for the many physically point-to-point networks that are created by 
direct
> wiring.  Thus, Noah's preferences are, in order: unicast-only (option 
1);
> 2 MEPs (option 3); one MEP with switch (option 1).
>
> Thus, while our preferences are different, it appears that we can both
> live with the option of publishing two separate notes, one with a 
unicast
> MEP and one with a multicast.  The text in the two should be very 
similar,
> and in both cases easily adapted from our FWD. We acknowledge this is an
> option the WG has not seriously debated to date.
>
> As to the specific issues from David's note at [1], the summary of our
> progress on those is:
>
>> Rewriting of destinations [2], corrected for loss of formatting
>> in [3], discussed in [4], [5].  This is independent of
>> multicast  For example, re-writing can occur with XMPP chat and
>> (IIUC) email to a single address.
>
> Follow precedent in existing MEPs, which makes clear e.g. that
> ImmediateSender need not have the same value as ImmediateDestination.
>
>> "MEP instance" vs. "MEP" [6].  This is a trivial editorial fix,
>> independent of everything.
>
> Some remaining distance between the two of us as to what's really 
intended
> by the original text. Shouldn't be to hard for the WG to resolve.  So,
> specific wording TBD.
>
>> Inconsistency of number of properties [7].  This is independent
>> of multicast.  Having separate names for the sender's and the
>> receiver's view of the Message appears to make every mention of
>> the Message property longer.  As the issue name suggests, it's
>> also inconsistent with the treatment of the other two properties.
>
> Keep the property names, which are derived from the existing ROR, but
> split into two separate property tables, one for sender properties
> (ImmediateDestination and Outbound message) and one for receiver (the
> other two).
>
>> Description of ImmediateDestination [8], discussed in [9]. This
>> broke into 4 parts (see following), but I agree that the issue
>> as a whole is only an issue in the context of multicast. If we
>> were to abandon multicast, we would instead face a somewhat
>> differently formulated set of similar issues.
>
>> - "immediate destination" is not a
>>   very informative description of
>>   ImmediateDestination.
>
> Editorial.  We can tune up, but note that this same sub-optimal
> explanation is in the existing MEPs.
>
>> - material about multicast should be
>>   consolidated in section 2.2
>
> Suggest adding high level intro to 2.2, but in the case of any
> multicast-capable MEPs, do talk in the property tables about the fact 
that
> an ImmediateDestination may indeed be interpreted as causing 
transmission
> to multiple receivers.  Specific wording TBD.
>
>> - no need to talk about "multicast group"
>
> Replacement wording TBD.
>
>> - discussion of "standard means of
>>   representing"?
>
> Replacement wording TBD.
>
> We both hope that this, which represent our joint suggestion for how to
> move forward, is useful to the workgroup in considering next steps. 
Thank
> you.
>
> David Hull
> Noah Mendelsohn
>
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0010.html
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2006Aug/0046.html
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2006Aug/0048.html
> [4] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0000.html
> [5] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0008.html
> [6] http://lists.w3.org/Archives/Public/xml-dist-app/2006Aug/0047.html
> [7] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0001.html
> [8] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0005.html
> [9] http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0007.html
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Thursday, 28 September 2006 18:11:10 UTC