Re: WG:RPC

	From moreau@crf.canon.fr Mon Mar 12 12:02 EST 2001
	Delivered-To: jones@research.att.com
	X-Authentication-Warning: lancelot.crf.canon.fr: smap set sender to <moreau@crf.canon.fr> using -f
	Date: Mon, 12 Mar 2001 18:02:11 +0100
	From: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
	X-Accept-Language: en,fr
	MIME-Version: 1.0
	To: "Mark A. Jones" <jones@research.att.com>
	Cc: mont@akamai.com, xml-dist-app@w3.org, Ray Denenberg <rden@loc.gov>,
	        Ray Whitmer <rayw@netscape.com>, Marwan Sabbouh <ms@mitre.org>,
	        Henrik Frystyk Nielsen <frystyk@microsoft.com>
	Subject: Re: WG:RPC
	Content-Transfer-Encoding: 7bit

	"Mark A. Jones" wrote:

	> As I understand RPC in the SOAP context  (see SOAP 1.1 section 7), it is
	> simply a convention for how  the XML markup is to be structured to represent a
	> method invocation and how the method response is to be structured in the
	> return value.  As far as I can tell, nothing associated with the message says
	> that it is an RPC.

	Sounds like a new issue for the Issues List, doesn't it?

It is not an issue if we just want to keep the SOAP philosophy, which
is that senders and receivers can employ any convention that they want
in the XML markup.  RPC is only one such convention.  You can even
have additional conventions layered on top of RPC.  For example, not
only is it RPC, but the first parameter which is a string represents
an object ID of some sort.  As long as senders and receivers agree on
the convention, there is no problem.  The SOAP spec included one such
convention for RPC.  Presumably, we should do the same for the XML
Protocol.

	> It seems to me that fundamentally RPC is a convention for marking up method
	> calls and return values. I think of modules as things which take in blocks and
	> produce response blocks or faults.  There are two possible views.  Either (1)
	> RPC is a module which takes in an RPC marked-up block,does the proper method
	> dispatch, and then returns the response block/fault, or (2) the module that
	> implements the application takes in an RPC marked-up block,  invokes an RPC
	> utility function to transform the block into a method call and dispatches it.
	> In  view (2), which I think is the SOAP view, RPC is not itself a module but
	> an interpretation of the input block  that the application module can impose.
	> View (1) that thinks of RPC as a module has some problems.  Unless blocks are
	> explicitly marked as RPC, the XMLP Processor doesn't know that the block
	> requires RPC processing; it is the application module that knows it is RPC.

	See above (and probably we can fix it easily?).

	> Furthermore, you can't think of the RPC module as composing with an
	> application module, e.g.,  applX(RPC(A)), since the RPC module doesn't produce
	> a block -- it has to map the RPC markup directly into a
	> method call.

	I thought you said earlier "(1) RPC is a module which [...] returns [a] response
	block [...]". If this is the case, why is composition not possible? For example,
	if RPC(A) returns response block B, then applX(RPC(A)) = applX(B) is a legitimate
	operation?

	Jean-Jacques.

What I meant here by RPC(A) is just the dispatch part of the RPC call,
not the actual module (applX) being called.  SOAP doesn't distinguish
between an applX(A) that uses RPC conventions and one that doesn't.
If it uses RPC then it is up to applX to interpret the markup as such
and to dispatch the applX method encoded in the RPC, perhaps with help
from some utility function for this purpose.  My point here is that
you can't make that utility function itself a module since it is
invoked from the "inside" of the applX module.

Mark Jones

Received on Monday, 12 March 2001 16:50:47 UTC