I have been looking at extending the current xml-rpc module/work that
I found over at www.thedesignexperience.org (Can't remember link) For
those who want some background on xml-rpc go to www.xmlrpc.com and you
should get up to speed within a couple of hours unlike SOAP which has
a much steeper learning curve.
What I have been thinking about
doesn't really abstract out the (problem/solution) of general web
services(WDSL/UDDI/SOAP/XMLRPC) but just deals with extending the
xmlrpc AOLserver module. Also much thanks to those who have gotten the
code this far (Steve Ball, Hafeez Bana, Dave Bauer, Jerry Asher, and
anyone else I've overlooked)
Sorry I don't have time for a full
design document but here are my thoughts/plans for the module.
Adding system calls extension to the
moduleFor background go here Basically
it adds 3 methods
- system.listMethods Returns all
methods that are registered on the individual instance xmlrpc
server
- system.methodSignature Returns an array of all
possible signatures for a single method (xmlrpc allows
overloading)
- system.methodHelp Return a documentation
string for an individual function.
Currently our xmlrpc
module basically registers all rpc procs by adding a variable equal to
the procedure to call to an nsv array named
xmlrpc_procs.
So to add new xmlrpc call you would
define your procedure and then call [xmlrpc_register_proc proc_name]
which simply currently does nsv_set xmlrpc_procs $proc_name $proc_name
I suggest modifying the proc to accept a documentation string
and a list of signatures/procedure names to allow for overloading.
These values would be saved in the nsv array and allow for easy
implementation of all the system.
extensions.
Adding
parameter checking upon invocationThe xmlrpc spec allows for
returning faultcodes/errors but our xmlrpc module only returns them
for malformed xml requests. I suggest reworking the code that
currently invokes whatever method we are calling to first check to
make sure that it is being called with an allowed parameter list. Most
xmlrpc implementations already do this and ours is lagging behind. I
having been debating whether to do this in each registered proc but I
think it could be abstracted out by using our information that we have
saved in our nsv array and allows us to have a one to many mapping
corresponding to the function overloading.
Adding the
system.multicall functionFor background go
here basically
this adds the functionality of packing multiple asyncronous calls to
the server in one request and returning all the result sets saving
bandwidth and latency. While I see this as being very useful it is
last on my current priorities here and shouldn't be too difficult once
the other items have been implemented.
Creating a tcl/adp
page to mimic the debugging/testing functionality found
here This page is
very useful but I would like a local version for non-net and think it
would come in handy.
All of the above items are pretty much
AOLserver module items and not dependent on any OpenACS features but
there may be things that should be considered that I am overlooking.
Down the line there probably should be some abstract wrapper for
general web services implementation but the above items shouldn't be
too difficult to implement and hopefully useful to community.
Questions/comments?