Re: WG:RPC

"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 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.

Received on Monday, 12 March 2001 12:03:05 UTC