Here's a chance to learn more about the details associated with GIOP, IIOP, their respective data formats, and connection semantics.
Take some time to read over chapter thirteen of the CORBA/IIOP specification. You should have already downloaded this document, but in case you have not you can download from the
technical library of the OMG Website.
The profile begins with a tag that identifies it as an IIOP profile. The tag is called TAG_INTERNET_IOP and has the value 0. It is followed by the CDR encapsulation of the profile body. The main pieces of information in the profile body are as follows:
- It begins by giving the version of IIOP supported by this particular object. At the time of this writing, the IIOP version could be 1.0, 1.1, or 1.2.
- The endpoint details, host and port, are given for a listening point on the server where the CORBA object lives. The host is a string that can contain either the server hostname or an IP address in dotted decimal notation.
- An object_key is given in the form of a sequence of octets. The object_key is binary data that uniquely identifies the CORBA object in the address space of the server. The format of the object_key might not be understood by the client, but this does not matter, because the object_key is only interpreted by the server.
- If the version of this IIOP profile is 1.1 or 1.2, the profile may include a series of IOR components. The purpose of these components is to give miscellaneous information that may be needed to use the CORBA object. For example, the CORBA Security Service defines several types of
component to facilitate secure connections to a CORBA object.
The formal CDR encoding of an IIOP profile is defined in Chapter 16. With the details given here,
it is possible to understand the contents of a typical stringified object reference.
