How RPC Server Stubs are generated?

, ,
1

Hi All,

As far as I understand, for RPC to work, there must be a rpc server stub (also known as skeletons) on the server, and a rpc client stub on the client side. In the case of EntireX RPC, I understand that EntireX generates a client stub in a form of a wrapper class (java wrapper, dcom wrapper, .net wrapper, etc…) However, I still don’t understand how the rpc server stubs are generated. Is there a source code for it? if there is, where? Could some one please explain. I would really appreciate it.

Thanks a lot,
Paul

2

Hi Paul,

it depends on the particular RPC Server if a stub is necessary or not. For example, the Natural RPC Server and the CICS RPC Server do not require a server stub.

On the other hand, the Java RPC Server and the C RPC Server require a server stub. You will find a corresponding menu item in the EntireX Workbench to generate a server stub.

Which RPC Server on which platform do you intend to use ?

Kind regards,
Rolf

Rolf Bahlke
Software AG Research and Development.

3

Hi Rolf,

Thank you very much for your reply.

I am using Natural RPC Server on VSE.

Could you please explain why the natural rpc server does not require the sever stub while the java and C rpc server do?

Thanks,
Paul

4

one way to understand an EntireX RPC server is to view it as three parts: the actual server process, the server stub and the business logic.
the server process takes care of communication with the Broker; the stub is called by the server process to marshall/unmarshall parameters and communicate with the business logic; and the business logic does it’s thing.
In the case of C and Java, the server process is provided (rpcserver.exe, jrpcserver.bat); you have to generate the stubs and ‘tie’ them to the business logic - either by coding inside the generated stub (java) or through a config file / filenaming (C).
In the case of Natural, the server ‘process’ is part of your Natural environment (SYSRPC). Natural does not require a stub as the marshalling/unmarshalling is handled by SYSRPC, and the business logic is ‘tied’ to the RPC server process by the library name and program name in the IDL (corresponding to the library and subprogram in Natural).
Hope this helps!
- arp