15.7.2 IIOP IOR Profiles

   IIOP profiles, identifying individual objects accessible through the Internet Inter-ORB Protocol, have the following form:

   module IIOP { // IDL extended for version 1.1, 1.2, and 1.3

   struct ProfileBody_1_0 {// renamed from ProfileBody

   Version iiop_version;

   string host;

   unsigned short port;

   sequence <octet> object_key;

   };

   struct ProfileBody_1_1 {// also used for 1.2 and 1.3Version 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; }; };

   IIOP Profile version number:

• Indicates the IIOP protocol version.

• Major number can stay the same if the new changes are backward compatible.

• Clients with lower minor version can attempt to invoke objects with higher minor version number by using only the information defined in the lower minor version protocol (ignore the extra information).

   Profiles supporting only IIOP version 1.0 use the ProfileBody_1_0 structure, while those supporting IIOP version 1.1 or 1.2 or 1.3 use the ProfileBody_1_1 structure. An instance of one of these structure types is marshaled into an encapsulation octet stream. This encapsulation (a sequence <octet>) becomes the profile_data member of the IOP::TaggedProfile structure representing the IIOP profile in an IOR, and the tag has the value TAG_INTERNET_IOP (as defined earlier).

   The version number published in the Tag Internet IIOP Profile body signals the highest GIOP minor version number that the server supports at the time of publication of the IOR.

   If the major revision number is 1, and the minor revision number is greater than 0, then the length of the encapsulated profile may exceed the total size of components defined in this specification for profiles with minor revision number 0. ORBs that support only revision 1.0 IIOP profiles must ignore any data in the profile that occurs after the object_key. If the revision of the profile is 1.0, there shall be no extra data in the profile (i.e., the length of the encapsulated profile must agree with the total size of components defined for version 1.0).

   For Version 1.2 and 1.3 of IIOP, no order of use is prescribed in the case where more than one TAG Internet IOP Profile is present in an IOR.

   The members of IIOP::ProfileBody_1_0 and IOP::ProfileBody_1_1 are defined as follows:

• host identifies the Internet host to which GIOP messages for the specified object may be sent. In order to promote a very large (Internet-wide) scope for the object reference, this will typically be the fully qualified domain name of the host, rather than an unqualified (or partially qualified) name. However, per Internet standards, the host string may also contain a host address expressed in standard “dotted decimal? form (e.g., “192.231.79.52?).

• components is a sequence of TaggedComponent, which contains additional information that may be used in making invocations on the object described by this profile. TaggedComponents that apply to IIOP 1.2 are described below in Section 15.7.3, “IIOP IOR Profile Components,? on page 15-55. Other components may be included to support enhanced versions of IIOP, to support ORB services such as security, and to support other GIOPs, ESIOPs, and proprietary protocols. If an implementation puts a non-standard component in an IOR, it cannot be assured that any or all non-standard components will remain in the IOR.

• iiop_version describes the version of IIOP that the agent at the specified address is prepared to receive. When an agent generates IIOP profiles specifying a particular version, it must be able to accept messages complying with the specified version or any previous minor version (i.e., any smaller version number). The major version number of this specification is 1; the minor versions defined to date are 0, 1, and 2. Compliant ORBs must generate version 1.1 profiles, and must accept any profile with a major version of 1, regardless of the minor version number. If the minor version number is 0, the encapsulation is fully described by the ProfileBody_1_0 structure. If the minor version number is 1 or 2, the encapsulation is fully described by the ProfileBody_1_1 structure. If the minor version number is greater than 2, then the length of the encapsulated profile may exceed the total size of components defined in this specification for profiles with minor version number 1 or 2. ORBs that support only version 1.1 or 1.2 IIOP profiles must ignore, but preserve, any data in the profile that occurs after the components member, for IIOP profiles with minor version greater than 1.2.

Note – As of version 1.2 of GIOP and IIOP and minor versions beyond, the minor version in the TAG_INTERNET_IOP profile signals the highest minor revision of GIOP supported by the server at the time of publication of the IOR.

• port contains the TCP/IP port number (at the specified host) where the target agent is listening for connection requests. The agent must be ready to process IIOP messages on connections accepted at this port.

• object_key is an opaque value supplied by the agent producing the IOR. This value will be used in request messages to identify the object to which the request is directed. An agent that generates an object key value must be able to map the value unambiguously onto the corresponding object when routing requests internally.

   The relationship between the IIOP protocol version and component support

   conformance requirements is as follows:

• Each IIOP version specifies a set of standard components and the conformance rules for that version. These rules specify which components are mandatory and which are optional. A conformant implementation has to conform to these rules, and is not required to conform to more than these rules.

• New components can be added, but they do not become part of the versions conformance rules.

• When there is a need to specify conformance rules that include the new components, there will be a need to create a new IIOP version.

   Note that host addresses are restricted in this version of IIOP to be Class A, B, or C Internet addresses. That is, Class D (multi-cast) addresses are not allowed. Such addresses are reserved for use in future versions of IIOP.

   Agents may freely choose TCP port numbers for communication; IIOP supports multiple agents per host.