BEA Logo BEA Tuxedo Release 7.1

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

 

   Tuxedo Doc Home   |   Programming   |   Topic List   |   Previous   |   Next   |   Contents

   Programming a BEA Tuxedo Application Using TxRPC

Building an RPC Server

RPC servers are built and configured in much that same way that ATMI Request/Response servers are. In fact, the service name space for RPC and Request/Response servers is the same. However, the names advertised for RPC services are different. For Request/Response servers, a service name is mapped to a procedure. For RPC servers, a service name is mapped to an IDL interface name. The RPC service advertised will be <interface>v<major>_<minor>, where <interface> is the interface name, and <major> and <minor> are the major and minor numbers of the version, as specified (or defaulted to 0.0) in the interface definition. Because the service name is limited to 15 characters, this limits the length of the interface name to 13 characters minus the number of digits in the major and minor version numbers. This also implies that an exact match is used on major AND minor version numbers because of the way name serving is done in the BEA Tuxedo system. Note that the interface, and not individual operations, are advertised (similar to DCE/RPC). The server stub automatically takes care of calling the correct operation within the interface.

RPC servers are built using the buildserver(1) command. We recommend using the -s option to specify the service (interface) names at compilation time. The server can then be booted using the -A option to get the services automatically advertised. This approach is used in the sample application, as shown in A Sample Application.

The buildserver(1) command automatically links in the BEA Tuxedo libraries. However, the RPC runtime must be linked in explicitly. This is done by specifying the -f -ltrpc option after any application files on the buildserver line. Normally, the output of the tidl(1) command is a server stub object file. This can be passed directly to the buildserver command. Note that the server stub and the application source, object, and library files implementing the operations should be specified ahead of the runtime library, also using the -f option. See the makefile rpcsimp.mk, in A Sample Application, for an example.