Previous | Table of Contents | Next |
Object references have at least one tagged profile. Each profile supports one or more protocols and encapsulates all the basic
information the protocols it supports need to identify an object. Any single profile holds enough information to drive a complete
invocation using any of the protocols it supports; the content and structure of those profile entries are wholly specified
by these protocols.
When a specific protocol is used to convey an object reference passed as a parameter in an IDL operation invocation (or reply),
an IOR which reflects, in its contained profiles, the full protocol understanding of the operation client (or server in case
of reply) may be sent. A receiving ORB which operates (based on topology and policy information available to it) on profiles
rather than the received IOR as a whole, to create a derived reference for use in its own domain of reference, is placing
itself as a bridge between reference domains. Interoperability inhibiting situations can arise when an orb sends an IOR with
multiple profiles (using one of its supported protocols) to a receiving orb, and that receiving orb later returns a derived
reference to that object, which has had profiles or profile component data removed or transformed from the original IOR contents.
To assist in classifying behavior of ORBS in such bridging roles, two classes of IOR conformance may be associated with the
conformance requirements for a given ORB interoperability protocol:
• Full IOR conformance requires that an orb which receives an IOR for an object passed to it through that ORB interoperability protocol, shall recover the original IOR, in its entirety, for passing as a reference to that object from that orb through that same protocol
• Limited-Profile IOR conformance requires that an orb which receives an IOR passed to it through a given ORB interoperability protocol, shall recover all of the standard information contained in the IOR profile for that protocol, whenever passing a reference to that object, using that same protocol, to another ORB.
Note – Conformance to IIOP versions 1.0, 1.1 and 1.2 only requires support of limited-Profile IOR conformance, specifically
for the IIOP IOR profile. However, due to interoperability problems induced by Limited-Profile IOR conformance, it is now
deprecated by the CORBA 2.4 specification for an orb to not support Full IOR conformance. Some future IIOP versions could
require Full IOR conformance.
An ORB may be unable to use any of the profiles provided in an IOR for various reasons which may be broadly categorized as
transient ones like temporary network outage, and non-transient ones like unavailability of appropriate protocol software
in the ORB. The decision about the category of outage that causes an ORB to be unable to use any profile from an IOR is left
up to the ORB. At an appropriate point, when an ORB discovers that it is unable to use any profile in an IOR, depending on
whether it considers the reason transient or non-transient, it should raise the standard system exception TRANSIENT with standard
minor code 2, or IMP_LIMIT with the standard minor code 1.
Each profile has a unique numeric tag, assigned by the OMG. The ones defined here are for the IIOP (see
Section 15.7.3, “IIOP IOR Profile Components? on page 15-55)
and for use in “multiple component profiles.? Profile tags in the range 0x80000000 through 0xffffffff are reserved for future
use, and are not currently available for assignment.
Null object references are indicated by an empty set of profiles, and by a “Null? type ID (a string which contains only a
single terminating character). Type IDs may only be “Null? in any message, requiring the client to use existing knowledge
or to consult the object, to determine interface types supported. The type ID is a Repository ID identifying the interface
type, and is provided to allow ORBs to preserve strong typing. This identifier is agreed on within the bridge and, for reasons
outside the scope of this interoperability specification, needs to have a much broader scope to address various problems in
system evolution and maintenance. Type IDs support detection of type equivalence, and in conjunction with an Interface Repository,
allow processes to reason about the relationship of the type of the object referred to and any other type.
The type ID, if provided by the server, indicates the most derived type that the server wishes to publish, at the time the
reference is generated. The object’s actual most derived type may later change to a more derived type. Therefore, the type
ID in the IOR can only be interpreted by the client as a hint that the object supports at least the indicated interface. The
client can succeed in narrowing the reference to the indicated interface, or to one of its base interfaces, based solely on
the type ID in the IOR, but must not fail to narrow the reference without consulting the object via the “_is_a? or “_get_interface?
pseudo-operations.
ORBs claiming to support the Full-IOR conformance are required to preserve all the semantic content of any IOR (including
the ordering of each profile and its components), and may only apply transformations which preserve semantics (e.g., changing
Byte order for encapsulation).
For example, consider an echo operation for object references:
interface Echoer {Object echo(in Object o);};
Assume that the method body implementing this “echo? operation simply returns its argument. When a client application invokes
the echo operation and passes an arbitrary object reference, if both the client and server ORBs claim support to Full IOR
conformance, the reference returned by the operation is guaranteed to have not been semantically altered by either client
or server ORB. That is, all its profiles will remain intact and in the same order as they were present when the reference
was sent. This requirement for ORBs which claim support for Full-IOR conformance, ensures that, for example, a client can
safely store an object reference in a naming service and get that reference back again later without losing information inside
the reference.