CORBA35 — Interface Introspection

Inspired by a recent paper by Doug Schmidt and Steve Vinoski
and the resulting newsgroup discussion on comp.object.corba,
I have a feature request to introduce a better reflection
mechanism into CORBA.

At the moment, there is the CORBA::Object::get_interface()
operation to access a matching InterfaceDef entry in an
Interface Repository. Since an Interface Repository is
seldomly deployed, using this operation is pretty much
futile and will either return a nil reference or throw
an exception.

Therefore, I propose to add a new get_interface_def()
operation to the Object interface that returns a FullInter-
faceDef structure, as defined by the Interface Repository.
This structure contains all that a dynamic client (such as
the ones proposed by Schmidt&Vinoski, or software like
CorbaScript or Combat) needs to know about an interface.

A new _interface_def pseudo-operation then needs to be added
to GIOP. This could probably be done without a version change,
as no marshalling changes or new messages are involved, it's
just another operation.

On the server side, the IDL compiler would generate a suitable
implementation as part of the skeleton. This implementation
could just contain a binary representation of the FullInterface-
Description structure (just like a "precompiled" TypeCode) that
is dumped to the GIOP stream. (So that you don't need the
Interface Repository IDL around.)

Proposed resolution:

In chapter 4.3, "Object Reference Operations," add the following
operation to the Object interface:

module CORBA {
interface Object

;
};

Add the following explanation to 4.3.1, "Determining the Object
Interface"

4.3.1.2 get_interface_def

FullInterfaceDescription get_interface_def ();

The get_interface_def operation returns a data structure
describing the most derived type of the object addressed by
the reference. The FullInterfaceDescription structure includes
descriptions of all the operations and attributes in the
transitive closure of the inheritance graph of the interface
being described. See the Interface Repository chapter for the
contents of the data structure. Note that if an Interface
Repository is not available, object references contained in
this structure may be nil or inaccessible.

In chapter 15.4.2, "Request Message", update the text that
reads

In the case of CORBA::Object operations that are defined in
the CORBA Core (Section 4.2, "Object Reference Operations,"
on page 4-12) and that correspond to GIOP request messages,
the operation names are _interface, _is_a, _non_existent,
_domain_managers and _component.

to read

In the case of CORBA::Object operations that are defined in
the CORBA Core (Section 4.2, "Object Reference Operations,"
on page 4-12) and that correspond to GIOP request messages,
the operation names are _interface, _is_a, _non_existent,
_domain_managers, _component or _interface_def.

In the C++ language mapping, section 1.37.1, "Mapping of
PortableServer::Servant", add the following operation to
class ServantBase:

namespace PortableServer { // C++
class ServantBase

;
}

Update the paragraph that reads,

ServantBase provides default implementations of the
_get_interface, _is_a and _non_existent object reference
operations [...]

to read

ServantBase provides default implementations of the
_get_interface, _is_a, _non_existent and _get_interface_def
object reference operations [...]

Add a new paragraph,

For static skeletons, the default implementation of the
_get_interface_def function returns information about the
interface associated with the skeleton class. For dynamic
skeletons, the default implementation uses the
_get_interface function to determine its return value.

Other language mappings might need similar updates.

By the way, since FullInterfaceDescription is only used as
a return value, only a pointer to FullInterfaceDescription
is needed. Therefore, you don't need the full Interface
Repository interface descriptions but only a pointer to an
incomplete type.

On the client side, you only need to pull in the Interface
Repository IDL if you are actually calling _get_interface_def.

On the server side, the skeleton can do some ORB-dependent
magic to push a precompiled binary data structure into the
result.