I have a Java service which should be called from Natural. I set up a Java RPC server in a box that points to a broker (ETB1234:1111) and server name SNAME1 and service CALLNAT. I tested the service using Workbench and everything works fine.
Now I have got couple of other Java services which too needs to be invoked from mainframe which points to the same broker ID and server name.
I tried creating another Java RPC server and ran on the same box. Now when I test the first service from workbench, I’m getting the response as successful. If i invoke it again I’m getting the response as
Broker Error 1001 0016: Callee not found. Library: SYSTEM, Program: GREETRPC Server: Method greet not found in class SystemStub (java.lang.NoSuchMethodException: SystemStub.greet())
I can understand the problem here. The SystemStub.java in first RPC server has got the method related to service one and does not contain the method related to service two. And since there are 2 Java RPC servers running pointing to the same Broker and server name, the request from workbench is diverted to either one of these servers and if it reached the correct one, there is valid response, else the error.
How can i implement this requirement. One way is for different Java RPC servers to point to different broker ID and server name.
If you need different services offered by different servers, then supply each with their own server name (SNAME1, SNAME2, TEST1, GREETER, etc). The calling programs (Natural) needs to specify the appropriate server name corresponding to the server it wants to reach.
You can also vary the Broker ID (assuming you set up another Broker), but it isn’t necessary for the example you describe; varying the server name is sufficient.
Generally, I would expect the Java RPC Server to have a bit less overhead - the data transfer is bound to the target language, rather than the target-independent format that XML gives you. Use of XML nearly always involves additional overhead to compose and parse the XML string, plus the additional network transmission as the XML string is nearly always larger than the language-bound messages for the Java/Cobol/Natural/etc wrappers.
Nonetheless, your mileage may vary…XML’s advantages (more portable, more accessible to other end points) may outweigh a specific performance advantage. You also have to consider where your bottlenecks are - frequently the time on a backend service (e.g. database accesses) are significantly larger than the network or CPU components of the response time - an increase in time to parse the string may not be noticeable in the overall response time.
If you need to invoke a Java class, then use the Java Wrapper. If you need to invoke a web service or other XML service, use the XML Wrapper. There is no provision for mixing the two.