CORBA 2.6.1 Administration Guide

module CORBA{
interface InitialReferences {
Object get(in ObjectID id);
ObjectIdList list();
};
};
Any client ORB must obtain the initial root naming context on an arbitrary host in an interoperable fashion. Using a file system relies on the
presence of a shared file system and an agreed location. These specific and often platform dependent mechanisms prevent all clients from
obtaining the root naming context in a portable and interoperable way.
The BSD uses a standard interoperable protocol to bootstrap to the initial root naming context on any arbitrary host.
ORBs that implement BSD issue Bootstrap GIOP request messages:
CORBA::ORB::resolve_initial_reference(ObjectId)
This operation is equal to a "get" and results in a request with an object key equal to "INIT".
CORBA::ORB::ObjectIdList CORBA::ORB::list_initial_services()
This operation is equal to "list" and results in a request with an object key equal to "INIT".
The BSD plays the server role in the bootstrap protocol as it is an fd socket listener. The BSD configuration includes an IP address and a URL
directory. The default is
$NSD_ROOT/urls. The BSD replies to the list request with a string sequence listing the files in the URL directory. It replies
to resolve the request with an object reference. The parameter identifies a file in the URL directory and the BSD reads the file into a string and
passes the string to CORBA::ORB::string_to_object.
The client role of the bootstrap protocol is not supported by NonStop CORBA.
Activating the BSD Bootstrap Protocol
The BSD's IP address is passed to the client by setting:
'org.omg.CORBA.ORBInitialHost' to the BSD's host address
'org.omg.CORBA.ORBInitialPort' to the BSD's port number
An example of a client start script instructs JDK 1.3 on an NT system to use the Bootstrap protocol to communicate with the BSD in a NonStop
CORBA subsystem running on a specific host:
java -Dorg.omg.CORBA.ORBInitialHost= <change_me> -Dorg.omg.CORBA.ORBInitialPort=4506 Test %1 %2 %3
Where, change_me is a dot-separated IPv4 address like 172.31.41.151 or colon-separated IPv6 address like fe80::a00:8eff:fe06:d093 and 4506 is
the BSD port number. NonStop CORBA does not use the BSD default port of 900, but uses a port dynamically assigned during installation. The
port number can be altered using the Console or the cfgmgt utility to modify the bsd1@ORB entity.
Interface Repository Database
The Interface Repository (IR) is a set of files that contain definitions of object interfaces hosted on your NonStop CORBA application
servers. Information in the IR can be used by clients that access servers using the Dynamic Invocation Interface (DII), as defined by the CORBA
specifications. You access the IR database programmatically through the interface defined in the CORBA Interface Repository specification.
The Common Object Services
NonStop CORBA implements the following CORBA services:
Naming Service
Event Service
Transaction Service
Naming Service
The NonStop CORBA Naming Service implements the Naming Service based on the OMG Naming Service Specification 1.2, with one minor
exception as noted in the NonStop CORBA 2.6.1 Programmer's Reference. The Naming Service provides a repository for the names and
locations of NonStop CORBA application objects.
The Naming Service enables developers to register object names at runtime. In the Naming Service database, naming contexts and their
associated object references are organized into a hierarchical namespace. Client applications can then use the Naming Service to discover the
names and object references for objects they wish to use.
The NonStop CORBA Naming Service is fully and transparently integrated with TS/MP and the Transaction Management Facility (TMF), making
the Naming Service fully scalable, reliable, and performance-oriented.
The Naming Service consists of the Naming Server executable program (deployed as a server pool) and its respective Naming Service database
along with the Interoperable Naming Service Daemon (ILSD). The Naming Server maintains the Naming Service database using key-sequenced
Enscribe files. Applications can bind names to objects and retrieve them by using the CORBA-defined object interface to the Naming Service.
Event Service