Archive of UserLand's first discussion group, started October 5, 1998.

Re: Help please: XML RPC, CGI, CORBA/IIOP

Author:joubin
Posted:2/6/1999; 7:30:01 PM
Topic:Help please: XML RPC, CGI, CORBA/IIOP
Msg #:2732 (In response to 2718)
Prev/Next:2731 / 2733

I have a XML message which contains remote procedure name and parameters [...]. Suppose the procedure is implemented by C++ or Java on server side, how can I call this procedure from the point after the XML parser [... ?]

If you simply want to provide server-side support for a given qualified procedure name (e.g. examples.getStateName), then if I may suggest (for Java, and analogously in C++):

Have your server expose a foo.xmlrpc.Registry interface which minimally provides a 

void registerProcedureHandler (String procedureName, ProcedureHandler handler) throws ...
method, where in tandem you have defined foo.xmlrpc.ProcedureHandler which minimally provides 
Object callProcedure (String procedureName, Object[] args) throws ...

Your implementation strategy using the above 2 interfaces is fairly open, anywhere from creating a class/procedureName up to using Reflection in a single generic implemetation of foo.xmlrpc.ProcedureHandler which is passed Object/procedurName tuples as needed. The latter is flexible, prevents code bloat, but will result in slower response times.

[Note that in the latter case the same object could also implement both foo.xmlrpc.Registry and foo.xmlrpc.ProcedureHandler.]

However:

If you want to call a method on a specific instance of an object (e.g. myRemoteObject.getStateName(), you'll need (minimally) one additional layer to establish remote reference bindings.

This layer is also a prerequisite to providing the functionality you seek in your q(3) , but keep in mind that you will further need to repartition the protocol (through a transport-protocol-bridge server, i.e. a proxy) to allow for selective routing of the messages through a transport mechanism other than xml-rpc's HTTP POST /RPC2.

The above certainly can be implemented on top of xml-rpc, though, at this point, so much of the interconnectivity (i.e. the "plumbing"), not to mention the Object serializations, is happening above xml-rpc (thus external to the protocol and delegated to the various remote procedures, and the data 'd to obscurity in the intracacies of the implemention) as to pose the question that you have asked: why use xml-rpc?

That's a good question.



This page was archived on 6/13/2001; 4:47:47 PM.

© Copyright 1998-2001 UserLand Software, Inc.