IT-SC book: Advanced CORBA® Programming with C++

Part V: CORBAservices

Chapter 18. The OMG Naming Service

18.1 Chapter Overview

This chapter shows how you can use a Naming Service to obtain object references without having to pass them around as strings. Sections 18.2 and 18.3 present the fundamental ideas and concepts of the service. Sections 18.4 to 18.9 present the details of the IDL operations and explain how to manipulate and locate names and object references in a naming graph. Sections 18.10 to 18.13 discuss a number of design issues, such as the implications of using the Naming Service as part of your overall application architecture and the options for federated naming. Section 18.14 shows how to use the Naming Service in the climate control system.

18.2 Introduction

The OMG Naming Service [21] is the simplest and most basic of the standardized CORBA services. It provides a mapping from names to object references: given a name, the service returns an object reference stored under that name. This is similar to the Internet Domain Name Service (DNS), which translates Internet domain names (such as acme.com) into IP addresses (such as 234.234.234.234). Both the OMG Naming Service and the DNS implement simple mappings from a name to a lookup value and are often likened to a white pages phone book, which maps subscriber names to telephone numbers.

The Naming Service provides a number of advantages to clients.[1]

[1] In the context of this discussion, the term client is used to refer to a client of the Naming Service. That client may be either a client or a server as far as your application is concerned.

Clients can use meaningful names for objects instead of having to deal with stringified object references.

By changing the value of a reference advertised under a name, you can get clients to use a different implementation of an interface without having to change source code. The clients use the same name but get a different reference.

The Naming Service can be used to solve the problem of how application components get access to the initial references for an application. Advertising these references in the Naming Service eliminates the need to store them as stringified references in files.

18.3 Basic Concepts

668

IT-SC book: Advanced CORBA® Programming with C++

The Naming Service maps names to object references. A name-to-reference association is called a name binding. The same object reference can be stored several times under different names, but each name identifies exactly one reference. A naming context is an object that stores name bindings. In other words, each context object implements a table that maps names to object references. A name in the table can denote either an object reference to an application object (such as the CCS controller) or another context object in the Naming Service. This means that, like a file system, contexts can be connected to form hierarchies: contexts correspond to directories that store names to either directories (other contexts) or files (application objects). A hierarchy of contexts and bindings is known as a naming graph. Figure 18.1 shows an example of a naming graph.

Figure 18.1 A naming graph.

In this graph, hollow nodes are naming contexts and solid nodes are application objects. A context can appear either as an interior node or as a leaf node, whereas an application object always appears as a leaf node. Directed arcs represent object references and are labeled with the name they appear under in their context.

This naming graph is similar to what you would expect to see for a DOS or UNIX file system.

Within a particular context, name bindings are unique (each binding can appear only once within its parent context).

Given a starting context, you can navigate to a target node by traversing a path from the starting context to the target node. The sequence of bindings used in the traversal forms a pathname that uniquely identifies the target object.

The same name binding can appear multiple times provided that each binding is in a different parent context. For example, the binding bin appears twice in the graph in

Figure 18.1.

A single object or context can have multiple names. For example, the sample graph uses the name bindings sys and s1 for the same context. (This corresponds to the concept of multiple links to the same file or directory in a UNIX file system.)

669

IT-SC book: Advanced CORBA® Programming with C++

Apart from its similarities to hierarchical file systems, the naming graph in Figure 18.1 illustrates a few significant differences.

It is possible for the graph to have contexts that have no names. Such contexts are known as orphaned contexts. (This is different from a normal file system, which requires every file and directory to have a name.)

A naming graph has one or more distinguished contexts known as initial naming contexts. Typically, initial naming contexts are orphaned contexts (but they need not be). Conversely, if a context is orphaned, it is typically also an initial naming context. As you will see in Section 18.6.3, initial naming contexts determine the points at which clients gain access to a naming graph. An initial naming context corresponds to what we think of as the root directory of a file system.

A naming graph can have more than one root. Typically, each such root is also configured as an initial naming context.

