Java Programming with CORBA

Read an Excerpt

Chapter 8: Discovering Services

This chapter provides an overview of mechanisms for discovering CORBA objects. We explain the two most important CORBA Services for locating objects: the Naming Service (section 2), which finds objects by name, and the Trading Service (section 3), which finds objects by type and properties. However, there is still the question of how to find initial references to instances of those services. In section 1, we explain the operations on the ORB pseudo-interface which can be used for bootstrapping.

In section 4, Naming and Trading domains are introduced. This section discusses which object instance is returned by the bootstrapping operations.

Finally, section 5 explains how ORBs name and locate servers and objects by using proprietary mechanisms. Although these mechanisms are not standardized, and hence not portable or interoperable, they are quite popular due to their simplicity.

1 Bootstrapping

CORBA solves the bootstrapping problem by providing a pair of operations on the ORB pseudo-interface:

(a) list_initial_services()-list the names of initial services which are available from the ORB.

(b) resolve_initial_references()-returns an initial object reference to a named service. For example, a naming context is returned when a Naming Service reference is requested.

We introduced these operations in Chapter 2 and explained their Java mapping in Chapter 7. We show how to use these operations in the Naming Service example in the following section.

These two operations only provide a bootstrapping mechanism for the services offered by a particular ORB implementation because the mechanism for registering serviceswith the ORB is not defined by CORBA. However, the standard interface to the ORB ensures the portability of application code.

Furthermore, these two operations do not provide full bootstrap support. The problem is that it is not clear which object instance will be returned when several are available. We discuss this problem in more detail in section 4 where we introduce the concept of domains as a solution.

An alternative way to bootstrap applications is to use proprietary mechanisms provided by various ORB implementations. We have a closer look at some of the options in section 5.

2 The CORBA Naming Service

The Naming Service allows object implementations to be identified by name and is thus a fundamental service for distributed object systems. This section is organized as follows:

(a) We give an overview and explain how to use the Naming Service (section 2.1).

(b) We explain the interface specification in detail (section 2.2).

(c) We provide an example (section 2.3).

2.1 Overview of the Naming Service

The Naming Service provides a mapping between a name and an object reference. Storing such a mapping in the Naming Service is known as binding an object and removing this entry is called unbinding. Obtaining an object reference which is bound to a name is known as resolving the name.

Names can be hierarchically structured by using contexts. Contexts are similar to directories in file systems and they can contain name bindings as well as subcontexts.

The use of object references alone to identify objects has two problems for human users, because First, object references are opaque data types, and second, their string form is a long sequence of numbers. When a service is restarted, its objects typically have new object references. However, in most cases clients want to use the service repeatedly without needing to be aware that the service has been restarted.

The Naming Service solves these problems by providing an extra layer of abstraction for the identification of objects. It provides Readable object identifiers for the human user-Users can assign names that look like structured file names-A persistent identification mechanism. Objects can bind themselves under the same name regardless of their object reference.

The typical use of the Naming Service involves object implementations binding to the Naming Service when they come into existence and unbinding before they terminate. Clients resolve names to objects, on which they subsequently invoke operations. Figure 8.1 illustrates this typical usage scenario.

2.2 Interface Specification

The central interface is called NamingContext and it contains operations to bind names to object references and to create subcontexts. Names are sequences of NameComponents. NamingContexts can resolve a name with a single component and return an object reference. They resolve names with more than one component by resolving the first component to a subcontext and passing the remainder of a name to that subcontext for resolution.

2.2.1 The Name Type

The CosNaming module provides type definitions used to identify objects by names:

module CosNaming {typedef string Istring;struct NameComponent
{Istring id;Istring kind;};

typedef sequence <NameComponent> Name;

Read More