CORBA 2.6.1 Programmer's Guide for C++

and transfer data between a client and a server. This abstraction is defined in the header file ehbase.h. The problem space is separated into
three session roles and two protocol stack roles.
The session roles are the usual listener, client, and server roles. A listener waits for connect indications at a specific address. A client connects
to the address; the listener creates a server to handle the session; and then the listener waits for another connection. The client and server
exchange an indeterminate number of messages over an indeterminate amount of time. Then the client and/or server forces a disconnect.
The protocol stack roles—event handler and event-handler user—allow the components of the NonStop CORBA GIOP to interact with a generic
event handler, and the event handlers to interact with a generic user.
A legacy wrapper can operate on either of two levels with respect to the client, server, or listener roles: that of the event-handler user—using
one of the event handlers provided by NonStop CORBA—or that of the event handler, if the NonStop CORBA event handler for that protocol
does not provide the necessary semantics. If possible, a legacy wrapper should act as an event-handler user rather than as an event handler.
The semantics of the NonStop CORBA event handlers lend themselves readily to TCP/IP, which is a streaming protocol. However, more specific
protocols were developed to provide the correct semantics for GIOP over the Guardian file system and GIOP over TS/MP. Therefore the socket
event handlers defined in the event framework are likely to fit the needs of a legacy wrapper, but the file-system and TS/MP event handlers in
the event framework often will not do so.
This means that to provide a legacy file-system or TS/MP application with the semantics it expects, you may need to implement your own server
or client event handler—that is, have your legacy wrapper act as an event handler. However, in such cases it still may be possible for the
listener portion of a client wrapper to use the listener event handler provided by NonStop CORBA, acting as a listener event-handler user.
The handle_event Method
A program acting as an event handler must implement a method called
handle_event(). This method is invoked by a callback from the NonStop
CORBA event framework when the event framework receives an I/O event of a type registered by the event handler. The callback includes an
event object containing all information necessary to identify the event.
The method implementation should do whatever is appropriate with all relevant I/O events.
Listener Event Handler and Event-Handler User
The basic functions of a listener event-handler user and a listener event handler are shown in Figure 12–3.
Figure 12.3. Listener Event Handler and Event-Handler User
Transfer Event Handler and Event-Handler User
The transfer event handler and event-handler user is a layer of abstraction added so that the GIOP components don't need to know whether
they are playing the client or the server role. A transfer event handler provides a continuous receive/send-on-demand service. Messages are
usually sent as one large entity (called a Message) but received in fragments (called message descriptors, or MDs). Messages, implemented as
a list of MDs, are passed to the handler. Received data is passed to the user in the form of MDs.
The basic functions of a transfer event-handler user and a transfer event handler are shown in Figure
12–4.
Figure 12.4. Transfer Event Handler and Event-Handler User
Client Event Handler and Event-Handler User