A graph can consist of several disconnected subgraphs.

It is possible for the graph to have loops.

There are reasons for these differences. The OMG Naming Service can be implemented either as a stand-alone service or as a front end to some other existing naming service. If implemented as a front end, the OMG Naming Service must reflect the semantics of the back-end service. If the back end permits loops, the front end must also permit them. The OMG Naming Service therefore imposes as few restrictions as possible on the shape of the naming graph to avoid restricting the choice of back-end service.

Nevertheless, it is probably best if you avoid loops in your naming graph. Loops make the service harder to administer because they create an infinite number of pathnames for the same binding. For example, by traversing the collections, cd, and app2 bindings in a loop, the graph in Figure 18.1 contains an infinite number of pathnames. If a naming graph consists of several disconnected subgraphs, each root is typically configured as an initial naming context. Clients can gain access to initial naming contexts via a special API call (see Section 18.6.3).

18.4 Structure of the Naming Service IDL

The IDL definitions for the Naming Service are provided in a file called CosNaming.idl. The file contains a single module called CosNaming. This module contains a number of type definitions and two interfaces: NamingContext and BindingIterator. The overall structure of the IDL for the service is as follows:

//File: CosNaming.idl #pragma prefix "omg.org" module CosNaming {

// Type definitions here...

670

IT-SC book: Advanced CORBA® Programming with C++

interface NamingContext { // ...

};

interface BindingIterator { // ...

};

};

Note that the repository IDs for the entire specification carry the prefix omg.org. This is a common feature of all OMG specifications and avoids polluting the global namespace for repository IDs.

18.5 Semantics of Names

Intuitively, the names used by the Naming Service behave like file names in a file system. However, there are some differences you need to be aware of.

18.5.1 Name Structure

The names used by the OMG Naming Service are not quite the same as ordinary file names. Here are the relevant definitions:

module CosNaming {

typedef string Istring; struct NameComponent

Istring id; Istring kind;

};

typedef sequence<NameComponent> Name; // ...

};

The NameComponent structure corresponds to a single "hop" in a pathname. A sequence of name components corresponds to a pathname that defines a traversal from some starting context to a target binding. Note that each name component itself consists of a pair of strings: id and kind. In this respect, CosNaming names differ from ordinary pathnames for files (in a pathname, each component is a simple string and not a pair of strings).

18.5.2 Name Representation

The OMG Naming Service specification does not define a representation of names as strings. In other words, we cannot simply write something such as user/u1/fred to denote a pathname. For one thing, the OMG Naming Service places no restrictions on the characters that may be used in a name component (the full set of ISO Latin-1 characters is permissible, including non-printing characters).[2] This means that there is no dedicated separator character, such as "/," to separate name components. Second, because name components themselves consist of a pair of strings, stringified names would require a

671

IT-SC book: Advanced CORBA® Programming with C++

secondary separator (other than "/") to separate the id and kind parts of a name component.[3] Because there is no specified way to express a CosNaming name as a string, we can use tables to show names.

[2]The specification allows an implementation of the Naming Service to restrict the permissible characters, so it can use back-end naming services that support only a limited character set. Most implementations do not restrict the set of permissible characters, but you must inquire from your vendor whether your Naming Service has any restrictions.

[3]At the time of this writing, the OMG is evaluating submissions for a revised Naming Service. The revised service will define a stringified representation for names.

The name shown in Table 18.1 consists of three components. For all three components, only the id fields are used and the kind fields are the empty string. Another example of a name is shown in Table 18.2.

Table 18.1. A name represented as a table (all kind fields are the empty string).

Table 18.2. A name using both id and kind fields.

This three-component name has a first component with an id field of a/b and a kind field of dir. The second component has the empty string as both the id and the kind fields, and the third component uses ctrl and factory as the values of the id and the kind fields, respectively.

For the remainder of this chapter, we use a typographical convention to represent names. For example, the following is the same name as the one shown in Table 18.1.

user/u1/fred

We use a slash as a separator for name components here; to avoid confusion in our notation, we do not use names that contain slashes themselves (even though it is perfectly legal as far as the Naming Service is concerned).

