CORBA 2.6.1 Programmer's Guide for C++

An object interface definition written in IDL
A server that implements the interface defined by the interface definition
A client application that makes use of an instance of a stock object
Introduction to NonStop CORBA Components
You will work with several NonStop CORBA components as you design and write your applications, including:
Bootstrap Service Daemon (BSD)
For applications that need interoperability with the bootstrap protocol in some earlier versions of J2EE, the Bootstrap Service
Daemon provides a standard interoperable protocol for resolving an initial reference ID and for listing the supported initial reference IDs.
The BSD configuration is held in the configuration database.
Configuration database
This database is built during the installation and configuration of NonStop CORBA. It contains an entry for the Naming Service that
includes an IOR used by
ORB::resolve_initial_references. The database is used to maintain the TCP/IP addresses for the Comm
Servers and the LSD. It is also used to maintain a map table for associations between the Comm Servers and remote client hosts. It
also contains a Comm Server load table. Finally, it is used to maintain application configurations. You modify the configuration database
directly by using the NonStop Distributed Component Console or by using the
cfgmgt tool.
Comm Servers
Comm Servers can be thought of as gateways allowing network clients to communicate with application servers on the NonStop
system. They also act as TCP/IP network resource concentrators, mapping all connections from a client address to the same Comm
Server. Comm Servers take advantage of TS/MP capabilities and are configured as TS/MP (Pathway) server classes. You configure
Comm Servers to use various transport protocols depending upon your application design.
Location Service Daemon (LSD)
The LSD acts as an Internet InterORB protocol (IIOP) port mapper. The LSD uses an object's object key to determine how to forward
requests. The LSD configuration is held in the configuration database. The LSD updates the database for each new client-
address/Comm-server mapping, and it updates existing mappings daily.
Interoperable Location Service Daemon (ILSD)
The ILSD acts as a forwarding agent for the Interoperable Naming Service. Like the BSD and LSD, ILSD uses an object's object
key to determine how to forward requests. If the request is aimed at a corbaloc URL, the ILSD forwards the request to the URL named
in the key string. If the request is aimed at a corbaname URL, the ILSD forwards the request to the reference obtained by resolving the
stringified name against the
CosNaming::NamingContext specified in the key string.
Interface Repository (IR) Daemon
The Interface Repository provides distributed access to one or more databases as persistent storage for Interface Repository
information.
IIOP over SSL
The Secure Sockets Layer Inter-ORB Protocol SSLIOP provides transport security for NonStop CORBA objects. NonStop CORBA
objects can interoperate with other vendor's IIOP/SSL implementations. SSLIOP allows private-key and certificate development and
production (you can also obtain certificates from a Certificate Authority). Administrators can configure NonStop CORBA to use IIOP/SSL
with existing applications that are not aware of security features. Alternatively, programmers can gain programmatic control of the
IIOP/SSL configuration and operation by creating or modifying applications to make them aware of security features. IIOP/SSL is an
optional feature set that must be installed and configured on your system before it can be used.
Refer to the NonStop CORBA 2.6.1 Administration Guide for a more complete description of the above NonStop CORBA components.
In addition to the components described above, your applications can make use of the following Common Object Services components
provided as part of NonStop CORBA (these services are CORBA applications like any other):
Naming Service (implemented as a server pool or NonStop TS/MP server class). NonStop CORBA implements the Interoperable
Naming Service specified in the OMG CORBA specifications, with the exception that the Resolve Initial References (RIR) URL is not
supported.
Event Service. A standard application service (one of the OMG Common Object Services) for asynchronous communication among
objects
Transaction Service. NonStop CORBA implements the Transaction Service by means of components that collaborate with the
Transaction Management Facility (TMF) on the NonStop system. These components include special language-specific client stubs, a
Transaction Service process that can run as a TS/MP server pool, and a singleton transaction ID broker process.
You can configure and monitor NonStop CORBA components by using the NonStop Distributed Component Console, a GUI-based
configuration tool. For some application-specific configuration settings you also use a command-line interface as described later in this manual.
For more information about the NonStop CORBA architecture, see
Architectural Walkthrough in this guide and the architecture section of the
NonStop CORBA 2.6.1 Administration Guide.