Suppose I have already generated XML RPC stub and use a command line, say jrpcserver.bat to start the server. However, if sometime later I’ll have to to support another XML service, then another new RPC server will have to be started.
Eventually, dozens, if not hundreds of OS processes (all RPC servers) would be running simultaneously. This doesn’t seem to me effective from point of view of administration and monitoring of many OS processes, even though there is merit of having better isolation between each of the RPC executables.
1: Is there a way to dynamically bind each new RPC generated stubs into a single, already running, RPC server?
2: If the answer is that (out of the box) it is not supported, does it mean that I have to wrap a running RPC server with functionality that allows it to load the new stubs dynamically?
thanks,
Avi
Avi, please confirm that you are talking about the Java RPC Server (and not the XML/SOAP RPC Server).
Rolf,
Your question got me confused because it shows me that I do not understand the product.
The Natural client people wants to have an IDL for each remote service they want to invoke. Since I do not have IDL, I thought that I would take XML schema for each service they want to call, and use the “IDL extractor for IDL schema” and let them use the resulted IDL file for their Natural client (assuming IDL file can represent well any XML schema) while on my ‘server/middleware’ side I’ll create RPC server, either Java RPC server or XML RPC server - I don’t know what is right for me.
Does the answer to the question is different regarding the type of RPC server, be it XML or Java server?
In this case you need the XML/SOAP RPC Server. The extraction does not only generate an IDL file but also a XMM file which has to be deployed to the XML/SOAP RPC Server. This deployment can be made on-the-fly, see http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite9-7/EntireX/9-7_EntireX/xmlWrapper/dynamic.htm.
So you need only one running instance of the RPC Server to support multiple XML services.
Also, if your remote services are represented by WSDLs, you can use the “IDL Extractor for WSDL”, which also generates an XMM file.
For the Natural clients, use the “Generate Natural client” function, which will create a Natural subprogram that your Natural programmers will call. Also generated is a data area (containing the parameters to the subprogram) and a test program that will call the remote service via the subprogram (and serve as an example of how to call the remote service). If you have a Natural RPC Server available, you can deploy these Natural objects directly to mainframe (or Windows or Unix/Linux) Natural environment. Otherwise, FTP the objects to your Natural environment and stow them there.