| Previous | Table of Contents | Next |
There is a limited fit between Automation objects and CORBA objects:
• Some OMG IDL primitives map directly to Automation primitives. However, there are primitives in both systems (for example, the OLE CURRENCY type and the CORBA unsigned integral types) that must be mapped as special cases (possibly with loss of range or precision).
• OMG IDL constructed types do not map naturally to any Automation constructs. Since such constructed types cannot be passed as argument parameters in Automation interfaces, these must be simulated by providing specially constructed interfaces (for example, viewing a struct as an OLE object with its own interface).
• CORBA Interface Repositories can be mapped dynamically to Automation Type Libraries.
• CORBA object references map to Automation interface pointers.
• There is no clean mapping for multiple inheritance to Automation interfaces. All methods of the multiply-inherited interfaces could be expanded to a single Automation interface; however, this approach would require a total ordering over the methods if [dual] interfaces are to be supported. An alternative approach would be to map multiple inheritance to multiple Automation interfaces. This mapping, however, would require that an interface navigation mechanism be exposed to Automation controllers. Currently Automation does not provide a canonical way for clients (such as Visual Basic) to navigate between multiple interfaces.
• CORBA attributes may be mapped to get and put properties in Automation interfaces.
This form of interface mapping will place some restrictions on the types of argument passing that can be mapped, and/or the
cost (in terms of run-time translations) incurred in those mappings. Nevertheless, it is likely to be the most popular form
of CORBA-to-COM interworking, since it will provide dynamic access to CORBA objects from Visual Basic and other Automation
client development environments.