Previous | Table of Contents | Next |
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
CORBA | COM | ||||
TypeCode | TYPEDESC | ||||
Repository | |||||
ModuleDef | ITypeLib | ||||
InterfaceDef | ITypeInfo | ||||
AttributeDef | VARDESC | ||||
OperationDef | FUNCDESC | ||||
ParameterDef | ELEMDESC | ||||
TypeDef | ITypeInfo | ||||
ConstantDef | VARDESC | ||||
ExceptionDef |
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.