CORBA 2.6.1 Programmer's Guide for C++

For further information about the SPT_SERVERCLASS_SEND_ procedure, refer to the Open System Services Programmer's Guide (Section
11).
Caution:
Although you should refer to the Open System Services Programmer's Guide for information about the
SPT_SERVERCLASS_SEND_ procedure, do not use the libraries provided by the product; doing so may
interfere with the operation of the NonStop CORBA ORB. Instead, use the version of the
spthread.h header file
provided in the
$NSD_ROOT/include directory, which includes the SPT_SERVERCLASS_SEND_ procedure and
all necessary underlying routines.
Calling a Context-Free or Context-Sensitive Pathsend Server for Waited
Operations
A NonStop CORBA client can use a server-wrapper process to issue waited requests to a context-free or context-sensitive Pathsend server.
This type of server-wrapper program must do the following:
1. Create the appropriate POA (stateless or stateful) for the wrapper. The conditions affecting this choice are described below.
2. Send data and receive replies by making calls to either context-free (SERVERCLASS_SEND_) or context-sensitive
(SERVERCLASS_DIALOG_xxx) Pathsend procedures. In the calls to SERVERCLASS_SEND_ or SERVERCLASS_DIALOG_SEND_,
set the nowait flag (flags.<15>) to 0.
The choice of a stateless or a stateful POA for the server wrapper depends on several factors:
Whether the legacy server is context-free or context-sensitive
How you map client requests to server dialogs if the legacy server is context-sensitive
Whether you need multiple wrapper processes to handle a high volume of requests
If the legacy server is context-free, you can use either a stateless or a stateful POA. A stateless POA allows you to take advantage of server
pools and is, therefore, advisable unless the volume of incoming requests is low.
If the legacy server is context-sensitive and you are mapping multiple incoming requests to a single dialog with the server, you must use a
stateful POA.
If the legacy server is context-sensitive and you map each incoming request to a new dialog, you can use either a stateless or a stateful POA.
As with a context-free server, a stateless POA is advisable unless the incoming request volume is low.
Caution:
Do not use waited I/O operations with multithreading. Waited I/O operations are process-blocking operations
and, as such, defeat the purpose of multithreading.
For further information about the context-free and context-sensitive Pathsend procedures, refer to the NonStop TS/MP Pathsend and Server
Programming Manual.
Calling a TCP/IP Server
A NonStop CORBA client can use a server-wrapper process to issue TCP/IP socket requests to a legacy server. Because no thread-blocking
jacket is available for these calls, a more complicated technique is necessary, using the object-oriented interfaces (APIs) to the NonStop
CORBA event framework. If you are writing a server wrapper that issues TCP/IP socket requests, you should refer to
The NonStop CORBA
Event Framework APIs for background information.
A NonStop CORBA server acting as a server wrapper sends requests to legacy servers in the form of I/O events through the underlying event
framework. To send such requests, the wrapper invokes the services of a client event handler through the event framework API. The server
wrapper acts as a user of a client event handler: in other words, a client event-handler user.
NonStop CORBA provides various types of client event-handler objects to support transport functions such as I/O completions and error
handling. A wrapper for a TCP/IP socket server should use the client event-handler object that supports TCP/IP socket I/O (
Fw_Sock_Client_EH).
A server wrapper for a legacy TCP/IP server must do the following:
1. Implement a client event-handler user object, inheriting from
Fw_Client_EH_User.
2. Acting as the client event-handler user, create a socket client event-handler object (
Fw_Sock_Client_EH) and associate with the event-
handler object as its user.
3. Invoke the
connect() method on the client event handler.
4. When the event handler returns a
connect_complete() upcall (indicating a successful connection), compose a message by invoking the
method
Fw_Message::get_message(). This method will create a new message if none are available for recycling.
5. Use one of the methods in the
Fw_Message class to write data into the message. If needed, the event framework will use multiple
message data descriptors (
Fw_MDs).
6. Direct the event handler to send the message by calling
Fw_Sock_Client_EH::send_message(). The event handler will initiate the send
operation and return immediately, while the send is still in progress.
7. The response data is returned from the server by means of
data_in() upcalls, one message data descriptor (Fw_MD) at a time. Retrieve
the data from the MDs and assemble it into an appropriate reply to the client.