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

Interacting with ATMI

The TxRPC executables use the BEA Tuxedo system to do the RPC communications. Other BEA Tuxedo interfaces and communications mechanisms can be used within the same clients and servers that are using the RPC calls. Thus, it is possible to have a single client making Request/Response calls (for example tpcall(3c), tpacall(3c), and tpgetrply(3c)), making conversational calls (tpconnect(3c), tpsend(3c), tprecv(3c), and tpdiscon(3c)), and accessing the stable queue (tpenqueue(3c) and tpdequeue(3c)). When a client makes the first call to the BEA Tuxedo software, either an RPC call, any of these other communications calls, or any other ATMI call (such as a call for buffer allocation or unsolicited notification), the client automatically joins the application. However, if the application is running with security turned on or if the client must run as part of a particular resource manager group, then tpinit(3c) must be called explicitly to join the application. Refer to tpinit(3c) in BEA Tuxedo C Function Reference for further details, and a list of options that can be explicitly set. When an application completes work using the BEA Tuxedo system, tpterm(3c) should be called explicitly to leave the application and free up any associated resources. If this is not done for native (non-Workstation) clients, the monitor detects this, prints a warning in the userlog(3c), and frees up the resources. In the case of Workstation clients, the resources may not be freed up and eventually the Workstation Listener or Handler will run out of resources to accept new clients.

As with clients, servers can use any of the communication paradigms in the role of client. However, a server cannot provide (advertise) both conversational services and RPC services within the same server; as described later, an RPC server must be marked as non-conversational. Although it is possible to mix ATMI request/response and RPC services within the same server, this is not recommended. One further restriction is that RPC operations cannot call tpreturn(3c) or tpforward(3c). Instead, RPC operations must return as they would if called locally. Any attempt to call tpreturn(3c) or tpforward(3c) from an RPC operation will be intercepted and an error will be returned to the client (exception rpc_x_fault_unspec or status rpc_s_fault_unspec).

Two functions available to servers but not to clients are tpsvrinit(3c) and tpsvrdone(3c), which are called when the server starts up and when it is shut down. Since the server must call tx_open(3c) before receiving any TxRPC operation requests, tpsvrinit() is a good place to call it. The default tpsvrinit() function already calls tx_open().