As per my action item, I am forwarding to xml-dist-app a discussion about issue 41[1] which happened on the administrative mailing list. 1. http://www.w3.org/2000/xp/Group/xmlp-issues#x41 -- Hugo Haas - W3C mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092
attached mail follows:
At the face-to-face meeting last week, I agreed to take ownership of issue No. 41. [1] The issue references an e-mail from Vidur Apparao [2]. I am a little unsure of my specific responsibilities regarding ownership of this issue, so I guess I'll start by just trying to sort out the concerns and the terminology as I understand it, ending with a proposal to stimulate discussion (or maybe just quickly resolve this.) Background ========== The pertinent excerpt from Vidur's note is: >> R200 >> >> "The XML Protocol must contain a convention for >> representing calls and replies between RPC (Remote >> Procedure Call) applications and services." >> >> Section 7 [1] of the SOAP 1.1 spec addresses the >> issue of using SOAP for RPC. It provides a >> "uniform representation of remote procedure calls >> and responses". >> >> "The conventions must include the following: >> >> 1.Complete and unique identification, by means of >> URI syntax, of the program, service or object and >> procedure or method to be called." >> >> Section 7 states that the "URI of the target >> object" is necessary to make an RPC calls and that >> the "protocol binding [should] provide a mechanism >> for carrying the URI". It further implies that the >> method name should be a QName, and is modeled as >> an element in the SOAP enveloper body. >> >> Issue RPC1: The target (program, service or >> object) URI is pushed down to the protocol binding >> and is not represented in the envelope instead. >> While this does not conflict with the >> requirements, I believe it's an important (and >> possibly debatable) decision. This decision >> precludes sending an RPC invocation through an >> intermediary that uses different protocol bindings >> for sending and receiving XP messages. >> Going back to the original SOAP specification [3]: >> To make a method call, the following information >> is needed: >> >> * The URI of the target object >> * A method name >> * An optional method signature >> * The parameters to the method >> * Optional header data >> >> SOAP relies on the protocol binding to provide a >> mechanism for carrying the URI. For example, for >> HTTP the request URI indicates the resource that >> the invocation is being made against. Other than >> it be a valid URI, SOAP places no restriction on >> the form of an address (see [4] for more >> information on URIs). Analysis ======== My impression is that before we can resolve this issue, we must clarify the relationship between the identification of the "target object", to use the SOAP terminology, and the actual URI to which a message is sent. I am not sure that Vidur would agree, but my view is that the two are in general different, though may in some circumstances be the same for convenience. Why? Let's assume that there is a service, we will call it an object for now, which accepts purchase orders. As a client application, I use some URI to indicate the identity of the service (object) to which I am sending my purchase order. Let me further assume that, at a lower level, I have routing software that is aware of two different transports available to the same logical destination: one uses HTTP, and the other uses MQSeries. So, at a lower level, the routing software will decide to actually open and HTTP connection (perhaps) to a URI which may or may not be the actual one I used to identify the service resource. A further consideration is the case in which several "hops" are needed over a variety of transports to reach the actual provider of service. So, in general, the address supplied by the sending application can be independent of the transport-specific URI actually used for delivery. Questions to be resolved ======================== So, I propose that there are at least two levels of URI address to which Vidur's question can be applied: 1) The identity of the service itself 2) The one or more URI's used to physically deliver the message over each "hop" For each of these, we can consider what I think is Vidur's essential question: should the URI be carried within the XML envelope, outside in a manner determined by the binding, or perhaps both? In general, the advantage of providing an address within the envelope seems to be that the message becomes more self describing, that the information is carried in the standard manner, and that in the case of No. 1 above the representation is independent of binding and untouched through successive hops. The drawback of relying on information in the envelope, as we discovered during the design of SOAP, is that there can be significant processing overhead in cracking an XML envelope during message routing and checking. Furthermore, I am not sure whether anyone feels there are use cases for the anonymous routing used for SOAP bodies, and potentially for other headers. Noah's proposals ================ Just to start the process of agreeing on a resolution, here is a strawman (strawperson) proposal: * For all applications of XMLP, not just RPC, a standard means will be provided within the envelope to represent the identity of the intended recipient of each header or the body (using SOAP terminology). In other words, this is a proposal pertaining to No. 1 above, calling for an explicit Actor URI on each header. * Bindings can, where appropriate, duplicate this information in a binding specific manner outside the envelope, thus avoiding the need to repeatedly parse the XML in situations where that is undesirable. * The addresses discussed in No. 2 above are the private business of each binding. In general, the binding need not include such addresses within the XML envelope, but as always, the binding has the option to create a binding-specific header to carry information within the envelope is for some reason the binding finds that the desirable. For the record, I do not feel that including any of the addresses in the envelope is necessary to correct operation of the system. I am going along with Vidur's recommendations because it seems like reasonably clean design, and relatively harmless as long as bindings have free to do optimizations as well. Worry to take the other route, and like SOAP rely only on the binding, I think that in multi-hop scenarios, each binding can pass the destination address to the next. Also, I personally am somewhat unsure as to why we want to preserve the asymmetry in SOAP, in which headers destined to intermediaries carry explicit addresses but headers (such as the body) intended for the last stop do not. For that reason, the above proposal treats all headers symmetrically. Finally, if this approach is adopted, it highlights the need to clarify our notions of path and of multi-hop routing... since all headers become symmetric, there is some question as to how we distinguish the endpoint from intermediaries, if that even survives as a useful distinction. In any case, it seems to me that we should adopt the same answer for RPC as for other messages, especially other request response messages. I hope this note is useful in starting the discussion. [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x41 [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0193.html [3] http://www.w3.org/TR/SOAP/#_Toc478383532 ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
attached mail follows:
Noah, My phone died halfway through this discussion today, so I'm probably missing something important. > So, I propose that there are at least two levels of URI address to > which Vidur's question can be applied: > > 1) The identity of the service itself > 2) The one or more URI's used to physically deliver the message over each > "hop" > [snip] > > * For all applications of XMLP, not just RPC, a standard means will be > provided within the envelope to represent the identity of the > intended recipient of each header or the body (using SOAP > terminology). In other words, this is a proposal pertaining to No. > 1 above, calling for an explicit Actor URI on each header. Does this mean that the service URI should be specified as the Body's Actor? If so, am I correct in assuming that this will not be required in all messages? -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA)
attached mail follows:
Mark Nottingham writes:
>> Does this mean that the service URI should be specified as
>> the Body's Actor? If so, am I correct in assuming that
>> this will not be required in all messages?
Well, I am still forming my opinions on this, but I tried to craft a
proposal that would deal with the essence of Vidur's concerns. A couple
of factors went into this proposal:
1. It is not apparent why the ultimate destination should
be addressed using conventions different from
intermediaries.
2. I detect a trend, which I agree with, that we will
ultimately deal with message paths and routing
(and probably therefore identifying the endpoint)
as some kind of order or partial order on
the actors.
Anyway, the proposal is that every header be provided with an explicit
actor, which for the sake of discussion would not be the empty string.
Note also something that I had missed until Henrik pointed it out to me:
in SOAP more than one header can have a null Actor, and BODY is just a
convenient way for providing one. Of course, we could change that.
Anyway, the proposal is an explicit Actor for each header.
>> Does this mean that the service URI should be specified
>> as the Body's Actor
Well, it needs to be on some header's Actor. Again, remember that in SOAP
more than one header can be destined for the endpoint, and contrary to
appearances, <BODY> is not special except in the case of RPC. (I
personally think that aspect of the design needs cleaning up, but that is
what we have today.) In other respects, I think the answer is "yes", with
the caveat that the phrase "the service URI" might or might not have the
same connotation for everyone. We still need to be careful regarding the
degree to which we claim it identifies a specific endpoint in code vs.
some more abstract notion of destination.
------------------------------------------------------------------------
Noah Mendelsohn Voice: 1-617-693-4036
Lotus Development Corp. Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------
attached mail follows:
On Thu, Mar 15, 2001 at 05:23:09PM -0500, Noah_Mendelsohn@lotus.com wrote: > > >> Does this mean that the service URI should be specified > >> as the Body's Actor > > Well, it needs to be on some header's Actor. Again, remember that in SOAP > more than one header can be destined for the endpoint, and contrary to > appearances, <BODY> is not special except in the case of RPC. (I > personally think that aspect of the design needs cleaning up, but that is > what we have today.) In other respects, I think the answer is "yes", with > the caveat that the phrase "the service URI" might or might not have the > same connotation for everyone. We still need to be careful regarding the > degree to which we claim it identifies a specific endpoint in code vs. > some more abstract notion of destination. I guess I'm trying to tease apart the relationship between node URIs, endpoint URIs and service URIs, along with message exchange patterns and correlation, and also I suppose these abstract destination URIs that seem to be popping up. For example, in a response message that's piggybacking on an HTTP response, there aren't too many things that make sense as the Body's actor (something that points at the final receiver) except "the request's originator" in some form. Since we most likely don't know it unless the request message tells us, this has to be an anonymous construct like "http://.../client" (I personally don't like this style of URI much, but that's for a different day). It also doesn't seem to make sense to put in the service URI here at all (or maybe we have different definitions of Service URI). It seems like we'll need abstract URIs that cover this case and others like it. Should they be defined by the binding specification, or at a more global level? -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA)
attached mail follows:
Mark Nottingham wrote: > [...] in a response message that's piggybacking on an HTTP > response, there aren't too many things that make sense as the Body's > actor (something that points at the final receiver) except "the > request's originator" in some form. Since we most likely don't know > it unless the request message tells us, this has to be an anonymous > construct like "http://.../client" You make me wonder whether we should not make Noah's proposal (i41) more symmetric, ie not just allocate a service URI to the endpoint/receiver, but also allocate one to the sender. This is probably necessary when using transports that do not directly support request-response patterns, such as SMTP. Comments? > (I personally don't like this style of URI much, but that's for a different > day). [...] I agree. Jean-Jacques.
attached mail follows:
hmmm, I think this may be necessary. Otherwise, the idendity of the sender may be lost if processed by different intermediaries marwan Jean-Jacques Moreau wrote: > > Mark Nottingham wrote: > > > [...] in a response message that's piggybacking on an HTTP > > response, there aren't too many things that make sense as the Body's > > actor (something that points at the final receiver) except "the > > request's originator" in some form. Since we most likely don't know > > it unless the request message tells us, this has to be an anonymous > > construct like "http://.../client" > > You make me wonder whether we should not make Noah's proposal (i41) more > symmetric, ie not just allocate a service URI to the endpoint/receiver, but also > allocate one to the sender. This is probably necessary when using transports > that do not directly support request-response patterns, such as SMTP. Comments? > > > (I personally don't like this style of URI much, but that's for a different > > day). [...] > > I agree. > > Jean-Jacques.
attached mail follows:
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. ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
attached mail follows:
Noah_Mendelsohn@lotus.com wrote: > 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. Maybe implicitely behind my suggestion was the possibility that we might do response dispatching (on the client), and not just request dispatching (on the server), through processors/handlers. This would make the whole architecture more symmetric. Jean-Jacques.
attached mail follows:
>>> <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/>
attached mail follows:
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/>
attached mail follows:
Is enabling intermediaries which do this one of the things we want to do 'out-of-the-box', or just allow? On Mon, Mar 19, 2001 at 07:19:39AM -0500, marwan sabbouh wrote: > 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/> -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA)
attached mail follows:
That is what we have to agree on. I am not sure what the answer is.What are the trade-offs between the two options?What are the trade-offs between the two options? I am tempted to say that we just allow that. This way, the specification can be written in a modular way. On the on the other hand, this may result in different vendors implementing the same functionality in many different ways, unless some working group address these issues. . Mark Nottingham wrote: > > Is enabling intermediaries which do this one of the things we want to > do 'out-of-the-box', or just allow? > > On Mon, Mar 19, 2001 at 07:19:39AM -0500, marwan sabbouh wrote: > > 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/> > > -- > Mark Nottingham, Research Scientist > Akamai Technologies (San Mateo, CA USA)
attached mail follows:
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/>
attached mail follows:
This seems like a question between network routing and document
routing. In either case it calls for a path to the initial XMLP sender
with identification of the sender through a URI, as the transport layer
information (i.e., sender) is not necessarily available to the XMLP
layers. I have a couple of quick questions on how this relates to the
requirements:
* R302 says "without prior agreement"
* Does this require the XMLP layer to preserve the URI of the
initial XMLP sender?
* Does this also require preservation of the entire sequence
of intermediary URIs in the document?
* Do these URIs have to resolve to the same physical resources
on the reply path or subsequent returns? The introduction
to section 4.4 ("intermediaries cannot be implicitly
defined") may be logical (units that are in some sense
equivalent) rather than physical (identical and state cannot
in any case be ensured)
* May the return path resolve intermediaries through a URI
reference instead of carrying a self contained URI list of
intermediaries?
* R304 says "many transport or application protocol bindings ...
without information loss".
* Does this reinforces the document centric approach rather
than an intermediary centric one?
* Does it allow the mutable documents can either be self
contained or URI-reference based?
* R608 requires the possibility of bindings to SSL channels.
* Does this suggest a document based approach allowing for the
secure flow of information?
* Where would a document embedded context be defined? At the
XMLP or at the "application" layer? Is this a candidate for
a suggested standard module?
* Is it permissible that an initial path setup construct a
path of "lilly pads" for stepwise processing, and that
subsequent phases reuse this path?
Michah Lerner
michah@att.com
Received on Thursday, 26 April 2001 02:12:01 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:41:43 GMT