RE: Suporting multicast with an "exactly once" MEP

FYI, when I see 2+ screens of text within about 90 minutes of you
asserting there is no slippery slope, don't worry, things are ok, my
concerns about slippery slope go right up again.  


________________________________

	From: xml-dist-app-request@w3.org
[mailto:xml-dist-app-request@w3.org] On Behalf Of David Hull
	Sent: Wednesday, August 30, 2006 1:57 PM
	To: xml-dist-app@w3.org
	Subject: Suporting multicast with an "exactly once" MEP
	
	
	Re-reading Noah's changes, I noticed something I'd missed the
first couple of times around:
	

		In the absence of failure in the underlying protocol,
this MEP consists of zero or more SOAP messages. The scope of a one-way
MEP is limited to transmission of (nearly) identical messages from one
sending node to zero or more receiving SOAP node(s); typically, in the
case of multiple receivers, the messages differ only in their
destinations.
		

	First, note that this re-writing of destination can also happen
in any unicast protocol that forwards, and that it need not happen at
all in a multicast protocol.  As always the root cause is decoupling,
not multicast.
	
	Decoupled messaging may be broken down into two interactions:
Sender gives a message to the transport ("into the ether"), and
transport gives message to receiver ("out of the ether"), with the
second part happening zero or more times in general.  Each of these,
however, is a simple one-way interaction with a single sender and a
single receiver.
	
	The transport may thus be seen as a pseudo-intermediary that
participates in a unicast one-way MEP instance with the sender and with
each receiver separately.  It may also choose to re-write the
destination of the message sent.  I say "pseudo-intermediary" because
this scheme is probably not kosher with respect to the SOAP model of a
single path from sender to receiver.  Strictly speaking we (probably)
have N+1 SOAP messages sent: One from sender to transport, N from
transport to receiver.
	
	(Alternatively we could define N message paths, each originating
at the sender and terminating at a receiver and all going through a
single intermediary which may rewrite the destination, but I'm leery of
this.  The sender should see only one path.  I'm particularly uneasy
with the case of zero receivers.)
	
	As I've said, I'm not sure that this solution fits well with the
SOAP messaging model (frankly, that's been a recurring concern), and in
particular how it interacts with intermediaries.  It would seem to
require that all intermediaries come between the sender and the
transport or the transport and the receiver.  This might not be a
problem.  E.g., an encrypting intermediary would always go between
sender and transport, and conversely for decryption.  I suppose it all
depends on what we're doing with intermediaries.  If there's a solid
case for sending to an intermediary through a decoupled transport, we
may need to re-think.
	
	Other than that, how does it fit the basic constraints I
mentioned earlier?
	

	1.	Actual implementations do it.  If I publish a message,
or send it to a mailing list, or send a broadcast or IP multicast
packet, multicast will happen. 
	2.	Multicast looks like a single operation to the sender. 
	3.	Multicast looks like a single operation to each
receiver. 
	4.	The sender and all receivers are participating in the
same operation, particularly for the purposes of logging and error
reporting. 

	We account for (1) by treating the transport as a forwarding
agent.  This seems quite natural.  In many cases (e.g. email, IM) the
connection between sender and receiver and a forwarding agent is
explicit.  In others one can at least make a plausible case for it.
	
	We account for (2) by treating the act of sending as a MEP
instance between the sender and the transport.
	
	We account for (3) by treating the act of receiving as a MEP
instance between the transport and the receiver.
	
	We don't seem to account for (4) directly, but (4) might not be
a valid constraint anyway.  In a decoupled world, senders and receivers
may know nothing about each other.  If they do, it's either because the
transport provides means for them to do so, or because there's something
in the messages themselves.  Either one is compatible with the model
given.  For that matter, I don't think the current text really addresses
this explicitly either, nor should it.
	
	What we've done here is to give up on modeling the
sender/receiver interaction as a single MEP.  I hasten to point out that
this is inherent in decoupling and not peculiar to multicast.  If I send
you (and you only) email, I don't wait until you receive it.  I send it
and I'm done.  Later, you pick it up.  AFAICT, it makes much more sense
to model this as two interactions than as one two-part interaction with
an indefinite (and possibly infinite) wait between parts.
	
	How does this affect bindings?  I'm not sure it does, at least
not much.  The core of a binding is the mapping between bundles of
properties and transport-level messages, and that remains intact.
Separating sending and receiving into different MEPs leaves room for the
binding to describe things like the re-writing of the destination in
some (but not all) transports.  Since this is transport dependent, it
has to be the binding that discusses this.
	
	Note that bindings to the existing text can talk about this,
with or without Noah's amendment, since the sender and receiver have
separate copies of the properties.  The alternate I've proposed above
just seems to provide a more natural place to do so.