The ProxyStub Makefile

[Previous] [Next]

As described in Chapter 2, COM defines an abstraction, called an apartment, for managing concurrent access to components. An apartment is a grouping of objects that share the same threading requirements. A single-threaded apartment (STA) can house one and only one thread. The multithreaded apartment (MTA) can house any number of threads. Every thread that wants to gain direct access to a given COM object must reside in an apartment—the same apartment, in fact, in which the COM object resides. Before accessing the object, a thread must call CoInitialize or CoInitializeEx, whereby it specifies which type of apartment it wants to enter. When a thread creates an instance of a COM object, that object might or might not reside in the same apartment as the creating thread, depending on the apartment preference specified by the object itself. Because a thread can directly access only the objects that reside in its own apartment, communication with objects residing in other apartments can occur only by means of a proxy. A proxy is an object that resides in the apartment of the calling thread that behaves as if it were the object itself. The proxy forwards method calls from one apartment to another—a technique known as method remoting—ensuring that all calls are made by threads running in the object's apartment. On the server side, a special interface stub object that runs in the address space of the callee unmarshals the parameters for that interface and makes the requested method call. The proxy and stub typically communicate with one another using Object Remote Procedure Call (ORPC) requests.

The beauty of the apartment model is that a client can remain blissfully ignorant about the threading limitations of the COM object, treating those requirements as essentially an implementation detail.

NOTE

---

This information on apartments and threading is specific to Windows NT 4.0. The apartment story changes with Windows 2000.

Marshaling Methods

Method remoting not only expedites communication between apartments, it also facilitates communication between objects running in different processes and on different machines via a technique known as marshaling.¹ The three marshaling techniques are described in Table 4-4.

Table 4-4. Marshaling Techniques.

Technique	Description
Custom	Object implements the IMarshal interface and handles its own cross-apartment communication. This technique is used only in the rare cases in which the COM-provided marshaling techniques don't suffice.
Type library	Uses OLEAUT32.DLL to marshal the interface. The type library marshaler provides marshaling only for the Automation data types. The component specifies type library marshaling using the [oleautomation] or [dual] Interface Definition Language (IDL) attributes. Type library marshaling supports marshaling between 16-bit and 32-bit applications.
Standard	COM looks in the Registry to find the correct proxy/stub DLL for marshaling the interface. The object must define custom data types in IDL and provide registered proxy/stub objects for each marshaled interface. More than one proxy/stub object can reside in the same server DLL.

As you can see from Table 4-4, type library marshaling is used with Automation-compliant interfaces and uses the built-in proxy/stub objects the system provides. Type library marshaling is an appropriate choice for dual interfaces or interfaces with methods that use only the primitive VARIANT-compatible Automation data types. Standard marshaling is much more flexible because it allows you to create sophisticated data structures in IDL, but it requires you to build and register in-process proxy/stub objects.

NOTE

---

It's not a strict requirement that interfaces marked with the [dual] keyword use the type library marshaler. In theory, there's nothing to prevent you from registering a custom proxy/stub DLL for dual interfaces, but that is rarely done in practice.