Message Queues in a Distributed Application

Message Queuing is new to many developers, and we've spent the large part of this chapter examining Message Queuing fundamentals, such as sending and processing messages. The unanswered question that all this raises is where a message queue should enter into your distributed application designs.

Unlike databases, message queues lack almost all error-checking capabilities. That, coupled with the fact that they are tightly bound to the Windows operating system, makes them poorly suited for client use in a distributed application. They also tend to bind a specific user to a fixed machine. In a production-level application, the amount of code you need to write to check for error conditions and respond appropriately might become cumbersome. There is also the fact that dead-letter, confirmation, and journaled outgoing messages might end up scattered on computers throughout the enterprise, making it difficult to track down problems or perform meaningful diagnostics.

However, Message Queuing works much better when it serves as an internal backbone for your components. For example, you might create an XML Web service that uses a message queue to forward work requests to another server-side component. This design neatly sidesteps the problems of other asynchronous approaches and guarantees scalability and high-performance. In Chapter 17, we'll consider a case study that puts Message Queuing to work coordinating an XML Web service and an internal client.

COM+ Queued Components

Experienced COM+ developers might know about queued components, an abstraction that enables you to call a method on a server-side component in an asynchronous, disconnected fashion. Essentially, your call is intercepted by a specialized "recorder" that translates the method call into a message. The message is received on the destination computer, which uses a specialized "player" to invoke the requested method on the component.

The best part about this approach is that it all takes place transparently. When you call the queued component, you don't need to use any special Message Queuing code or classes. It seems that this could be an ideal solution for dealing with heavy user loads in the world of .NET.

Unfortunately, as you'll discover in the next chapter, COM+ components aren't easily remotable unless you either embrace DCOM again (shudder) or create a .NET wrapper component. Because calls to an ordinary .NET component can't be queued, this approach removes most of the benefits that queued components provide. However, all is not lost several programming gurus have remarked that the pluggable .NET Remoting infrastructure can easily accommodate a Message Queuing channel, which would allow transparent component interaction through a message queue. This functionality hasn't been developed, but it seems like a logical next step for Microsoft as it adds to its infrastructure support in coming upgrades to .NET. In the meantime, you can create one-way, fire-and-forget methods for XML Web services and .NET Remoting components.