One of the major requirements for the COM+ queued components architecture specifies that the component developer should take no special steps to make a component asynchronous; the developer writes synchronous code, and COM+ provides the mechanism to allow clients to call the method asynchronously.
As a result, the client cannot create the component directly, since it would result in the usual blocking calls. Instead, COM+ uses the architecture shown in Figure 8-1. For every queued component, COM+ provides a recorder object. The recorder object supports the same set of interfaces as the queued component. When the client calls methods on the recorder interfaces (Step 1), the recorder (as the name implies) merely records the calls. When the client releases the recorder, the recorder converts the calls to an MSMQ message and posts that message to the recorder queue (Step 2).
Every application that contains queued components has a queue associated with it. MSMQ transfers the message to the application queue from the recorder queue (Step 3). For each application, COM+ maintains a listener object that detects when a message was added to the application queue (Step 4). The listener creates a player object (Step 5) and instructs it to retrieve the message from the queue (Step 6). The player creates the actual component and plays the calls back to it (Step 7). When the player is finished playing back calls, it releases the component.
You can think of the recorder as the component proxy. The recorder is responsible for forwarding the call across processes or machines to where the object resides. The recorder lives in the client process and supports the same set of queued interfaces as the component. When clients query the recorder for a different interface, then the recorder must also provide recording ability for the interface if it is supported by the real component.
The player in this architecture is analogous to the stub—it translates the MSMQ message to method calls and then makes those calls to the object. The player is responsible for removing the message from the queue and is configured to always require a transaction. As a result, creating the player kicks off a new transaction that includes in its scope the message removal and the playback of method calls. Every action the queued component takes when executing the methods, such as database updates, executes within that transaction. If, for example, the database update fails, the transaction aborts and every resource manager that took part in it has to roll back. As mentioned previously, MSMQ is a resource manager and its rollback puts the message back in the queue. The listener detects its presence there and retries the playback sequence (more on that later).
Every COM+ application has at most one listener associated with it, serving all queued components in the application by listening to the application queue and creating the player objects.
Note that the queued components design separates the act of detecting a message from the act of playing it back to the component. If the listener were responsible for calling methods on the objects, then all calls to queued components would be asynchronous, but serialized—that is, occurring one at a time. That kind of design would have killed performance. By having a dedicated player for each component, the listener can process asynchronous calls as fast as they can be added to the queue.
The listener object lives in the application process. If you configure your application to support queued components, COM+ creates a listener in the application process when the application is launched. In fact, if the application is not running, then no one will listen to its message queue, and, as a result, no queued components will ever be instantiated. COM+ cannot possibly know when it is a good time to create the application and have it start servicing queued calls for you. Only the application administrator has that knowledge (for example, what hours of the day or what load level).
You have a number of options available for launching the application:
Start the application manually from the Component Services Explorer.
Provide your application administrator with a simple utility that makes programmatic calls to the COM+ Catalog (as explained in Chapter 6) to start the application.
Use the Windows Task Scheduler to invoke your utility at designated times.
Activate nonqueued component in the same application. This activation causes COM+ to launch the application, and by doing so, it creates the listener.