| Previous | Table of Contents | Next |
The intent of this specification is to allow the construction of implementations that fit
in the design space described in Section 17.2, “Interworking Object Model,? on
page 17-3, and yet guarantee interface uniformity among implementations with similar
or overlapping design centers. This goal is achieved by the following compliance statements:
• When a product offers the mapping of CORBA interfaces onto isomorphic COM and/or Automation interfaces, the mapping of COM and/or Automation interfaces onto isomorphic CORBA interfaces, or when a product offers the ability to automatically generate components that perform such mappings, then the product must use the interface mappings defined in this specification. Note that products may offer custom, nonisomorphic interfaces that delegate some or all of their behavior to CORBA, COM, or Automation objects. These interfaces are not in the scope of this specification, and are neither compliant nor noncompliant.
• Interworking solutions that expose COM Views of CORBA objects are required to expose the CORBA-specific COM interfaces ICORBAObject and IORBObject, defined in Section 17.7.5, “ICORBAObject Interface,? on page 17-27 and Section 17.7.7, “IORBObject Interface,? on page 17-28, respectively.
• Interworking solutions that expose Automation Views of CORBA objects are required to expose the CORBA-specific Automation Dual interfaces DICORBAObject and DIORBObject, defined in Section 17.7.5, “ICORBAObject Interface,? on page 17-27 and Section 17.7.7, “IORBObject Interface,? on page 17-28, respectively.
• OMG IDL interfaces exposed as COM or Automation Views are not required to provide type library and registration information in the COM client environment where the interface is to be used. If such information is provided; however, then it must be provided in the prescribed manner.
• Each COM and Automation View must map onto one and only one CORBA object reference, and must also expose the IForeignObject interface, described in Section 17.7.4, “IForeignObject Interface,? on page 17-26. This constraint guarantees the ability to obtain an unambiguous CORBA object reference from any COM or Automation View via the IForeignObject interface.
• If COM or Automation Views expose the IMonikerProvider interface, they shall do so as specified in Section 17.7.2, “IMonikerProvider Interface and Moniker Use,? on page 17-23.
• All COM interfaces specified in this specification have associated COM Interface IDs. Compliant interworking solutions must use the IIDs specified herein, to allow interoperability between interworking solutions.
• All compliant products that support distributed interworking must support the CORBA Internet Inter-ORB Protocol (IIOP), and use the interoperability architecture described in CORBA in the manner prescribed in Section 17.8, “Distribution,? on page 17-32. Interworking solutions are free to use any additional proprietary or public protocols desired.
• Interworking solutions that expose COM Views of CORBA objects are required to provide the ICORBAFactory object as defined in Section 17.7.3, “ICORBAFactory Interface,? on page 17-24.
• Interworking solutions that expose Automation Views of CORBA objects are required to provide the DICORBAFactory object as defined in Section 17.7.3, “ICORBAFactory Interface,? on page 17-24.
• Interworking solutions that expose CORBA Views of COM or Automation objects are required to derive the CORBA View interfaces from CosLifeCycle::LifeCycleObject as described in CORBA View of COM/Automation Life Cycle, as described under Section 17.6.2, “Binding and Life Cycle,? on page 17-20.