What is IIOP

Before diving into IIOP, let me first explain some of the terminology used in this
article.

CORBA is a distributed technology that supports access to remote objects developed

in multiple languages across a variety of platforms. The core of the CORBA
architecture is the Object Request Broker (ORB), which is the object bus. The ORB
allows client applications to find objects and invoke methods on them locally or
across a network. It handles passing requests, responses and exceptions between a
client object and a server object. When the client applications uses an object, it
doesn’t need to know the object’s location, programming language or type of platform
because the ORB masks these details. The ORB handles the location of server objects
in a repository that keeps this level of detail from the client.

Each ORB must define a standard representation for the objects it transmits, the so-
called on-the-wire format. In an ideal world, all ORBs would use the same on-the-
wire format, but this is not how CORBA implementations have evolved. To cope with
this problem, CORBA 2.0 defines a standard format that ORBs can use to exchange
objects: the General Inter-ORB Protocol (GIOP). The Internet Inter-ORB Protocol
(IIOP) in turn specifies how GIOP maps to TCP.

To present things in a different way,

 CORBA is to object oriented computing what the WWW is to documents
 IDL is to CORBA what HTML is to the web
 IIOP is to CORBA what HTTP is to the www
 IOR is to CORBA what URL is to the www
Interoperable object reference

An interoperable object reference (IOR) is the “contact details” that

a client application uses to communicate with a CORBA object.
The interoperable ininteroperable object reference comes about
because an IOR works (or interoperates) across different
implementations of CORBA. For example, an IOR for an object in an
Orbix server can be used by a client that is implemented with, say,
Orbacus, Visibroker, TAO, omniORB or JacORB.
Many people are content to know that object references are
“contact details” for CORBA objects, and they do not seek any
additional information about object references. If you are such a
person then you can skip this chapter. However, CORBA IORs are
remarkably flexible, and this flexibility is fundamental to the
implementation of several other components of CORBA, including
implementation repositories (Chapter 7), messaging (Chapter 16)
and transactions (Chapter 21). Because of this, having an
understanding of the information contained inside object references
makes it much easier to understand other parts of CORBA.
10.2  IDL Definition of an IOR
CORBA uses IDL to define some of its low-level APIs. Because of
this, it is not surprising that the details of an IOR are defined as an
IDL struct, as is shown in Figure 10.1. The contents of
this struct can be explained easily by analogy with a business
card, which—because it also contains “contact details”—is the
business equivalent of an IOR. A sample business card is shown in
Figure 10.2.

Introduction to the CORBA Naming

Service
OrbixNames is IONA Technologies' implementation of the CORBA Naming Service, a
service that allows you to associate abstract names with CORBA objects in your
applications. This chapter describes the features of the CORBA Naming Service.
The Naming Service is a standard service for CORBA applications, defined in the
Object Management Group's (OMG) CORBAservices specification. The Naming
Service allows you to associate abstract names with CORBA objects and allows
clients to find those objects by looking up the corresponding names. This service is
both very simple and very useful.
A server that holds a CORBA object binds a name to the object by contacting the
Naming Service. To obtain a reference to the object, a client requests the Naming
Service to look up the object associated with a specified name. This is known
as resolving the object name. The Naming Service provides interfaces defined in IDL
that allow servers to bind names to objects and clients to resolve those names.
Most CORBA applications make some use of the Naming Service. Locating a
particular object is a common requirement in distributed systems and the Naming
Service provides a simple, standard way to do this.
The Interface to the Naming Service
The Naming Service maintains a database of names and the objects associated with
them. An association between a name and an object is called a binding. The IDL
interfaces to the Naming Service provide operations to access the database of
bindings. For example, you can create new bindings, resolve names, and delete
existing bindings.
OrbixNames is implemented as a normal Orbix server. This server contains objects
which support the standard IDL interfaces to the Naming Service. These interfaces are
defined in the IDL moduleCosNaming:
// IDL
module CosNaming {
  // Naming Service IDL definitions.
  ...
};
Part V of this guide on page 147 provides a full reference for the definitions in this
module. The remainder of this chapter provides a brief overview of the most
commonly used definitions.
Format of Names in the Naming Service
In the CORBA Naming Service, names can be associated with two types of object:
a naming context or an application object. A naming context is an object in the
Naming Service within which you can resolve the names of other objects.
Naming contexts are organized into a naming graph, which may form a naming
hierarchy much like that of a filing system. Using this analogy, a name bound to a
naming context would correspond to a directory and a name bound to an application
object would correspond to a file.
The full name of an object, including all the associated naming contexts, is known as
a compound name. The first component of a compound name gives the name of a
naming context, in which the second component is accessed. This process continues
until the last component of the compound name has been reached.
The notion of a compound name is common in filing systems. For example, in UNIX,
compound names take the form /aaa/bbb/ccc; in Windows they take the
form C:\aaa\bbb\ccc. A compound name in the Naming Service takes a more abstract
form: an IDL sequence of name components.
Name components are not simple strings. Instead, a name component is defined as an
IDL structure, of type CosNaming::NameComponent, that holds two strings:
// IDL
// In module CosNaming.
typedef string Istring;

struct NameComponent {
  Istring id;
  Istring kind;
};
A name is a sequence of these structures:
typedef sequence<NameComponent> Name;
The id member of a NameComponent is a simple identifier for the object;
the kind member is a secondary way to differentiate objects and is intended to be used
by the application layer. For example, you could use the kind member to distinguish
the type of the object being referred to. The semantics you choose for this member are
not interpreted by OrbixNames.
Both the id and kind members of a NameComponent are used in name resolution. Two
names that differ only in the kind member of one NameComponent are considered to be
different names.
IDL Interfaces to the Naming Service
The IDL module CosNaming contains two interfaces that allow your applications to
access the Naming Service:
NamingContext Provides the operations that allow you to access the main features of the Naming
Service, such as binding and resolving names.

BindingIterator Allows you to read each element in a list of bindings. Such a list may be returned by
operations of the NamingContext interface.

The remainder of this chapter describes how you use the NamingContext interface to do

simple Naming Service operations, such as binding names to your application objects
and resolving those names in your clients.
Using the Naming Service
The first step in using the Naming Service is to get a reference to the root naming
context. The root naming context is an object, of type CosNaming::NamingContext,
which acts as an entry point to all the bindings in the Naming Service.
This section describes some of the operations you can call on the root naming context,
or other naming contexts created by you, to do basic Naming Service tasks.
Associating a Name with an Object
The operation CosNaming::NamingContext::bind() allows you to bind a name to an
object in your application. This operation is defined as:
void bind (in Name n, in Object o)
  raises (NotFound, CannotProceed,
   InvalidName, AlreadyBound);
To use this operation, you first create a CosNaming::Name structure containing the name
you want to bind to your object. You then pass this structure and the corresponding
object reference as parameters to bind().
Using Names to Find Objects
Given an abstract name for an object, you can retrieve a reference to the object by
calling CosNaming::NamingContext::resolve(). This operation is defined as:
Object resolve (in Name n)
  raises (NotFound, CannotProceed, InvalidName);
When you call resolve(), the Naming Service retrieves the object reference
associated with the specified CosNaming::Name value and returns it to your application.