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

Noah,

Thanks for your detailed note. I don't think the issue is about 
designing a new multicast MEP right now, nor about reusing the existing 
Request-Response MEP for doing multicast; it is whether one can indeed 
design a multicast MEP with the current framework, without limiting the 
design range. You suggest sending out multiple outbound messages. This 
is already an implementation choice. Should that be surfaced at the 
MEP/property level? What impact does this have on the message path? etc.

We seem to have had at least one concern[1] expressed by a supplier of 
multicast systems.

The issue is also that we may have inadvertantly broken (some of) the 
resolution to issue #103 [2], especially steps 1) and 2), which insisted 
on having "an ultimate receiver" -not "the", whereas we have "the 
initial sender"-, which, given our usual carefulness in crafting 
definitions, I read to mean there might be more than one ultimate 
receiver. So I think the status quo is s/the/an/, as this is what was 
agreed in the past.

I know this was important to Henrik previously; I don't know whether 
this still is. (Cc'eing him.)

Thank you,

Jean-Jacques.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2003Jun/0040.html
[2] http://www.w3.org/2000/xp/Group/xmlp-issues#x103

noah_mendelsohn@us.ibm.com wrote:

> 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 Monday, 16 June 2003 07:50:06 UTC