Interoperable Naming Service
This chapter is from the book
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 Basic use of the CORBA naming service.
){kind=link}
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.
){kind=link}
Figure 2 A sample naming service hierarchy.
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.