Previous Up Next

Chapter 10  Interoperable Object Reference (IOR)

10.1  Introduction

An interoperable object reference (IOR) is the “contact details” that a client application uses to communicate with a CORBA object. The interoperable in interoperable 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.


module IOP {
    typedef unsigned long ProfileId;
    const ProfileId TAG_INTERNET_IOP = 0;
    struct TaggedProfile {
        ProfileId        tag;
        sequence<octet>  profile_data;
    };
    struct IOR {
        string                   type_id;
        sequence<TaggedProfile>  profiles;
    };
    ...
};
Figure 10.1: IDL definition of an IOR (interoperable object reference)
Figure 10.2: Example of a business card

The type_id field of the IOR struct contains the object’s repository id (Section 9.4). The equivalent of the type_id on a business card is the job title, such, as senior consultant, sales person, director or software engineer.

The other field in an IOR is a sequence of TaggedProfile. The name of this type is not very intuitive, so it deserves some explanation. Profile is the contact details expressed as binary data (a sequence<octet>)1 and a tag tells us how to interpret that binary data. An analogy of a profile in the business card is the number 555–493–687. To make sense of this number, you need to look at its tag to find out that it is a telephone number rather than, say, a fax number. The OMG-defined tag value TAG_INTERNET_IOP specifies that the binary data provides IIOP2 contact details, and another set of IDL type definitions (which are discussed in Section 10.2.2) define the layout of the binary data. The tagged-profile approach to specifying contact details provides some future-proofing. For example, if the popularity of TCP/IP declines in the future when another transport mechanism is invented then the OMG can define a new tagged-profile format to support that transport mechanism. Furthermore, CORBA vendors can define their own proprietary tagged profiles. For example, CORBA has not yet standardized on a way of communicating using shared memory or wireless networks, but several CORBA vendors have defined their own proprietary protocols for these purposes.

An IOR contains a sequence of tagged profiles. This means that an IOR can list several sets of contact details. For example, perhaps one set of contact details is for a proprietary shared-memory protocol and another is for the CORBA-compliant IIOP protocol. When a client that is built with the same CORBA vendor’s product uses the IOR, it will choose one of the profiles (probably the first one it finds). When a client that is built with a different CORBA vendor’s product tries to use the IOR, the client ignores the shared-memory profile because it does not recognize the proprietary tag value and instead uses the IIOP profile. An IOR that contains several profiles—for different transport mechanisms—is analogous to a business card that lists several sets of contact details, such as a telephone number, fax number, email address and postal address.

An IOR could contain several profiles, all of which use the same underlying transport mechanism. For example, an IOR could contain 3 or 4 different sets of IIOP contact details. This could be used to provide load balancing or fault tolerance. It is important to note that CORBA allows this flexibility but does not require that a CORBA vendor exploit it. Many CORBA products embed just a single set of contact details in IORs. A few CORBA products provide load balancing and fault tolerant capabilities that are based on IORs containing several profiles. Whether a server exports single-profile or multi-profile IORs does not affect interoperability with clients.

10.2.1  Space Optimization

There is one interesting way in which the analogy between an IOR and a business card falls down. A business card typically has the person’s name—in other words, his or her (hopefully unique) identity—written on it exactly once. A CORBA object has an identity that is unique within a server process. This identity is called its object key. The object key information is embedded inside the tagged profile information. Because of this, if an IOR contains several tagged profiles then the object key information may be repeated several times—once inside each and every tagged profile. However, the TaggedComponent mechanism (discussed in Section 10.2.3) provides an optional space optimization that allows a single profile to contain one object key and several sets of (host, port) tuples.

10.2.2  IIOP Contact Details

One issue that has not been discussed yet is this: what do the contact details inside an IOR look like? In practice, most IORs contain a single profile (set of contact details) for the IIOP protocol. Figure 10.3 shows the information stored in an IIOP profile. The GIOP marshaling rules (Section 11.2) are used to marshal an IIOP profile into a binary buffer. This binary buffer is then stored in the sequence<octet> data of a TaggedProfile.3


module IOP {
    typedef unsigned long ComponentId;
    struct TaggedComponent {
        ComponentId      tag;
        sequence<octet>  component_data;
    };
    ...
};
module IIOP {
    struct Version {
        octet  major;
        octet  minor;
    };
    struct ProfileBody_1_1 { // also used for 1.2 and 1.3
        Version                         iiop_version;
        string                          host;
        unsigned short                  port;
        sequence<octet>                 object_key;
        // added in 1.1; unchanged for 1.2 and 1.3
        sequence<IOP::TaggedComponent>  components;
    };
    ...
};
Figure 10.3: IDL definition of an IIOP Profile in an IOR

As can be seen, an IIOP profile contains the host and port at which a client can connect to the server process. A server process might contain several objects, so the object_key is used to identify exactly one object within the server process. The reason for the presence of the TaggedComponent entries will be discussed in Section 10.2.3.

When a client wants to make a call upon an object by using its IOR, the client application opens a TCP/IP socket connection to the host and port specified in the IOR. It then sends the request. The header of the request specifies the object key of the target object and the name of the operation being invoked. The CORBA runtime system within the server application uses this header information to find the correct servant (Section 5.2) and to call the appropriate operation upon that servant.

10.2.3  The use of TaggedComponent entries in an IOR

An IIOP profile (Figure 10.3) contains a sequence<TaggedComponent>. A TaggedComponent consists of binary data (a sequence<octet>), and a tag tells us how to interpret that binary data. The OMG has defined over 30 different types of TaggedComponent so far, which are used to specify additional information about an object reference, such as:

10.3  Proxy

The IOR structure (Figure 10.1) contains the contact details for a CORBA object. However, it does not specify the signatures for operations that may be invoked upon the object. A proxy is a C++/Java/whatever-language-you-are-using object “wrapper” around the IOR and it provides the signatures of the IDL operations for the remote CORBA object. When a client application invokes an operation on a proxy, the proxy marshals (Section 11.2) the in/inout parameters into a binary buffer and then transmits this request using the contact details specified in the IOR. The proxy waits to receive a reply message, unmarshals the out/inout parameters and return value and then returns these to the calling code.

The previous paragraph explained that a proxy is a wrapper around an IOR. However, the distinction between an IOR and a wrapper around an IOR is often irrelevant. Because of this, the term proxy is often used as a synonym for an IOR.

1
An octet is the built-in IDL type that denotes a byte of raw data.
2
IIOP (Internet Inter-ORB Protocol) is the CORBA protocol for communication on TCP/IP networks. CORBA protocols are discussed in Chapter 11.
3
CORBA uses the term encapsulation to refer to marshaling one type into a binary buffer and then storing this in a sequence<octet>.
Previous Up Next