CORBA 2.6.1 Programmer's Guide for C++

Caution:
The same NonStop CORBA server (for example, your client wrapper) cannot receive Pathsend requests from
both NonStop CORBA clients and legacy clients. Attempts to send both types of requests to the same process
have unpredictable results.
Writing a Client Wrapper for a Remote (TCP/IP) Client
The client wrapper for a remote (TCP/IP) client is similar to that for a context-free Pathsend requester. The client wrapper cooperates with the
NonStop CORBA event framework using two objects, a factory and a servant (worker). The factory is a listener event-handler user, and the
worker is a server event-handler user.
A client wrapper for a legacy TCP/IP client operates as follows:
1. Creates a factory object, inheriting from
Fw_Listener_EH_User.
2. The factory object creates a socket listener event-handler object (
Fw_Sock_Listener_EH) and associates itself with that event-handler
object as its user.
3. The factory object invokes the
start_listening() method on the event handler to register interest in incoming connect indications.
4. When a connect indication arrives from the legacy client, the factory creates a new worker object (
Fw_Server_EH_User) to handle the
server side of the connection.
5. Acting as the server event-handler user, the new worker object creates a socket server event-handler object (
Fw_Sock_Server_EH) and
associates itself with that event-handler object as its user.
6. When a request arrives from the legacy client, the server event handler passes the request data to the worker in a
data_in() upcall.
7. The worker decodes the request and interacts with the CORBA server, using CORBA requests (containing legacy request data as
parameters) to perform the actual work of the application.
8. The worker translates replies from the server into replies to the legacy client and sends the replies by invoking the
send_message()
method.
9. When it is ready to shut down, the factory invokes the stop_listening() method.
Writing Other Types of Client Wrappers
The client wrapper must cooperate with the NonStop CORBA event framework to perform its tasks. You can write a client wrapper for a context-
sensitive Pathsend requester or a Guardian file-system requester. However, doing so is more complex than the cases described in this manual,
and therefore it is not recommended that you do so without assistance. If you need to integrate one of these types of clients into your NonStop
CORBA application, HP recommends that you contact your service provider.
Managing Transactions in Client Wrappers
To manage transactions in client wrappers, you need to use two proprietary methods, tmf_start() and tmf_end(), that are part of the
CosTransactions::Current interface in NonStop CORBA.
When a client wrapper receives a TMF transaction from a legacy client through the Guardian file system, the wrapper should propagate the
transaction into the CORBA environment by calling Current::tmf_start(), passing the transaction ID from the client as a parameter. This call
directs the Transaction Service to join the TMF transaction and implicitly propagate the transaction context to CORBA transactional objects in
the CORBA server.
When the legacy client ends the TMF transaction, the client wrapper should call
Current::tmf_end(). This call directs the Transaction Service to
suspend its participation in the transaction.
Only one process current transaction controller (the application, the client wrapper, or the Transaction Service) should exist at a time. Before
calling
tmf_start(), the client wrapper should suspend its process current transaction by calling the TMF_SUSPEND_ procedure. After calling
tmf_end(), the client wrapper should resume its process current transaction by calling the TMF_RESUME_ procedure.
For details about TMF_SUSPEND_ and TMF_RESUME_, refer to the TMF Application Programmer's Guide.
The NonStop CORBA Event Framework APIs
NonStop CORBA provides several APIs that are needed when writing client wrappers and some types of server wrappers. These APIs are
interfaces to the NonStop CORBA event framework, which is the core of the NonStop CORBA run-time environment. The event-handler
interfaces provide asynchronous transfer of information between clients and servers, so that a NonStop CORBA application component need not
use underlying transport protocols, such as TS/MP or TCP/IP, directly.
This section gives a general functional description of the event framework APIs. For detailed descriptions of the classes and methods in these
APIs, see the NonStop CORBA 2.6.1 Programmer's Reference.
Design of the Event Framework
The NonStop CORBA event framework supports the handling of I/O events over various transport protocols. It is the core of the NonStop
CORBA run-time environment and is designed to fit the needs of the ORB.
Note:
The NonStop CORBA event framework is distinct from the Event Service, which is defined by OMG and is part of
the Common Object Services. The Event Service is a high-level application service that provides asynchronous