To show a name that also uses the kind fields, we use the notation

user(dir)/u1(dir)/fred(person)

672

IT-SC book: Advanced CORBA® Programming with C++

This corresponds to the three-component name shown in Table 18.3. Again, to avoid confusion with our separator convention, we do not use id or kind fields that contain parentheses themselves.

Although name components can contain non-printing characters, we recommend that you restrict your names to the same set of characters you would use for file names. This practice will make life easier if you want to use command-line tools or graphical user interfaces to manipulate the naming graph.

Table 18.3. Table representation of the name user(dir)/u1(dir)/fred(person).

18.5.3 Purpose of the kind Field

The kind field of name components can be used to describe the id field in some way. For example, you could use kind values of person, factory, or GIF_Image to classify the object advertised under a name. This idea is similar to that of file name extensions; for example, we frequently use file names such as file.cc and file.o to make the contents of a file obvious by its name.

Many people (including the authors) believe that the distinction between id and kind for name components is a bad idea. For one thing, the analogy with file names does not necessarily hold for object names. Second, even if name components were single strings, we could still use the idea of a name extension by using only the id field and "." as a separator character. As it stands, the Naming Service specification only complicates the type of name components without providing any additional functionality.

However, we must live with this wrinkle of the Naming Service. For your applications, you can choose to ignore the kind fields and always set them to the empty string.

18.5.4 Non-Support for Wide Strings

If you look at the IDL definition of names on page 775, you will find another wrinkle. Note that the IDL contains a type definition for Istring. An Istring is simply an alias for string, so why was this definition added? The reason is historical. At the time the Naming Service was defined, IDL did not provide a wide character type, but it was known that wide characters would be supported in a future version. The Istring definition was added in anticipation of this change. The idea was that by redefining Istring to wstring, the OMG could upgrade the Naming Service to support names containing wide characters.

Unfortunately, this idea does not work. Consider what would happen if the OMG changed Istring to be an alias for wstring now. We would end up with different

673

IT-SC book: Advanced CORBA® Programming with C++

Naming Services coexisting in CORBA. In some services, Istring would be an alias for string, and in others Istring would be an alias for wstring. We would have two different types with the same repository ID. In one service, the repository ID

IDL:omg.org/CosNaming/Istring:1.0

would denote the type string, whereas in another, the same repository ID would denote the type wstring.

We cannot permit this situation because CORBA intimately relies on repository IDs to provide type safety. CORBA makes the assumption that the same repository ID denotes the same type everywhere. If a single repository ID represented different types for different applications in a CORBA system, all type safety and interoperability would be lost. For example, if a client that takes Istring as type string were to send a name component to a server that takes Istring as type wstring, the server's marshaling code would misinterpret 8-bit ISO Latin-1 characters as wide characters. Not only would this lead to incorrect interpretation of the bit pattern of the name component, but it could also cause the server to lose synchronization with IIOP message boundaries. In a poorquality implementation, it could crash the server.

At the time of this writing, there are no plans to upgrade the Naming Service to support wide character names. If such an upgrade is provided in the future, a simple redefinition of Istring to wstring will not work. Instead, it will be necessary to add a new module containing new interfaces that support wide character names.

Upgrading the Naming Service for wide character support is just one example of the more general topic of versioning, a topic we briefly touch on in Section 4.19.3.

18.5.5 Name Equivalence

On page 773, we state that name components must be unique within their parent context. To determine uniqueness, the Naming Service compares both the id and the kind fields. This means that the same context can contain two name components that have the same id value and differ only in the values of their kind fields. Similarly, two name components are considered different if their kind fields are identical but their id fields are different. Formally, name equivalence is defined as follows.

Two name components are equivalent only if they have identical id and kind fields. Two names are equivalent only if all their components are equivalent.

For example, the following four single-component names are different and can all coexist within the same parent context:

Guinness(Beer)

Budweiser(Beer)

Chair(Person)

Chair(Furniture)

674