| Previous | Table of Contents | Next |
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. 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, as defined in CORBA (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. 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, which 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.
The mapping for CORBA interfaces into COM is more complicated than COM interfaces into CORBA, since CORBA interfaces might
be multiply-inherited and COM does not support multiple interface inheritance.
If a CORBA interface is singly inherited, this maps directly to single inheritance of interfaces in COM. The base interface
for all CORBA inheritance trees is IUnknown. Note that the Object interface is not surfaced in COM. For single inheritance,
although the most derived interface can be queried using IUnknown::QueryInterface, each individual interface in the inheritance
hierarchy can also be queried separately.
The following rules apply to mapping CORBA to COM inheritance.
• Each OMG IDL interface that does not have a parent is mapped to an MIDL interface deriving from IUnknown.
• Each OMG IDL interface that inherits from a single parent interface is mapped to an MIDL interface that derives from the mapping for the parent interface.
• Each OMG IDL interface that inherits from multiple parent interfaces is mapped to an MIDL interface deriving from IUnknown.
• For each CORBA interface, the mapping for operations precede the mapping for attributes.
• Operations are sorted in ascending order based upon the ISO Latin-1 encoding values of the respective operation names.
• The resulting mapping of attributes within an interface are ordered based upon the attribute name. The attributes are similarly sorted in ascending order based upon the ISO-Latin-1 encoding values of the respective attribute names. If the attribute is not readonly, the get_<attribute name> method immediately precedes the set_<attribute name> method.
CORBA Interface Inheritance COM Interface Inheritance
Figure 18-1 CORBA Interface Inheritance to COM Interface Inheritance Mapping
//OMG IDL//interface A {
void opA();
attribute long val; }; interface B : A {
void opB(); }; interface C : A {
void opC(); }; interface D : B, C {
void opD(); }; interface E {
void opE(); }; interface F : D, E {
void opF();
}//Microsoft MIDL//[object, uuid(b97267fa-7855-e044-71fb-12fa8a4c516f)]interface IA: IUnknown{
HRESULT opA();
HRESULT get_val([out] long * val);
HRESULT set_val([in] long val);
};
[object, uuid(fa2452c3-88ed-1c0d-f4d2-fcf91ac4c8c6)]
interface IB: IA {
HRESULT opB();
};
[object,uuid(dc3a6c32-f5a8-d1f8-f8e2-64566f815ed7)]
interface IC: IA {
HRESULT opC();
};
[object, uuid(b718adec-73e0-4ce3-fc72-0dd11a06a308)]
interface ID: IUnknown {
HRESULT opD();
};
[object, uuid(d2cb7bbc-0d23-f34c-7255-d924076e902f)]
interface IE: IUnknown{
HRESULT opE();
};
[object, uuid(de6ee2b5-d856-295a-fd4d-5e3631fbfb93)]
interface IF: IUnknown {
HRESULT opF();};
Note that the co-class statement in Microsoft ODL allows the definition of an object class that allows QueryInterface between
a set of interfaces.
Also note that when the interface defined in OMG IDL is mapped to its corresponding statements in Microsoft IDL, the name
of the interface is proceeded by the letter I to indicate that the name represents the name of an interface. This also makes
the mapping more natural to the COM programmer, since the naming conventions used follow those suggested by Microsoft.