Object Reference Semantics

Object references are analogous to C++ class instance pointers but can denote objects implemented in different processes (possibly on other machines) as well as objects implemented in the client's own address space. Except for this distributed addressing capability, object references have semantics much like ordinary C++ class instance pointers have.

Every object reference identifies exactly one object instance. Several different references can denote the same object. References can be nil (point nowhere).

References can dangle (like C++ pointers that point at deleted instances). References are opaque (the client is not allowed to look at their contents). References are strongly typed.

References support late binding. References can be persistent. References can be interoperable.

These points deserve further explanation because they are central to the CORBA object model.

Each reference identifies exactly one object.

Just as a C++ class instance pointer identifies exactly one object instance, an object reference denotes exactly one CORBA object (which may be implemented in a remote address space). A client holding an object reference is entitled to expect that the reference will always denote the same object while the object continues to exist. An object reference is allowed to stop working only when its target object is permanently destroyed. After an object is destroyed, its references become permanently non-functional. This means that a reference to a destroyed object cannot accidentally denote some other object later.

An object can have several references.

Several different references can denote the same object. In other words, each reference "names" exactly one object, but an object is allowed to have several names.

If you find this strange, remember that the same thing can happen in C++. A C++ class instance pointer denotes exactly one object, and the pointer value (such as 0x48bf0) identifies that object. However, as shown in [15], multiple inheritance can cause a single C++ instance to have as many as five different pointer values.

The situation is similar in CORBA. If two object references have different contents, it does not necessarily mean that the two references denote different objects. It follows that an object reference is not the same as an object's identity. This has profound implications for the design of object systems, and we explore some of these implications in Sections 7.11.3 and 20.3.2.

References can be nil.

CORBA defines a distinguished nil value for object references. A nil reference points nowhere and is analogous to a C++ null pointer. Nil references are useful for conveying "not found" or "not there" semantics. For example, an operation can return a nil reference to indicate that a client's search for an object did not locate a matching instance. Nil references can also be used to implement optional reference parameters. Passing a nil value at run time indicates that the parameter is "not there."

References can dangle.

After a server has passed an object reference to a client, that reference is permanently out of the server's control and can propagate freely via means invisible to the ORB (for example, as a string carried by e-mail). This means that CORBA has no built-in automatic mechanism for the server to inform a client when the object belonging to a reference is destroyed. Similarly, there is no built-in automatic way for a client to inform a server that it has lost interest in an object reference. This does not mean that you cannot create such semantics if your application requires them; it means only that CORBA does not provide these semantics as built-in features.

To find out whether an object reference still denotes an existing object, a client can invoke the non_existent operation, which is supported by all objects.

References are opaque.

Object references contain a number of standardized components that are the same for all ORBs as well as proprietary information that is ORB-specific. To permit source code compatibility across different ORBs, clients and servers are not allowed to see the

representation of an object reference. Instead, they must treat an object reference as a black box that can be manipulated only through a standardized interface.

The encapsulation of object references is a key aspect of CORBA. It lets you add new features, such as different communication protocols, over time without breaking existing source code. In addition, vendors can use the proprietary part of object references to provide value-added features, such as performance optimizations, without compromising interoperability with other ORBs.

References are strongly typed.

Every object reference contains an indication of the interface supported by that reference. This arrangement allows the ORB run time to enforce type safety. For example, an attempt to send a print message to an Employee object (which does not support that operation) is caught at run time.

For statically typed languages such as C++, type safety is also enforced at compile time. The language mapping does not permit you to invoke an operation unless the target object is guaranteed to offer that operation in its interface. (This is true only if you are using the generated stubs to invoke operations. If you are using the Dynamic Invocation Interface, static type safety is necessarily lost.)

References support late binding.

Clients can treat a reference to a derived object as if it were a reference to a base object. For example, assume that the Manager interface is derived from Employee. A client may actually hold a reference to a Manager but may think of that reference as being of type Employee. As in C++, a client cannot invoke Manager operations via an

Employee reference (because that would violate static type safety). However, if a client invokes the number operation via the Employee reference, the corresponding message is still sent to the Manager servant that implements the Employee interface.

This arrangement is exactly analogous to C++ virtual function calls: invoking a method via a base pointer calls the virtual function in the derived instance. One of the major advantages of CORBA, compared with traditional RPC platforms, is that polymorphism and late binding work for remote objects exactly as they do for local C++ objects. This means that there is no artificial wall through your architecture in which you must map an object-oriented design onto a remote procedure call paradigm. Instead, polymorphism works transparently across the wire.

References can be persistent.

Clients and servers can convert an object reference into a string and write the string to disk. Sometime later, that string can be converted back into an object reference that denotes the same original object.

References can be interoperable.

CORBA specifies a standard format for object references. This means that one ORB can use references created by a different vendor's ORB, whether they are exchanged as parameters or as strings. For that reason, these standard object references are also known as Interoperable Object References, as we explained in Section 2.4.6.

Note that in addition to the standard IOR format, an ORB can provide proprietary reference encodings. This capability can be useful if an ORB is tailored for a particular environment, such as an object-oriented database. However, proprietary references cannot be exchanged with ORBs from a different vendor.