Issue 6391: Interface Introspection (corba-rtf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: 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 { // PIDL ... other operations ... FullInterfaceDescription get_interface_def (); }; }; 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 { ... other operations ... virtual CORBA::FullInterfaceDescription_ptr _get_interface_def (); }; } 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. Resolution: Revised Text: Actions taken: October 27, 2003: received issue April 11, 2012: Deferred Discussion: End of Annotations:===== te: Mon, 27 Oct 2003 21:42:42 -0500 From: Frank Pilhofer To: issues@omg.org Cc: corba-rtf@omg.org Subject: Interface Introspection Reply-To: Frank Pilhofer User-Agent: Mutt/1.2.5i 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 { // PIDL ... other operations ... FullInterfaceDescription get_interface_def (); }; }; 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 { ... other operations ... virtual CORBA::FullInterfaceDescription_ptr _get_interface_def (); }; } 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. Have fun, Frank -- Frank Pilhofer ........................................... fp@fpx.de Too often, people who want to offer sound advice give us more sound than advice. - Alfred E. Neuman