This chapter describes the mechanism used by omniORB2 to ensure type safety when object references are exchanged across the network. This mechanism is handled completely within the ORB. There is no programming interface visible at the application level. However, for the sake of diagnosing the problem when there is a type violation, it is useful to understand the underlying mechanism in order to interpret the error conditions reported by the ORB.
In GIOP/IIOP, an object reference is encoded as an Interoperable Object Reference (IOR) when it is sent across a network connection. The IOR contains a Repository ID (REPOID) and one or more communication profiles. The communication profiles describe where and how the object can be contacted. The REPOID is a string which uniquely identifies the IDL interface of the object.
Unless the ID pragma is specified in the IDL, the ORB generates the REPOID string in the so-called OMG IDL Format
. For instance, the REPOID for the Echo interface used in the examples of chapter 2 is IDL:Echo:1.0.
When interface inheritance is used in the IDL, the ORB always sends the REPOID of the most derived interface. For example:
// IDL
interface A {
...
};
interface B : A {
...
};
interface C {
void op(in A arg);
};
// C++
C_ptr server;
B_ptr objB;
A_ptr objA = objB;
server->op(objA); // Send B as A
In the example, the operation C::op accepts an object reference of type A. The real type of the reference passed to C::op is B, which inherits from A. In this case, the REPOID of B, and not that of A, is sent across the network.
The GIOP/IIOP specification allows an ORB to send a null string in the REPOID field of an IOR. It is up to the receiving end to work out the real type of the object. OmniORB2 never sends out null strings as REPOID. However, it may receive null REPOID from other ORBs. In that case, it will use the mechanism described below to ensure type safety.
The ORB is provided with the interface information by the stubs via the proxyObjectFactory class. For an interface A, the stub of A contains a A_proxyObjectFactory class. This class is derived from the proxyObjectFactory class. The proxyObjectFactory is an abstract class which contains 3 virtual functions.
class proxyObjectFactory {
public:
virtual const char *irRepoId() const = 0;
virtual _CORBA_Boolean is_a(const char *base_repoId) const = 0;
virtual CORBA::Object_ptr newProxyObject(Rope *r,
CORBA::Octet *key,
size_t keysize,
IOP::TaggedProfileList
*profiles,
CORBA::Boolean release) = 0;
};
A single instance of every *_proxyObjectFactory is instantiated at runtime. The instances are entered into a list inside the ORB. The list constitutes all the interface information known to the ORB.
When the ORB receives an IOR from the network, it unmarshals and extracts the REPOID from the IOR. At this point, the ORB has two pieces of information in hand:
Using the REPOID received, the ORB searches its proxyObjectFactory list for an exact match. If there is an exact match, all is well because the runtime can use the is_a method of the proxyFactory to check if the expected REPOID is the same as the received REPOID or if it is that of its base interfaces. If the answer is positive, the IOR passes the type checking test and the ORB can proceed to create an object reference in its own address space to represent the IOR.
However, the ORB may fail to find a match in its proxyObjectFactory list. This means that the ORB has no local knowledge of the REPOID. There are three possible causes:
To handle this situation, the ORB must find out the type information dynamically. This is explained in the next section.
When the ORB receives an IOR of interface type B when it expects the type to be A, it must find out if B inherits from A. When the ORB has no local knowledge of the type B, it must work out the type of B dynamically.
The CORBA specification defines an Interface Repository (IR) from which IDL interfaces can be queried dynamically. In the above situation, the ORB could contact the IR to find out the type of B. However, this approach assumes that an IR is always available and contains the up-to-date information of all the interfaces used in the domain. This assumption may not be valid in many applications.
An alternative is to use the _is_a operation to work out the actual type of an object. This approach is simpler and more robust than the previous one because no 3rd party is involved.
class Object{
CORBA::Boolean _is_a(const char* type_id);
};
The _is_a operation is part of the CORBA::Object interface and must be implemented by every object. The input argument is a REPOID. The function returns true(1) if the object is really an instance of that type, including if that type is a base type of the most derived type of that object.
In the situation above, the ORB would invoke the _is_a operation on the object and ask if the object is of type A before it processes any application invocation on the object.
Notice that the _is_a call is not performed when the IOR is unmarshalled. It is performed just prior to the first application invocation on the object. This leads to some interesting failure mode if B reports that it is not an A. Consider the following example:
\\ IDL
interface A { ... };
interface B : A { ... };
interface D { ... };
interface C {
A op1();
Object op2();
};
\\ C++
C_ptr objC;
A_ptr objA;
CORBA::Object_ptr objR;
objA = objC->op1(); // line 1
(void) objA->_non_existent(); // line 2
objR = objC->op2(); // line 3
objA = A::_narrow(objR); // line 4
If the stubs of A,B,C,D are linked into the executable and:
If only the stub of A is linked into the executable and: