The CORBA naming service associates names with object references, and clients and servers use it to locate and advertise CORBA objects. Fintan Bolton describes the newer of the two major CORBA versions, the Interoperable Naming Service.

This chapter is from the book

This chapter is from the book

The CORBA naming service is used by clients to locate CORBA objects and by
servers to advertise specific CORBA objects. It plays the role of a bootstrap
service, enabling clients to find other services and facilitating initial connections
between clients and servers.

The basic function of the naming service is the association of names with object
references. A server creates associations between names and object references
for those CORBA objects that are intended to serve as initial points of contact.
A client that knows the name of an object can then retrieve its object reference
by querying the naming service.

The naming service is available in two major versions:

The original CORBA Naming Service.

The CORBA Interoperable Naming Service. This is a more recent extension
and revision of the original naming service. The semantics of certain operations
are specified more precisely. A string format and a URL format are defined
for names. New operations are declared in the CosNaming::NamingContextExt
interface.

This chapter describes the newer Interoperable Naming Service. If you want
to use the original CORBA Naming Service, you must restrict yourself to the
subset of IDL that excludes the interface NamingContextExt.

Overview

The naming service is a simple locating service that allows clients to look
up an object location using a name as a key. The name can be specified in a
human-readable stringified name format or in a raw name format.

Before a client can look up an object, the association between the object
location and its name must be created. This association is known as an object
binding, and it is normally made by a CORBA server.

Figure 1 illustrates the
steps in using the naming service. It is typically implemented as a standalone
process that runs independently of the client and server. These steps are followed:

Create an object binding. As a server is starting up, it creates a number
of CORBA objects that will serve as points of initial contact for clients. These
objects are advertised to clients by creating object bindings in the naming
service. The bindings consist of a series of name/object reference
associations.

Resolve a name. A client can access each of the objects advertised in the
previous step by resolving a name. This consists of looking up an object
reference using its name as a key.

Use the target object. Since an object reference is all the client needs
to access an object, the client can now go ahead and use the object.

This is the main functionality provided by the naming service, which is,
essentially, a database of object bindings. The collection of object bindings is
usually—but not always—arranged in a hierarchy. There are two kinds of
bindings in the hierarchy:

Context binding—An association between a name and a naming
context

Object binding—An association between a name and an object
reference

The hierarchy is illustrated in Figure 2.
In many ways it resembles the directory structure of a file system. Open circles
represent naming contexts, which play a role analogous to directories
in a file system. Closed circles represent object references, which play a role
analogous to files in a file system. They are the leaves of the hierarchical
tree.

At the top of the sample hierarchy is the initial context. Immediately below
the initial context are three naming contexts: London.region,
New_York.region, and Frankfurt.region. At a lower level of
nesting are the naming contexts London.region/Main.failover and
London.region/Backup.failover. At a lower level again are some object
references—for example,
London.region/Main.failover/StockExchange.