Re: New PR issue: one or more ultimate receiver?

Actually, I think we can handle several flavors of multicast with what we 
have in SOAP 1.2, independent of the "the/an" distinction.  I think the 
key is to realize that for many (not all) types of multicast, it's better 
to model the MEP as multiple outbound messages, possibly directly to the 
multicast target, or possibly to nodes that assist with the fanout.  If 
you want responses at all (as opposed to fire-n-forget), it's the  MEP 
that should define the rule for folding the responses.  For example, what 
do you do if an outbound message is sent to 10 nodes, 7 report success and 
3 fault?  Well, there are flavors of multicast involving voting which 
might report that as success.  There are others in which you would want 
one or more of the faults reported, or perhaps an array of 10 response 
statuses.  If you want to use a spanning tree to reach a thousand nodes, 
the MEP can describe the generation of messages by each of the tree nodes, 
and the folding of responses as approriate.  I don't think the exercise is 
primarily to map our existing request/response MEP to multicast. 

 I think our design enables the specification of MEPs that will model any 
of the above.  The specification for the MEP would describe the routing of 
the messages, the generation of one message dependent on another (e.g. if 
you used an explicit tree flood algorithm to fan out the outbound messages 
and fold in the responses), or whatever.  I strongly urge that we NOT 
design the details here.  I'm only making the case that there are many 
useful flavors of multicast that I believe can be well-handled by 
specifying the suitable MEPs, and I think that's more than enough to let 
us move SOAP 1.2 to recommendation.

I would also point out that there is a completely different flavor of 
multicast that I believe we can also handle.  Consider a fault tolerant 
system, perhaps like the space shuttle, where 3 machines all run the same 
software more or less in lockstep.  Thus all requests go to all three, 
which (in the absence of errors) produce identical responses.  Let's 
assume that a hardware or software mechanism in or below the SOAP binding 
causes the multiple message copies to be sent, and handles any necessary 
voting on the responses.  I believe we are quite clear that SOAP says 
nothing about whether the implementation of a SOAP node such as the 
endpoint is distributed or replicated.  In this case, the same chapter 2 
soap logic is being executed consistently by a combination of 3 machines 
which collectively conspire to implement a highly fault tolerant instance 
of what to SOAP is a single node.  In this case, I think you can use our 
ordinary Request/Response or perhaps even Response-only MEPs.  Again, I 
think our design is more than adequate to claim reasonable 80/20 support 
for multicast and to move on to recommendation status.

I  would also point out that during our CR period we heard, as far as I'm 
aware, no concerns expressed by any suppliers of multicast systems.  I 
hope this is helpful.  Thank you.

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







"Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
Sent by: xml-dist-app-request@w3.org
06/13/2003 04:37 AM

 
        To:     Dear XMLP Comments <xmlp-comments@w3.org>
        cc:     XMLP Public <xml-dist-app@w3.org>, David Fallside <fallside@us.ibm.com>, 
Martin Chapman <martin.chapman@oracle.com>, Hugo Haas <hugo@w3.org>, (bcc: 
Noah Mendelsohn/Cambridge/IBM)
        Subject:        New PR issue: one or more ultimate receiver?



The following issue has been raised (e.g. [1]) on ws-arch: is there one 
and only one ultimate receiver, or can there be several ultimate 
receivers for the same message?

The issue is that multicast bindings, for example, may be prohibited if 
there is only one single ultimate receiver.

Currently, Part 1 specifies there can only be ONE ultimate receiver (THE 
ultimate receiver). An earlier version of Part 1 used to allow multiple 
receivers (AN ultimate receiver), as per the resolution to issue 103 [2].

It appears that when the resolution to issue 103 was implemented, not 
all occurences of "THE" were changes to "AN", and that an (unfortunate) 
editorial sanity check later replaced all instances of "AN" to "THE", 
instead of the contrary.

We have two options at this stage:

1) Go with whatever is in Part 1 today, considering that we are too late 
in the Recommendation process; or

2) Reimplement the resolution to 103 (i.e. s/THE/AN/).

I have a preference for option 2) above and consider that this is an 
editorial change only. However, I think we should first investigate 
whether this change is likely to (severely) impact current 
implementations. I don't think so, but at the same time I don't want to 
take the risk of delaying publication.

I apologize for raising this issue so late in the Recommendation process.

Pls remove xmlp-comments of any follow-up discussions.

Jean-Jacques.

[1] http://lists.w3.org/Archives/Public/www-ws-arch/2003Jun/0118.html
[2] http://www.w3.org/2000/xp/Group/xmlp-issues#x103

Received on Friday, 13 June 2003 22:04:07 UTC