Chapter 8. Messaging (Lightweight Communication)

In a distributed system, computers are bound together by connections that have widely different characteristics and capabilities. For example, users on an internal network typically have direct, guaranteed access to one or more local servers. They can benefit from proprietary protocols and communicate efficiently over TCP/IP sockets with Microsoft .NET Remoting. Clients that connect over the Internet, however, require different considerations. They are more likely to rely on HTTP and a cross-platform data exchange format such as SOAP. Some users, however, such as those with a dial-up connection or those who use a laptop, can't assume a guaranteed connection of any kind. They might need to perform at least some of their work while disconnected from the rest of the system. In this scenario, the clients can't use XML Web services or .NET Remoting directly. Instead, they need messaging services.

Of course, messaging isn't just a tool to support disconnected clients. It can also ensure scalability and high performance for a large-scale system. Messaging is often described as "lightweight communication" because it allows clients to work asynchronously, sending requests but never waiting for responses. Messaging can also give you the flexibility to even out peak loads and process requests in batches when server hardware is otherwise idle (for example, late at night).

This chapter begins by considering messaging as a natural extension of the asynchronous communication pattern introduced in Chapter 6. We'll look at how you can create true fire-and-forget methods for XML Web services and .NET Remoting components without requiring an asynchronous consumer. Next, and for the majority of the chapter, we'll explore Microsoft Message Queuing, the messaging service that's built into the Microsoft Windows operating system. We'll also consider when (and where) message queues make most sense in a distributed application.