Re: Addressing within envelope or binding-specific?

I think this is an example of a choice that we will face repeatedly in a 
variety of areas: which things to encoding the envelope in a fixed manner, 
and which to propagate hop to hop.  I think either is capable, in 
principle, of routing a return message through multiple transports, but 
the trade-offs are different.

If the return address is to be encoded in a fixed manner in the envelope, 
then we need to deal with the case were the original sender does not in 
any useful sense know its identity (per my original note), or the related 
case in which the sender has some notion of its identity, but not in a 
form that would actually be useful for routing a return message.  Consider 
message that first went through the public network, and then through some 
company's private message queuing system (MQSeries, etc.)   Yes, in 
certain cases the originator could put a URI into the envelope to identify 
itself.  Whether that URI would in fact be the most useful routing cookie 
to send the response back through MQSeries would depend a lot on how the 
application and the environment were built behind the firewall. 
Furthermore, we know that parsing and perhaps updating the XML envelope 
tends to have performance implications, and is to be avoided in situations 
where low overhead is desired.

The trade-offs are different, I think, for hop by hop propagation of 
return addresses.  Let's assume that the message originates through HTTP, 
and the ultimate response is to be generated quickly enough to send over 
the HTTP response Channel.  The originator puts no indication in the 
envelope, but sends the outbound message and the connection remains open. 
The message arrives at what I think we are calling the transport 
intermediary, for requeuing perhaps over MQSeries.  The software 
responsible for the requeuing would have to send through MQSeries, either 
in the SOAP envelope or in some binding-specific manner (compare to 
SOAPAction) an indication that an open HTTP connection is waiting for the 
response, and some cookie usable to find that connection when the response 
returns.  Presumably the work would be done, a response generated back 
through MQSeries carrying the cookie, and the correct connection would be 
identified for responding through HTTP.

I am not trying to make a quick decision as to which are these 
architectures is better, merely pointing out that both are possible and 
that there are trade-offs.  I think we will face analogous decisions for 
much of the information that relates to routing and message patterns over 
multiple transports.

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







marwan sabbouh <ms@mitre.org>
03/19/01 07:19 AM

 
        To:     Scott Isaacson <SISAACSON@novell.com>
        cc:     moreau@crf.canon.fr, Noah_Mendelsohn@lotus.com, 
w3c-xml-protocol-wg@w3.org, xml-dist-app@w3.org
        Subject:        Re: Addressing within envelope or binding-specific?

I am concerned that the address of the client be lost as a request
traverses multiple intermediaries that uses different protocol binding. 
That is why I advocate a mechanism to carry a client URI or address in a
request.  The client or an intermediary may fill this entry.

marwan

Scott Isaacson wrote:
> 
> >>> <Noah_Mendelsohn@lotus.com> 03/16/01 03:20PM >>>
> >Jean-Jacque Moreau suggests:
> >
> >>> not just allocate a service URI to the
> >>> endpoint/receiver, but also allocate one
> >>> to the sender
> >
> >Maybe, but I think there may be situations in which a sender doesn't in
> >any useful sense know its own name, but in which the binding knows the
> >return path implicitly.  As we have seen on the web with NAT and other
> >protocols, not all clients have useful IP addresses or DNS names, for
> >example.  I think it should be possible to send an XMLP 
request/response
> >from these.  Of course, you could fake out a return address, but the 
point
> >is that in certain cases it really is the binding and underlying 
transport
> >that do the correlation and routing.
> 
> Agreed, as long as their is a common place where the sender name could 
go.
> It should be optional, but should be consistently there, and by "faked 
out" I
> assume you mean some "null" or "empty" or "unknown" or "anonymous" type
> special names that could be used in place of a real name.
> 
> Scott
> 
> > <snip/>

Received on Monday, 19 March 2001 09:27:06 UTC