xmlrpc introspection

Graham Dumpleton grahamd at dscpl.com.au
Fri Apr 25 10:05:00 CEST 2003


"Bryan" <belred1 at yahoo.com> wrote in message news:<UR0qa.77049$gK.181217 at rwcrnsc52.ops.asp.att.net>...
> i see a scalability problem with listMethods.  we have a server that
> dynamically loads many providers.  each provider registers one or more
> services.  each service handles one or more methods.  so a typical method
> name would be service.method or for example calculator.add.  when the server
> receives calculator.add, it knows to send it to all providers that
> registered for calculator service.  now when our server receives a
> listMethods request, it has to return all the method names in all providers.
> this could be hundreds or even thousands.  it would be nice if it was
> standard that there was a listServices request and listMethods took an
> optional service parameter.  then you can scale this up.  i noticed that
> it's typical to have method names in the format service.method so i'm too
> far off with this.  i'm probably going to have to implement it this way, i
> just wish it was the "standard" way.

That this presents a problem is not so much a deficiency of the the introspection
API but that many XML-RPC server side implementations only really easily allow
you to have XML-RPC services hosted out of a single URL. To my mind, different
web services should not all be at the same URL if they do different things. If you
can oragnise your server side code so that distinct services are on different URLs
then the introspection API will only be returning methods for that specific service
when called against its URL and you don't have the problem, unless you have a
bizare number of methods which are all to do with that service.

For example, calculator service could be accessed as:

  http://somesite/service/calculator

If you had a database access service, it could be accessed as:

  http://somesite/service/database

Have a look at the python manual for OSE (http://ose.sourceforge.net) to see how
it manages to have all registered services access using different URLs.




More information about the Python-list mailing list