Forwarded message 1
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
------------------------------------------------------------------------