COM & .NET Component Services

Configuring COM+ Applications

The primary benefit of using COM+ is that you can configure a component or the application containing it without changing any code on the object or the client side. This advantage enables you to focus your object code on its intended purpose, relying on the various services COM+ provides instead of having to develop them yourself. This section shows you how to configure some of the application-level options for the Hello COM+ program you created.

COM+ Application Types

As mentioned previously, the application activation type (a server or a library application) is a configurable application-level attribute called activation. You can configure the application’s activation type in the application’s properties page, under the Activation tab (see Figure 1-9).

Figure 1-9. Application Activation tab

Changing the application type has significant implications for most COM+ services. The application type is a design-time decision that should consider the security needs of your components, the calling patterns of your clients, fault isolation (a server application gets its own process), and specific COM+ services requirements. Throughout the book, a particular service configuration that is related to the activation type is pointed out explicitly. However, even without knowing much about COM+, you can use the following rule to decide on your activation type: prefer server type applications, unless you absolutely need to run in the client process for performance reasons. Library applications have some limitations in using COM+ services (such as security and queued component support), and they cannot be accessed from another machine.

COM+ Surrogate Processes

If the original COM components resided in a DLL, how does COM+ achieve different activation modes for the configured components? When the application is configured as a library, the client loads the DLL directly into its process. When the application is configured as a server application, COM+ creates a surrogate process for it, called dllhost.exe, that loads the DLL. COM+ then places a proxy in the client process and a stub in the surrogate process to connect the client to the object. You can have multiple instances of the dllhost process running on your machine simultaneously; if clients have created objects from different server applications, each server application gets its own instance of dllhost.

To verify these points yourself, configure the Hello COM+ example to run as a server application. Run the test client again, create the object, and call the ShowMessage( ) method, but do not press the OK button. The Component Services Explorer gives you visual feedback when a server application is running: the application icon and the active components will be spinning. Library applications will have no visual feedback when they are running in a client process, even if that process is another COM+ server application. Expand the COM+ Applications folder and select the Status View on the Component Services Explorer toolbar (the button at the far right end of the toolbar; see Figure 1-10). The Component Services Explorer will display the process ID of the running server applications. Record the process ID for the Hello COM+ application. Next, bring up Windows Task Manager and locate the process with a matching ID. Its image name will be dllhost.exe.

Figure 1-10. Examining a running server application

The first CoCreateInstance( ) request for a component in a server application creates a new dllhost process, to host components from that application only. Subsequent CoCreateInstance( ) calls to objects from the same application create new objects in the existing dllhost instance. Unlike classic COM, there is no way to create each object in its own process. No COM+ equivalent to the COM call you make to CoRegisterClassObject(...REGCLS_SINGLEUSE...) exists.

The Component Services Explorer also lets you manage server application activation administratively. You can shut down a running application by right-clicking on its icon in the Component Services Explorer and selecting Shutdown from the pop-up context menu. You can shut it down even when clients are holding active references to objects in the application. (You shut down applications this way frequently during debugging sessions.) The Component Services Explorer does not provide a way to shut down library applications, since COM+ may not even manage their client process. You can also select Start from the server application pop-up context menu to launch a new dllhost process associated with that application. However, no objects will be created unless you use object pooling, which is discussed in Chapter 3.

Idle Time Management

Another distinction between a classic COM local server and a COM+ server application is process shutdown. In classic COM, when the last client has released its last reference on an object in the process, COM would shut down that process. COM+ provides idle time management for COM+ server applications. COM+ server applications can be left running indefinitely even when idle (when there are no external clients), or you can have COM+ shut them down after a predetermined timeout. This shutdown is done for the sake of performance. Imagine a situation in which a client creates an object from a server application every 2 minutes on average, uses it for 1 minute and 55 seconds, and then releases it. Under classic COM, you would pay an unnecessary performance penalty for creating and destroying the server process. Under COM+, you can configure the server application to be left running when idle for a specific time. If during that time no client request for creating a new object has come through, COM+ is allowed to shut down the process to release its resources. In this example, you would perhaps configure the server application to be left running when idle for 3 minutes, as you would want to compensate for variances in the client calling pattern. If a new call comes in within those 3 minutes, COM+ zeros the idle time counter and starts it up when the application is idle again. You can configure server application idle time management under the Advanced tab on the server’s properties page (see Figure 1-11). Library applications do not have an idle time management option and will be unloaded from their client process once the last object has been released.

Figure 1-11. Configuring server application idle time management