18.3.12 Mapping for Read-Write Attributes

   In Microsoft ODL, an attribute preceded by the keyword [propput] is interpreted as only supporting an accessor function that is used to set the value of the attribute. In the previous example, the attribute Profile is mapped to the following statements in OMG IDL.

   // OMG IDL

   struct CustomerData{CustomerId Id;string Name;

   string SurName;

   };

   interface Customer{attribute CustomerData Profile;...};

   Since CORBA does not have the concept of write-only attributes, the mapping must assume that a property that has the keyword [propput] is mapped to a single read-write attribute, even if there is no associated [propget] method defined.

   18.3.12.1 Inheritance Mapping

   Both CORBA and COM have similar models for individual interfaces. However, the models for inheritance and multiple interfaces are different.

   In CORBA, an interface can singly or multiply inherit from other interfaces, and in language bindings supporting typed object references, widening and narrowing support convert object references as allowed by the true type of that object.

   However, there is no built-in mechanism in CORBA to access interfaces without an inheritance relationship. The run-time interfaces of an object (for example, CORBA::Object::is_a, CORBA::Object::get_interface) use a description of the object’s principle type, which is defined in OMG IDL. In terms of implementation, CORBA allows many ways in which implementations of interfaces can be structured, including using implementation inheritance.

   In COM V2.0, interfaces can have single inheritance. However, as opposed to CORBA, there is a standard mechanism by which an object can have multiple interfaces (without an inheritance relationship between those interfaces) and by which clients can query for these at run-time. (It defines no common way to determine if two interface references refer to the same object, or to enumerate all the interfaces supported by an entity.)

   An observation about COM is that some COM objects have a required minimum set of interfaces that they must support. This type of statically-defined interface relation is conceptually equivalent to multiple inheritance; however, discovering this relationship is only possible if ODL or type libraries are always available for an object.

   COM describes two main implementation techniques: aggregation and delegation. C++ style implementation inheritance is not possible.

   When COM interfaces are mapped into CORBA, their inheritance hierarchy (which can only consist of single inheritance) is directly mapped into the equivalent OMG IDL inheritance hierarchy.2

   2. This mapping fails in some cases, for example, if operation names are the same.

   Note that although it is possible, using Microsoft ODL to map multiple COM interfaces in a class to OMG IDL multiple inheritance, the necessary information is not available for interfaces defined in Microsoft IDL. As such, this specification does not define a multiple COM interface to OMG IDL multiple inheritance mapping. It is assumed that future versions of COM will merge Microsoft ODL and Microsoft IDL, at which time the mapping can be extended to allow for multiple COM interfaces to be mapped to OMG IDL multiple inheritance.

   CORBA::Composite is a general-purpose interface used to provide a standard mechanism for accessing multiple interfaces from a client, even though those interfaces are not related by inheritance. Any existing ORB can support this interface, although in some cases a specialized implementation framework may be desired to take advantage of this interface.

   module CORBA // PIDL

   {

   interface Composite

   {

   Object query_interface(in RepositoryId whichOne);

   };

   interface Composable:Composite

   {

   Composite primary_interface();

   };

   };

   The root of a COM interface inheritance tree, when mapped to CORBA, is multiply-inherited from CORBA::Composable and CosLifeCycle::LifeCycleObject. Note that the IUnknown interface is not surfaced in OMG IDL. Any COM method parameters that require IUnknown interfaces as arguments are mapped, in OMG IDL, to object references of type CORBA::Object.

   // Microsoft IDL or ODLinterface IFoo: IUnknown{HRESULT inquire([in] IUnknown *obj);};

   In OMG IDL, this becomes:

   interface IFoo: CORBA::Composable, CosLifeCycle::LifeCycleObject

   {

   void inquire(in Object obj);

   };

   18.3.12.2 Type Library Mapping

   Name spaces within the OLE Type Library are conceptually similar to CORBA interface repositories. However, the CORBA interface repository looks, to the client, to be one unified service. Type libraries, on the other hand, are each stored in a separate file. Clients do not have a unified, hierarchical interface to type libraries.

   The following table defines the mapping between equivalent CORBA and COM interface description concepts. Where there is no equivalent, the field is left blank.

   Table 18-12CORBA Interface Repository to OLE Type Library Mappings

   Using this mapping, implementations must provide the ability to call Object::get_interface on CORBA object references to COM objects to retrieve an InterfaceDef. When CORBA objects are accessed from COM, implementations may provide the ability to retrieve the ITypeInfo for CORBA object interface using the IProvideClassInfo COM interface.