CORBA 2.3.7 Programmer's Guide for C++

incoming connect indications.
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.
4.
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.
5.
When a request arrives from the legacy client, the server event handler passes the request data to the worker in a
data_in() upcall.
6.
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.
7.
The worker translates replies from the server into replies to the legacy client and sends the replies by invoking the
send_message() method.
8.
When it is ready to shut down, the factory invokes the stop_listening() method.9.
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 Pathway or TCP/IP, directly.
This section gives a general functional description of the event framework APIs. For detailed descriptions of the classes