xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ar...@cornell.edu
Subject Re: Interceptors/Introspection patch
Date Thu, 07 Mar 2002 16:00:00 GMT

The concept is really not that difficult.  This patch simply adds the 
ability to add callbacks ("interceptors", filters", "hooks", call 
them whatever you want, "listeners" maybe?) which are called at specific 
stages in the remote procedure call process.  These interceptors are given 
the contextual information of the call at the time (the operation name, the 
method arguments, etc.), and are able to modify them when a 
request/response is sent out over the wire, and conversely when a 
request/response is read from the wire.

This is useful if you want to manipulate the call for instance, to add 
some custom contextual information (e.g. security tokens), or if you want 
to perform some operation on the generated XML document (e.g. encryption, 
XSLT transformation, whatever).  Since the XML-RPC library, as it is, 
provides none of these hooks, I had to add them in.  IMO, an "interceptor" 
mechanism should be a standard feature of a remote procedure call 
protocol.  The only overhead this patch adds is accumulation of 
HTTP headers (as far as I can tell there are only about 4 or 5 that get 
sent), and iteration through the list of interceptors, which is simply a 
no-op if none are registered.  Performance can be further improved by 
using nonsychronized list implementations, but I do not do this simply 
for the sake of backwards compatibility with 1.1.  (in any case, any 
overhead this patch adds is dwarfed by the overhead of XML document 
generation, parsing and transmission in the first place, so I think it is 
a non-issue)

You'll have to refer to the XML-RPC Introspection site for details on 
what that is.  Basically introspection allows you to query the API 
of the remote server, and get a list of calls, and a textual description 
of those calls.  Again, pretty straightforward stuff.

Look through and run the example (it should run "out of the box") and you 
should get the idea.  In the example I modify the arguments being passed, 
add a custom header, and perform XOR "encryption".

Sure, some people will say PKI/SSL is the solution to the problem of 
passing authentication information, and encrypting the stream...but not 
everybody lives in the world of PKI yet - there are many other security 
schemes and uses for manipulation of the rpc call (just off the top of my 
head: on-the-fly GZIP compression of the request; XSLT transformations of 
the XML-RPC document, to SOAP perhaps; dynamically translating from one 
API to another, or between versions of APIs; logging each RPC call to 
some logging service; sending out events based on RPC calls; on and on).

Also, please CC: my email address on responses - I have subscribed to 
theh rpc-dev-digest list, but so far it seems to be a black hole out of 
which I get no responses.

Aaron Hamid

> Begin forwarded message:
> > From: "EXT-Raiteri, Ashley L" <ashley.l.raiteri@boeing.com>
> > Date: Thu Mar 07, 2002  08:33:59  AM US/Mountain
> > To: "'rpc-dev@xml.apache.org'" <rpc-dev@xml.apache.org>
> > Subject: RE: Interceptors/Introspection patch
> > Reply-To: rpc-dev@xml.apache.org
> >
> > Aaron.
> > I am not sure I even understand what the patch provides.
> > The description in on your web page perhaps requires more knowledge than
> > I have to understand.  Can you explain it more thoroughly.
> > Ashley Raiteri
> > Boeing S&C
> >
> >
> > -----Original Message-----
> > From: arh14@cornell.edu [mailto:arh14@cornell.edu]
> > Sent: Wednesday, March 06, 2002 1:40 PM
> > To: rpc-dev@xml.apache.org
> > Subject: Interceptors/Introspection patch
> >
> >
> >
> > Guys, it seems like a new release went out today...I haven't been able 
> > to
> > get a straight answer on whether any of you are interested in my
> > interceptors patch (since merged with Eric Kidd's Introspection patch).
> >
> > http://aeolus.cit.cornell.edu/xmlrpc.html
> >
> > Now that there is a new release I have to go back and update the patch.
> > Do you guys see any promise in this patch (either of them really)?  The
> > less I have to maintain in parallel the easier my life will be.
> >
> > Aaron Hamid
> > Integration & Delivery
> > Cornell University
> >
> >

View raw message