17.7.3 ICORBAFactory Interface

   All interworking solutions that expose COM Views of CORBA objects shall expose the ICORBAFactory interface. This interface is designed to support general, simple mechanisms for creating new CORBA object instances and binding to existing CORBA object references by name.

   interface ICORBAFactory: IUnknown {HRESULT CreateObject( [in] LPWSTR factoryName, [out, retval] IUknown ** val);HRESULT GetObject([in] LPWSTR objectName, [out, retval] IUknown ** val);}

   The UUID for the ICORBAFactory interface is:

   {204F6240-3AEC-11cf-BBFC-444553540000}

   A COM class implementing ICORBAFactory must be registered in the Windows System Registry on the client machine using the following class id, class id tag, and Program Id respectively:

   {913D82C0-3B00-11cf-BBFC-444553540000}DEFINE_GUID(IID_ICORBAFactory, 0x913d82c0, 0x3b00, 0x11cf, 0xbb, 0xfc, 0x44, 0x45, 0x53, 0x54, 0x0, 0x0);“CORBA.Factory.COM?

   The CORBA factory object may be implemented as a singleton object (i.e., subsequent calls to create the object may return the same interface pointer).

   We define a similar interface, DICORBAFactory, that supports creating new CORBA object instances and binding to existing CORBA objects for Automation clients. DICORBAFactory is an Automation Dual Interface. (For an explanation of Automation Dual interfaces, see the Mapping: Automation and CORBA chapter.)

   interface DICORBAFactory: IDispatch {HRESULT CreateObject( [in] BSTR factoryName, [out,retval] IDispatch ** val);HRESULT GetObject([in] BSTR objectName, [out, retval]IDispatch ** val);}

   The UUID for the DICORBAFactory interface is:

   {204F6241-3AEC-11cf-BBFC-444553540000}

   An instance of this class must be registered in the Windows System Registry by calling on the client machine using the Program Id “CORBA.Factory.?

   The CreateObject and GetObject methods are intended to approximate the usage model and behavior of the Visual Basic CreateObject and GetObject functions.

   The first method, CreateObject, causes the following actions:

• A COM View is created. The specific mechanism by which it is created is undefined. We note here that one possible (and likely) implementation is that the View delegates the creation to a registered COM class factory.

• A CORBA object is created and bound to the View. The argument, factoryName, identifies the type of CORBA object to be created. Since the CreateObject method does not accept any parameters, the CORBA object must either be created by a null factory (a factory whose creation method requires no parameters), or the View must supply its own factory parameters internally.

• The factoryName sequence could be interpreted as a key to a CosNameServicebased factory finder. The CORBA object would be created by invoking the factory create method. Internally, the interworking solution would map the factoryName onto the appropriate COM class ID for the View, create the View, and bind it to the CORBA object.

• The objectName parameter is mapped by the interworking solution onto a CORBA object reference. The specific mechanism for associating names with references is not specified. In order to appear familiar to COM and Automation users, this parameter shall take the form of a sequence of identifiers separated by periods (.), in the same manner as the parameter to CreateObject. An implementation could, for example, choose to map the objectName parameter to a name in the OMG Naming Service implementation. Alternatively, an interworking solution could choose to put precreated COM Views bound to specific CORBA object references in the active object registry, and simply delegate GetObject calls to the registry.

• The object reference is bound to an appropriate COM or Automation View and returned to the caller.

• The bound View is returned to the caller.

The factoryName parameter identifies the type of CORBA object to be created, and thus implicitly identifies (directly or indirectly) the interface supported by the View. In general, the factoryName string takes the form of a sequence of identifiers separated by period characters (“.?), such as “personnel.record.person.? The intent of this name form is to provide a mechanism that is familiar and natural for COM and Automation programmers by duplicating the form of OLE ProgIDs. The specific semantics of name resolution are determined by the implementation of the interworking solution. The following examples illustrate possible implementations:

• The creation could be delegated directly to a COM class factory by interpreting the factoryName as a COM ProgID. The ProgID would map to a class factory for the COM View, and the View’s implementation would invoke the appropriate CORBA factory to create the CORBA server object.

The GetObject method has the following behavior:

   Another name form that is specialized to CORBA is a single name with a preceding period, such as “.NameService?. When the name takes this form, the Interworking solution shall interpret the identifier (without the preceding period) as a name in the ORB Initialization interface. Specifically, the name shall be used as the parameter to an invocation of the CORBA::ORB::ResolveInitialReferences method on the ORB pseudo-object associated with the ICORBAFactory. The resulting object reference is bound to an appropriate COM or Automation View, which is returned to the caller.