COMments

[Previous] [Next]

The User Profile Services framework resides in an ActiveX DLL that supports the single-threaded apartment model (STA). When a client like Microsoft Internet Explorer—which supports the multithreaded apartment model (MTA)—creates an instance of a class defined in this component, COM will automatically do the following:

1. Spawn a new thread.
2. Create a single-threaded apartment in the new thread.
3. Construct an instance of this class within the apartment.
4. Return a proxy that references the class instance to the thread in the client that initiated the action.

All requests made to this User Profile Service framework object will be marshaled between threads. Consequently, if permitted, a client could possibly construct a UserProfileRepBridge (bridge) object in one thread and a UserProfileRepository implementation class (implementor) object in another. This results in a costly performance lag because the implementor and the bridge objects are bridging across threads. All client requests made to the bridge will be marshaled from the client's thread to the bridge's thread. All events published from the bridge will be marshaled from the bridge's thread to the implementor's thread. If the client expects a return value from a request, it must be marshaled back from the implementor's thread to the bridge's thread, and finally to the client's thread.

To avoid this dilemma, you want to create the bridge and the implementor in the same thread, which results in both objects residing in the same COM apartment. When objects live in the same apartment, they can access each other through a direct address pointer (no proxy required) and produce optimal performance. This is easier said than done, because implementors by nature do not exist in the same ActiveX component as the bridge. Implementors generally are created in other components to dynamically attach new behavior. Visual Basic does not support MTA; therefore, the Bridge design pattern is best suited for clients that support the same threading model as the framework DLL. When an STA client creates objects from an STA ActiveX DLL, the objects are created within the client's apartment. All requests to the object are therefore made through a direct address pointer.

To produce the best performance for the framework, however, I defined the UPFactory class (described in Chapter 8, "Object Factory") that will at least create all framework-defined class objects within the same apartment, if used by an MTA client. So, if other concrete repository classes were defined within the framework that inherited the UserProfileRepository interface, you could rest assured that requests to these objects would execute implementation within the same apartment.

Avoid using the Bridge design pattern in out-of-process servers (such as ActiveX EXE projects) because, regardless of the threading model, a client containing an implementor would have to link with a bridge object across process boundaries. This is even more costly than linking across threads, and the deficit increases dramatically when the processes are distributed on different nodes.

A possible complement to an out-of-process server is a Smart Proxy Bridge (described in Chapter 7, "Smart Proxy"), which allows you to implement the Bridge design pattern locally to the client process while still providing transparent access to remote objects.