CORBA 2.6.1 Programmer's Guide for C++

The following sections elaborate on the static view of NonStop CORBA components shown in Figures A-1 and A-2, by describing one way that requests
and responses flow between the components.
Walkthrough of Message Flows Using the Naming Service as an Example
Message flows in a NonStop CORBA subsystem can be complex. Understanding the patterns is often helpful in debugging an application or tuning for
performance. You may find it useful as background information when you deploy applications.
This section describes the flow of messages from a client to and from a single service, the Naming Service, as an example of how the flow might happen in
a typical application. This walkthrough is not an exhaustive description of how such flows occur. There are other possible ways an application could work,
but the walkthrough shows a relatively simple example.
Communicating with the root naming context is the first activity many clients engage in. But the Naming Service is not a unique entity; it is treated as just
another NonStop CORBA server. It uses the configuration database and transport protocols like other NonStop CORBA servers.
When NonStop CORBA is installed, a basic working configuration is stored in the configuration database. The Naming Service configuration would be
configured using the configuration database entity
NS@ORB(-ORBprofile NS)as follows:
[dbname:$data01.RK00.NSDCFGDB] 2>entity NS@ORB
fs_server true
use_comm_server true
server_class NS
pathmon $Zndm
tsmp_server true
tcp_server true
When the application is started, the following flows occur (Figure A-4):
Figure
A.4. Message Flows