CORBA 2.6.1 Programmer's Guide for C++

1. Creates a factory object, inheriting from .
2. The factory object creates a listener event-handler object and associates 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 (such as a Pathsend requester), the factory creates a new worker object
(
Fw_Server_EH_User) to handle the connection.
5. Acting as the server event-handler user, the new worker object creates a server event-handler object and associates itself with the
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
NSDEFw_GFS::Server::Event::reply() method for a file-system or TS/MP client, or the Fw_Sock_Server_EH::send_message() method for
a TCP/IP client.
9. When it is ready to shut down, the factory invokes the
stop_listening() method.
A client wrapper for a context-free Pathsend requester uses the
NSDEFw_GFS class to perform Guardian file-system I/O. The following steps are
required in the client wrapper program:
1. Call
ORB_init(). This method initializes the event-framework internals, including an event thread and a single instance of the $RECEIVE
event handler (
NSDEFw_GFS::Receive_EH).
2. Create a client-wrapper factory object at startup time. The client-wrapper factory is a Guardian file-system listener event-handler user
(
Fw_Listener_EH_User).
3. The client-wrapper factory associates itself with a new listener event-handler object (
NSDEFw_GFS::Listener::EH) that it creates. This
listener event handler listens at the null subdevice (necessary because the Guardian file system expects a subdevice number, but the
TS/MP protocol opens a process rather than a subdevice).
The constructor is as follows:
// Constructor: create a new listener event handler object
// and begin listening for events.
Client_Wrapper::Factory::Factory()
{
ip_EH = new NSDEFw_GFS::Listener::EH;
ip_EH->ip_user = this;
ip_EH->start_listening( "" );
}
4. Use the signal_completion() and the wait_for_completion() methods.
When the factory object determines that it is no longer required (on the last close by the LINKMON process), it uses the
signal_completion() method to allow the main thread to continue to completion:
void
Client_Wrapper::Factory::signal_completion()
{
workCompleted.lock();
workCompleted.signal();
workCompleted.unlock();
}
The wait_for_completion() method is used to wait for the client-wrapper factory object to complete its work:
void
Client_Wrapper::Factory::wait_for_completion()
{
workCompleted.lock();
workCompleted.wait();
workCompleted.unlock();
}
5. When OPEN messages arrive on $RECEIVE, the event handler invokes the factory’s connect_in() method. The connect_in() method
creates a worker to service that connection.
Client_Wrapper::Factory::~Factory()
{}
// Got a connect indication; create a new worker object to
// handle the connection. Have the worker object accept
// the connection.
void
Client_Wrapper::Factory::connect_in (void *pp_client_key)
{}
void Client_Wrapper::Worker::handle_event (NSDEFw_GFS::Server::Event *event)
{ ...
}
As previously noted, a new worker is created to handle each new OPEN message. The worker object is a server event-handler user
(
NSDEFw_GFS::Server::EH_User).
The worker's
data_in() method is invoked when an I/O event is completed. For each WRITEREAD event, the worker creates a new worker
thread to process the WRITEREAD request.