Previous Table of Contents Next


17.5.4 Mapping Interface Identity


   This specification enables interworking solutions from different vendors to interoperate across client/server boundaries (for example, a COM View created by product A can invoke a CORBA server created with product B, given that they both share the same IDL interface). To interoperate in this way, all COM Views mapped from a particular CORBA interface must share the same COM Interface IDs. This section describes a uniform mapping from CORBA Interface Repository IDs to COM Interface IDs.

   17.5.4.1 Mapping Interface Repository IDs to COM IIDs

   A CORBA Repository ID is mapped to a corresponding COM Interface ID using a derivative of the RSA Data Security, Inc. MD5 Message-Digest algorithm.4,5 The repository ID of the CORBA interface is fed into the MD5 algorithm to produce a 128bit hash identifier. The least significant byte is byte 0 and the most significant byte is byte 8. The resulting 128 bits are modified as follows.

   Note – The DCE UUID space is currently divided into four main groups:byte 8 = 0xxxxxxx (the NCS1.4 name space)10xxxxxx (A DCE 1.0 UUID name space)110xxxxx (used by Microsoft)1111xxxx (Unspecified)

   For NCS1.5, the other bits in byte 8 specify a particular family. Family 29 will be assigned to ensure that the autogenerated IIDs do not interfere with other UUID generation techniques.

   The upper two bits of byte 9 will be defined as follows.

   00 unspecified01 generated COM IID10 generated Automation IID11 generated dual interface Automation ID

   Note – These bits should never be used to determine the type of interface. They are used only to avoid collisions in the name spaces when generating IIDs for multiple types of interfaces — dual, COM, or Automation.

   The other bits in the resulting key are taken from the MD5 message digest (stored in the UUID with little endian ordering).

   The IID generated from the CORBA repository ID will be used for a COM view of a CORBA interface except when the repository ID is a DCE UUID and the IID being generated is for a COM interface (not Automation or dual). In this case, the DCE UUID will be used as the IID instead of the IID generated from the repository ID (this is done to allow CORBA server developers to implement existing COM interfaces).

   This mechanism requires no change to IDL. However, there is an implicit assumption that repository IDs should be unique across ORBs for different interfaces and identical across ORBs for the same interface.

   Note – This assumption is also necessary for IIOP to function correctly across ORBs.

   4. Rivest, R. “The MD5 Message-Digest Algorithm,? RFC 1321, MIT and RSA Data Security, Inc., April 1992.

   July 2002 CORBA, v3.0: Interface Composition Mappings

   17.5.4.2 Mapping COM IIDs to CORBA Interface IDs

   The mapping of a COM IID to the CORBA interface ID is vendor-specific. However, the mapping should be the same as if the CORBA mapping of the COM interface were defined with the #pragma ID <interface_name> = “DCE:...?.

   Thus, the MIDL definition

   [uuid(f4f2f07c-3a95-11cf-affb-08000970dac7), object]interface A: IUnknown {...}

   maps to this OMG IDL definition:

   interface A {#pragma ID A=?DCE:f4f2f07c-3a95-11cf-affb-08000970dac7?...};