COM+ Queued Components is a service that allows a client to call object methods asynchronously. The client is blocked only for a short duration while COM+ processes the request, and the object executes the call at a later point. You can think of queued components as asynchronous COM+.
Under classic COM and DCOM, all method calls on your object are synchronous—the client is blocked while the object executes the call. Classic COM developers often had to develop a proprietary mechanism for asynchronously invoking calls on their objects. One recurring mechanism had the object spin off a worker thread to process the client request and immediately return control to the client. The object would later signal the client somehow when the call completed (if the client needed to know), and the client had to distinguish between method completions of multiple objects.
Such solutions coupled the clients to the objects and were inconsistent. Different vendors provided slightly different solutions, requiring different programming models on the client side at times.
The first release of MTS and Microsoft Message Queue (MSMQ) in 1998 provided another way to support asynchronous object method calls with COM. MSMQ is a message queuing service that allows you to post messages from one queue to another, potentially across machines.
Clients and objects could use MSMQ to facilitate COM asynchronous method calls. With MSMQ, the client posts a message to a designated queue that contains the method name and parameters. The object retrieves the message off the queue, parses the message, and executes the call. The object and client developers agree about the queue location, the message format, and other details required for asynchronous interaction in advance.
However, using MSMQ for asynchronous calls has some disadvantages:
The nonstandard interaction couples the object to its clients.
The client developers still have to design and implement a way to package the method information into a message, and object developers still have to design and implement a way to parse the message.
MSMQ is not easy to install and use. Developers have to learn how to write code to use MSMQ interfaces.
The client is very much aware that it uses MSMQ to post the call to the object. The resulting asynchronous method invocation code does not resemble the synchronous method invocation on the same COM interface.
This approach is analogous to the pre-DCOM days when developers wrote raw RPC calls to invoke methods on remote objects.
The idea behind COM+ queued components is simple: let COM+ encapsulate the interaction with MSMQ and provide a uniform way of invoking asynchronous method calls. In fact, the method invocation code itself is the same as a synchronous call. The only difference is in the way the client creates the object.
You can think of MSMQ as the transport layer between the client and object, much like RPC is the transport layer in the case of remote activation. A DCOM client does not care about the underlying details of RPC protocol and marshaling when invoking a method on a remote machine. Similarly, a queued components client does not need to care about the details of the MSMQ protocol and the methods-to-message conversion.
Queued components are an essential addition to your arsenal because implementing robust asynchronous execution on your own is a demanding task; it requires you to spend much effort on design, implementation, and testing. By providing you with queued components, COM+ lets you focus on the domain problems at hand, rather than on complicated asynchronous plumbing.
Besides simplifying asynchronous method invocation, queued components provide you with other major benefits (discussed in the following sections).
When the client calls a queued component, the call is converted to a message and placed in a queue. MSMQ detects the message in the queue and dispatches the message to the queued component. If the client and the object are on different machines, the message can be placed in a local queue on the client machine, if necessary.
Imagine that the client is disconnected from the network: suppose a sales person is working on a laptop at the airport while waiting for a flight. The client application on the laptop can still make calls to queued components—to update order numbers, for example. The calls are stored locally by MSMQ. The next time the client machine is connected to the network, MSMQ is aware that the local queue contains messages, so it dispatches them to the remote component.
The server hosting the objects could be disconnected as well. MSMQ transfers queued messages from the client machine once the object machine is brought back online.
The benefits of disconnected work are twofold. First, your system’s robustness improves because network outage between a client and a queued component is handled easily. Second, allowing disconnected work in your application, by design, has practical importance: approximately 40 percent of all new computers sold are for mobile and portable use. These devices benefit greatly from queued components, as they allow users to continue working while offline or on the road. Targeting the portable market is an important consideration for many modern applications.
Many enterprise-wide applications are developed to automate existing business processes and information flow. These processes, such as email and voicemail, are often messaging-based by nature, and modeling them with queued components is very appropriate.
A component may not be available because of server overload or networking problems. Under classic DCOM, you would have to abort the whole transaction or wait for the component to become accessible. Using queued components, you can separate the transaction into activities that must be completed now and those that can be completed later. Your end users will be unaware of server slowdowns or failures.
MSMQ is a resource manager, and will thus auto-enlist in your transactions. When your application makes calls to queued components during a transaction, your application (via COM+) adds messages to an MSMQ queue. Those messages will not persist in the queue if the transaction is aborted. The transaction coordinator (DTC) instructs all resource managers that participated in the transaction to roll back the changes. MSMQ’s rollback rejects the messages that were added to the queue during the transaction.
Once a message is added to a queue, COM+ tries to invoke the call in that message on the object. When COM+ retrieves the message from the queue, it creates a new transaction for the retrieval. If the object participates in that transaction, and that transaction is aborted, MSMQ’s rollback in this case will return the message to the queue. This, in turn, causes COM+ to try again to invoke the call on the object.
A major scalability bottleneck is the length of time the client ties up an instance of the server. In a distributed system, you should minimize that time as much as possible by reducing the number of network round trips to allow your server to accept calls from other clients. When a client makes calls on a queued component, COM+ records the calls the client makes and combines them into a single message. Message delivery generally requires just a single network operation, so the time the server instance is occupied is reduced.
Every system has a peak load of clients asking for services. Systems architects have to design the system to handle that peak load. The question is, what do you do if the workload is uneven throughout the day? Designing your system to handle the peak load in real time may require huge investments in expensive hardware, load balancing machines, longer development time, and more difficult design goals. Such an approach results in a system that may handle the peak load, but remains vastly underutilized on average. A more realistic alternative is to accept client requests, buffer them, and execute them later on. For example, most online web stores do exactly that—they accept your order immediately and you are free to surf other web sites. The store buffers your request and can handle the next client. In the background, at the system’s leisure, it processes the request and sends you an email confirmation once your order is processed and shipped.
Using queued components, you can separate the purchasing task into two stages: a short-duration, front-end, synchronous acknowledgement, and an offline, queued task—the order processing itself.
Clearly, queued components offer solutions to several real-life problems, saving you precious development time and increasing overall system quality. The question is, when should you use queued components?
During system requirements analysis, try to identify business activities that can be separated by time. You may execute each activity synchronously, but you connect them with queued components.
For example, imagine an online store. Orders are collected from the customers immediately and synchronously. Processing the order—parts orders to various vendors, billing updates, and so on—can be done later. All tasks must be done, but they don’t all have to be done at once.