- 17.05 (released) ...
Regardless of its location, a COM components can be accessed either through OLE Automation or directly through the interface's virtual table.
Accessing a COM component through Automation means using a well-known interface called IDispatch to access to a group of methods and properties. This interface includes the method
One advantage of this approach is that the interface has a known virtual table layout. As a result, Windows can include a built-in marshaler for that interface (See Deeper into COM for information on marshalers). The supported types (known as Automation types) and their Eiffel equivalents are listed in the following table:
|COM Type||Eiffel equivalent||Description|
|unsigned char||CHARACTER||Standard character|
|float||REAL||4-byte real value|
|Interface IDispatch *||ECOM_INTERFACE||Automation interface|
|Interface IUnknown *||ECOM_INTERFACE||Generic interface|
|Coclass Typename||TYPE_NAME||Component main class|
|TypeName*||CELL [TypeName]||Pointer to type|
Another advantage is a more dynamic discovery of the methods and properties of a component at runtime. Indeed the IDispatch interface also includes methods to determine whether or not a method or property is available and, in the case that it is available, get its identifier. This process is called late binding and allows component to discover at runtime the availability of functionality on other components.
This approach has also a lot of drawbacks. First, late binding is not an efficient way of calling a function on an interface. This is because first its identifier must be requested, and then the function called. That's two round trips which can be expensive in a distributed environment. Second, since the marshaler is built-in, it has to know in advance all the possible types that a function can accept to be able to marshal the corresponding data. Consequently, there is a limitation on the number of types that one can use in signatures of functions on an Automation compatible interface. The set of available types is called Variant and cover most of the standard types. It does not allow however the passing of complex user defined data types.
For these reasons Automation is mostly used in scripting environments (where speed is not an important factor) to accomplish simple tasks.
Direct interface access is the preferred way to access remote servers where speed becomes a concern and data types are specific to the application. The first interface pointer on the component is obtained through the class object (see Class Object ). Other interfaces on the component are obtained by calling the QueryInterface function.
Because information on any interface cannot be accessed dynamically, the description of the interfaces must be provided to tools that need to handle the components such as the EiffelCOM wizard. The official way of describing components and interfaces is through Interface Definition Language (IDL). Once an IDL file has been written to describe a component it can be compiled with MIDL (the Microsoft IDL compiler) to generate both a type library and the code for the marshaler specific to that interface.
One idea behind EiffelCOM is that the details of how a component is accessed should be of no concern to an EiffelCOM programmer. Of course the programmer should be able to choose which kind of access he or she wants to use, but this choice should have no impact on the design of the Eiffel system itself. For that reason, the Eiffel code generated by the wizard follows the same architecture independently of the choice made for interface access and marshaling. The differences in access are handled in the EiffelCOM runtime library where the actual calls to the components are implemented.
- Parent <COM and Eiffel>