Title: COM / OLE Automation FAQ
Question: There are many terms for the same or similar thing arround the COM technology...
Answer:
-What is the difference between Automation and ActiveX ?
Automation is a subset of Microsoft COM (Component Object Model) that allows applications to communicate with each other in a standard way. It is based on a single COM Interface, called IDispatch, which allows the dynamic binding of a client to a server. Automation servers can be DLLs, EXEs or even COBOL .INT/.GNT. It is often referred to as "OLE Automation" because when Microsoft originally brought out this technology, the name it used was OLE2.
An ActiveX control is a COM object that is built into a DLL and supports several more interfaces, although its main interface remains IDispatch. The other interfaces enable the component to act as a GUI control within a parent window. The name ActiveX is the name Microsoft uses to cover all COM and OLE activity.
Micro Focus supports both Automation, as a client and server, and ActiveX controls. This document only covers Automation support.
-Is COM an ORB?
No. CORBA ORBs (Object Request Brokers) are a similar object technology, but COM is not one of them. Microsoft produces COM on Windows and other companies have ported it to non-Windows platforms such as Unix and have also produced COM/ORB bridges.
Most Windows applications and many Windows operating system components have COM interfaces. It is the de facto standard for component interoperability on MS platforms.
- What can I do with OLE Automation?
Most languages, including many scripting languages, support automation. See the appendices for further information.
Automation servers allow a client to reuse the technology within an application - for instance, building, saving and printing a report using Microsoft Word.
You can add an automation interface to your existing application in order for it to be reused by new programs.
-What types of servers can I create?
There are two types of server: in-process (DLLs) and out-of-process (EXEs)
In-process servers are faster because there is no context switching, but less secure because a crash can bring the whole application to a halt.
-What are the differences between in-process and out-of-process components?
Registry differences
In-process servers are registered using the InProcServer32 key, under its class id (CLSID); out-of-process servers use the LocalServer32 key.
In-process servers need the DllSurrogate registry entry under the AppId key on the server machine when using DCOM.
Multi-threaded in-process servers require the registry entry "ThreadingModel" under the InProcServer32 key to tell OLE how the DLL can deal with threading. The value of the entry may be blank (for single-threading), "Apartment", "Free" or "Both" (for both apartment- and multi-threading).
- What is a Dual Interface?
A Dual Interface is both an automation interface and a native COM interface that is, it extends the IDispatch interface of just seven methods with methods of its own that clients can call directly. For clients that can bind to dual interfaces, this greatly increases call speed.
Object COBOL servers can also be dual interfaces by specifying the dual attribute in the type library. The class wizard will automatically generate your type library with this attribute; OCREG has a check box that allows you to choose.
NB: Dual interfaces have a different IDL composition to non-dual interfaces
- What is DCOM?
DCOM is Distributed COM that is, COM objects used over a network, using network protocols such as TCP/IP to communicate. DCOM therefore allows the client and server to be on two different machines.
DCOM has many operational rules:
Basic Win95 does not support DCOM You need to install the Win95 DCOM pack available from Microsoft, or some other package, such as Internet Explorer 4, which also installs this support. The DCOM support also includes component multi-threading support.
Note: COM Servers will not automatically be launched by Win95 for security reasons; the COM server needs to be running before Win95 will allow clients to communicate with the server.
Location You need to tell the client machine on where the server is located. You can do this in several ways:
Run DCOMCNFG.EXE, find the description of the server, select "Properties" and "Location", ensure that the option "Run this program on the following computer" is selected then enter the name of the server.
Add the location to your client registry file before entering it in to the registry, using the "RemoteServerName" entry under the AppID key.
Security Access Make sure that each valid client user has both launch and access permissions to use the server. Use DCOMCNFG.EXE to change these.
Server identity The server needs to know under which user identity it will run on its machine. Use DCOMCNFG.EXE to change the identity. There are three options:
The Launching User. The server will run under the user that the client machine is logged in with. Each client user will get a separate instance of the server launched for it.
NOTE: Server machines have a VERY SMALL maximum number of simultaneous servers it can launch this way this is because each users server is run under a separate Windows "WinStation" and these consume resources!
The Interactive User. The server will run under the identity of the user logged in to the server machine. The server will only be launched once unless it is marked as a "single-use" server. It will only run if a user is logged on, and has access to the screen for GUI.
This User. The server will run under a particular identity. The server will only be launched once unless it is marked as a "single-use" server.
NT Domain security. Clients and servers should normally be running in the same NT domain, but the same user logging on to two different NT Workstations with the same password should also allow a client to call a server, although the user must be added as a local user on an NT Server.
If the client passes an automation object to the server, the server may not have the correct security privileges to call methods on that object. In this case the client should use the OLE API "CoInitializeSecurity" with appropriate parameters before passing the object.
In-process servers - In-process servers are used over DCOM using a proxy program on the server machine to load the DLL. The default is called "Dllhost.exe". The server machine needs the special named value "DllSurrogate" under the AppId registry key specifying the proxy program (blank indicates using the default). Unlike on a local machine, if the server is registered as running under a single user identity, the proxy will only be started once and the instances of the server object will share data space in the same executable.
NTFS has security on directories the identity that the server application is being run under must be given the right privileges to access and execute programs and data that have been protected in this way.
- What is a type library?
A type library is a binary dictionary of a components interfaces, methods and properties. It allows other applications to browse your dictionary to search for the methods it needs, and to use it to bind to.
You dont have to have a type library for your automation component, but some client languages require one.
A type library is built either using a tool or through compiling a descriptive file. The file will contain the description in the language IDL (Interface Description Language) and is compiled by the MIDL utility.
A type library must always be kept up-to-date with both the source class and the registry entries. This includes the ids used by COM to identify components.
For DCOM, type libraries should be registered on both the client and server machines.
The Microsoft utility OLEVIEW can be used to view type libraries.
- What is early and late binding?
Early binding: The linker will put calls into your program that call the methods in the server directly, and will verify that your parameter types match that in the type library used to bind. This produces faster code but also means that the component must be available wherever you ship your application, and there is no protection if you pass the wrong data types or invalid data.
Late binding: Late binding is dynamic binding the client can call the methods in the server on a dynamic basis without having to link to the server code. Scripting languages use dynamic binding.
There are two types of late binding. Normal late binding involves asking the server for the dispatch id of a named method via a method in the IDispatch interface called "GetIDsOfNames", then calling the method via the IDispatch method "Invoke" passing the id.
Dispatch id binding uses the type library during the writing or compilation stage to get the dispatch id for each method first, saving the overhead of having to make two IDispatch method calls for each method invoked.
-What is MTS?
MTS is Microsoft Transaction Server (also known as MTX).
MTS is an extra layer on COM that provides for transaction integrity using COM in-process automation components. It also provides further security abilities and a method of packaging components for DCOM.