[Up: Object Request Broker]
[Previous: Interface Definition] [Next: Invocation]

Addressing

In order to access a remote object, a client first needs the servant's address. This information is contained in object references. While in older revisions the handling of object references was an implementation detail, they have been standardized in CORBA 2.0 in a successful effort to strive for interoperability among different ORBs. These Interoperable Object References (IOR) are opaque to the developer: no information can be extracted from an IOR, and neither can an IOR be composed from known components.

It is important to note that the lifetime of an object reference is independent of the lifetime of its server. A servant is not notified of the creation or destruction of its object references (see the ``Pacific Ocean'' problem in [15]), and a client does not have a means of checking if the server is running save by performing an invocation - which will fail if the server is down and cannot be restarted.

Although the knowledge of a running server might be thought important to the clients, this inability is quite intentional, as it allows a transparent restart of the server without a client noticing. A server might be temporarily shut down to conserve resources or for replacement, and later be restarted on demand. Clients continuously asking ``are you asleep yet'' would permanently prevent a server from shutting down.

The information whether a server is still active is useless anyway, as such information would always be old: during the time it takes to receive the reply, the server could crash or be stopped just as well.

Even though the Internet is today's most common CORBA environment, other means of transport are allowed, too. Object references contain one or more profiles, each one an appropriate identifier to locate the object's implementation - the Internet-specific IIOP (Internet Inter-ORB protocol) profile is but one option.

An object reference with more than one profile can make sense for redundancy purposes (two profiles can point to mirrored objects on different hosts), for quality of service purposes (one preferred profile for encrypted transport) or for optimization (one profile for local interprocess transport if the server is on the same host as the client, and another profile for remote transport).

To learn which information is contained in an object reference, it is useful to write down a formal definition of an IOR. An IOR \( I=(t,\{p_{i}\}) \) is a two-tuple with an optional IDL-declared type \( t \) and a set of profiles \( p_{i} \). Profiles have different layouts; as an example, an IIOP profile \( P_{IIOP}=(v,h,n,k,o) \) can be further decomposed into five components, one fixed IIOP revision number \( v \) (at the moment of writing, 1.2), the Internet host name (or dotted decimal IP address) \( h \), a TCP port number \( n \) that the server is listening on, a server-specific opaque object key \( k \) and optional ``tagged components'' \( o \)3.2.

Figure 3.3: Stringified Interoperable Object Reference
\begin{figure} \hrule\vspace{3mm} \par\verbatiminput{include/ior-example.txt}\par\hrule\par\end{figure}

Figure 3.4: Contents of the Object Reference shown in Figure 3.3
\begin{figure} \hrule\vspace{3mm} \par\verbatiminput{include/iordump.txt}\par\hrule\par\end{figure}

Their opaque nature poses a bootstrap problem for a client, which must acquire an object reference, but cannot compose one by itself. One solution is the exchange of stringified object references, which are more or less a hex dump of the opaque data. The servant generates an object reference to itself, and writes its stringification into a file, which can be either on a shared volume or manually transported to the client using e-mail, networked file transfer or a sneakers network. The client then reads the file and uses the inverse transformation to receive the original object reference. A sample stringified IOR is shown in figure 3.3, and figure 3.4 displays the contents of that object reference, interpreted and made visible using a special iordump tool.

This way of bootstrapping using ``unreadable'' strings is rather ineffective, especially if not only one, but many object references must be exchanged. The Naming Service, one of the aforementioned common object services, has been introduced to reduce this problem. Servers can register their objects with the Naming Service, where they can be retrieved by the client using a more natural name. Yet servers and clients still need an object reference to the Naming Service itself.

Unfortunately, this common problem and frequently asked question of bootstrapping has not been answered satisfactorily until recently. CORBA 2.3 will introduce a new, more ``human-readable'' form of object references as part of the Interoperable Naming Service specification [24] that follows the same syntax as the common Uniform Resource Identifiers of the World Wide Web [5], while being limited to objects with only IIOP profiles.

As seen in the formal definition above, the minimal IOR consists of three parts: a host name and a port number as part of the IIOP profile, and a server-selected object key - the version number can be fixed, and both the type information and the tagged components are optional. So the new scheme for IIOP-based object references consists of these three parts written in plain text:

iioploc://<hostname:port>/NameService

While this notation is useful and convenient, it already requires careful handling of the object key by the object adapter, which should allow for sensible object keys as not to thwart this new scheme with illegible object keys.

An object reference, be it Internet-based or not, need not be final: GIOP (see section 3.4) allows request forwarding, where an address does not point to the actual servant, but to a forwarding service. This may be useful if the server may change its location (for example, if it is shut down to save resources or for replacement and then started again), as long as the forwarding service keeps running.

In response to frequently used terminology, it should be noted that there are no ``persistent'' or ``transient'' object references, as mentioned in some literature or in Internet discussions. There is only one kind of object reference, and while they may point to persistent or transient objects,3.3 this cannot be determined from the reference without internal knowledge of the server-side ORB. Some ORBs indeed use specific tags in references to persistent or transient objects and use the information for internal purposes, but the client does not know.

[Previous: Interface Definition] [Next: Invocation]
[Up: Object Request Broker]

Frank Pilhofer
1999-06-23