Re: WG:RPC

I'd like to respond to all of these together, even though my comments are
associated with Mark's message.

--mark

Mark Jones
AT&T Labs

> Re: WG:RPC
>
> From: Mark Nottingham (mnot@akamai.com)
> Date: Wed, Mar 07 2001
>
>   ------------------------------------------------------------------------
>
> Date: Wed, 7 Mar 2001 19:14:18 -0800
> From: Mark Nottingham <mnot@akamai.com>
> To: marwan sabbouh <ftdata@yahoo.com>
> Cc: rden@loc.gov, ms@mitre.org, xml-dist-app@w3.org
> Message-ID: <20010307191416.G20610@akamai.com>
> Subject: Re: WG:RPC
>
> This sounds good. I've been thinking there's three kinds of modules:
>
> * Those that supply generic, 'pluggable' services, like encryption,
>   authentication, etc. These can be used in any message, they're not
>   transport- or application-specific.
>

This is one reason why I think composability is important at the module level
(why I put it in the Abstract Model for Module Processing proposal).  The
output of one module (decryption) might be the input to another
(authentication, application-specific, etc.).

>
> * Those that are application toolkits, to standardize common
>   functions, like RPC. These might bring requirements in terms of
>   transport or message correlation requirements, and will only be
>   used for certain applications.
>

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.  You could have the sender more explicitly indicate that
they payload was to be processed as an RPC, rather than replying on a more
implicit contract between sender and recipient by directly marking the block
as using RPC conventions, but SOAP doesn't seem to do that.  The sender and
receiver have simply agreed to treat it as such.  (The sender knows that the
receiver supports a method call with a particular signature.)  It is
specifically stated that "SOAP for RPC is orthogonal to the SOAP protocol
binding".  Presumably, you need a binding that supports request-response
patterns, but lots of non-RPC usage will also use request-response patterns in
exactly the same manner --  they just won't adhere to the restricted markup
conventions of RPC usage or use the same invocation mechanisms.  The non-RPC
modules/handlers might  use other invocation mechanisms such as accessing a
DOM model of the block, running a SAX-style parser on the block as it streams
through, etc.

At the nuts and bolts level, in terms of the current abstract model, the way
this works is the sending XMLP application has an API for submitting an RPC
call.  The API provides a "toolkit" on the sender side to give the method call
the appropriate RPC markup (e.g., modelled as a struct in SOAP) and selects
the XMLP_DATA (request-response) operation since a response is required.  The
XMLP Layer chooses the appropriate transport (if not also somehow indicated by
the application) and sends it on its way.  At the receiving end, the XMLP
Processor determines the appropriate module/handler to operate on the block
and dispatches a call into the receiving XMLP application level.  When the
handler gets access to the block, it knows that it is implementing an
RPC-style method call, and it  invokes some utility function to take the
block, map it into a method call (in the handler's language binding), make the
call, wrap up the return result in the appropriate RPC-style XML markup and
send it back down to the XMLP Layer for traversal back to the sender.  The
XMLP Layer of the sender gets the response, returns from the XMLP_DATA
operation with the XML RPC markup.  The API call in the sender transforms the
XML RPC result markup back into the native data structures of the caller and
returns the value to the caller.

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

>
> * Those that are applications. Not sure of an example here.

Huh??  Why aren't applications simply modeled as modules that receive XMLP
blocks, return responses (or generate faults), etc. just as your generic,
pluggable modules that you listed above do?  They will generally be "terminal"
modules from a composability viewpoint, but in same cases they may be useful
either as standalone apps or as modules used by other apps.

>
>
> Does this make sense?
>

>
> On Tue, Mar 06, 2001 at 09:35:58AM -0500, marwan sabbouh wrote:
> > first, I m in agreement with the layerd architecture
> > you propose.
> >
> > >what's on
> > >top of the XP layer?  Is it another layer, with a
> > >bunch of modules, one
> > >of whichis RPC, and on top of that, there's the
> > >application?    Or does the application
> > sit on top of the XP layer?
> >
> > In the case of RPC, I have to say that the application
> > sits on top of the RPC module. The app. calls methods
> > implemented by the RPC module.  The rpc module calls
> > method implemented by the XP layer. Below is an
> > examination of an XMLP RPC implementation:
> >
> > The XP client or app. does the following to call a
> > remote mehod:
> > 1-Create an XP transport Binding
> > 2-Serialize the message according to the set of RPC
> > convention for XP and RPC
> > 3-Attach the message to the transport Binding
> > 4- send the message
> > 5-wait for the reply
> >
> > The XP app. sits on top of the XP listener and uses
> > the RPC module. The apps interacts with the RPC module
> > who uses XP objects.
> >
> > 1-The XP binding listener receive the requestand hands
> > off the request to the rpc module
> > 2- The RPC module deserialize the message using the
> > set of conventions defined by XP
> > 3- the RPC module unmarshal method names and params
> > accoeding to xp conventions
> > 4-call the method implemented by the application
> > 5-serialize the reply using the set of conventions
> > defined by XP
> >
> > 6-return to the XP listener
> > 7- Listener sends reply to the client
> >
> >
> > comments please?
> > marwan
> > --- Ray Denenberg <rden@loc.gov> wrote:
> > > marwan sabbouh wrote:
> > >
> > > > we were asked to look into how RPC fit into the
> > > XMLP
> > > > architecture. Is  Rpc a module? or Is it an
> > > > application that sits on top of XMLP?  --
> > >
> > > This is difficult without some layered architecture
> > > to refer to. Can we
> > > informally designate some of the layers we're
> > > talking about, just for a frame of
> > > reference?
> > >
> > > Let's say there's an XP layer. Just below it is,
> > > let's say, the "message
> > > transfer" layer, which may be http or beep. Below
> > > that is the transport layer.
> > >
> > > If we can accept that for sake of discussion, my
> > > question would be, what's on
> > > top of the XP layer?  Is it another layer, with a
> > > bunch of modules, one of which
> > > is RPC, and on top of that, there's the application?
> > >    Or does the application
> > > sit on top of the XP layer?
> > >
> > > --Ray
> > >
> > >
> > > Ray Denenberg
> > > Library of Congress
> > > rden@loc.gov
> > > 202-707-5795
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email at your own domain with Yahoo! Mail.
> > http://personal.mail.yahoo.com/
> >
>
> --
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)

Received on Thursday, 8 March 2001 11:15:56 UTC