Chapter 4: Applying Reliable Messaging

Messaging provides an infrastructure that binds distributed enterprise components together. Components, such as reporting services and analytical services, might reside on different computers at different locations. Messaging services provide a way to support reliable communication that binds all components together. Messaging also supports an open development framework that allows an enterprise solution to easily integrate new functionality produced after an enterprise product has shipped.

This chapter closely looks at messaging within the .NET Framework and how this vital communication mechanism can tie together a scalable enterprise application. The chapter begins by looking at how messaging systems work and showing how to configure a messaging environment. Next , it introduces the messaging-supported classes within the .NET Framework and shows how to implement an application messaging framework. The chapter concludes by implementing a sample distributed service.

Introducing Messaging Systems

Messaging binds distributed components together. If a distributed component becomes unavailable, the process requesting the services is not immediately impacted. Suppose an application requires the services of a reporting engine. If the reporting engine is integrated by direct method invocation, the requesting application fails when the reporting engine is disconnected. However, if message binding integrates the two, then the application requesting the reporting services would simply post a request and move on to other activities. When the reporting engine is available, it processes the request and performs its function.

Many successful enterprise applications, such as PeopleSoft, count on messaging for flexibility. Essentially , the application is organized into discrete modules that accomplish specific tasks . Messages sent between the modules define the behavior of the application. For example, when a user enters information into a form, the functional code behind the form formats that information into a message that is then sent to a data access component, which commits the information to the database. At first, this might sound like an unnecessarily complex way to process information. However, the benefits outweigh the costs. It requires little effort later to add a new user interface component that seamlessly replaces the outdated one by sending and receiving the same messages. Even a new component can intercept the message, validate the submitted information, and then forward the message to the data access component.

If building applications purely on messaging sounds familiar, it probably should. This is essentially how all Internet applications work. Client code, packaged within a Web browser, sends messages using the Hypertext Transfer Protocol (HTTP). The messages contain a header and a body as defined by the protocol. The messages are received by a Web server, which shares many characteristics of a message queue. The server either processes the data contained within the body of the message or forwards the message to another process.

Messaging services offer a number of advantages over direct method calls between components. Messages are much more robust than direct method calls in that the invoking process is more insulated from failures within the referenced component. Also, messages can have varying priorities so that specific functions can be accomplished sooner. Messages can also have transactional characteristics if several related messages are grouped together. This ensures that the series of messages are received only once and in the intended order. Finally, messaging leverages the sophisticated security model built into the underlying operating system with support for auditing, encrypting, and authenticating messages.

Messaging systems share a lot of similarity with e-mail systems. Both operate using three fundamental components: messages, queues, and a managing server. Messages communicate specific information between a sender and recipient. They are sent from one point to another and are held within message queues until read. Message servers, such as Microsoft Message Queue (MSMQ), are responsible for managing message queues, encrypting messages, sending and receiving messages, authenticating, and routing messages to their final destination.

Understanding Messages

Messages are discrete packages of information with a distinct sender and recipient. In most cases, messages are composed of a label, which describes the subject of the message, and a body, which communicates the actual information. Message labels are usually human-readable text descriptions; the body might vary from simple text to images to compiled code.

Defining the Message Label

A message label is similar to the subject line of a typical e-mail message. The label provides the message a means to describe its contents, which in turn allows multiple listening applications to determine if it should be interested in the message. Typically, the message header will contain a word or phrase for which an application is looking. If the word appears in the message label, the application reads the message body and processes its contents. Otherwise, the application ignores the message entirely.

Defining the Message Body

The message body contains the information that needs to be communicated from one process to another. The message body can contain any type of data including a simple text message, a selection of spreadsheet cells , and a graphic file. There are different methods available for accessing and processing the message body.

Defining Transactional Messages

A message-driven process can bind several related messages into a single transactional message , ensuring that the messages are delivered in order, are delivered only once, and are successfully retrieved from their destination queue. If any errors occur, the entire transaction is cancelled.

Understanding Message Queues

Message queues hold messages until they are read by messaging clients . When a client reads a message, the messaging system removes the message from a queue. The queue is also responsible for ensuring the integrity of a message. When a server hosting a message queue goes down, it is expected that the message queue is restored to its original state when the server becomes available again. There are two fundamental types of message queues: user queues and system queues.

User queues maintain messages used by installed applications. They are divided into two different classifications: public queues and private queues. A public queue is available to all clients and servers within a domain. Other messaging systems within a network are able to post messages to a locally managed public queue. A private queue is only available to locally installed applications. Some operating systems, primarily workstation platforms, are unable to create public message queues for security reasons.

System queues exist whether public or private message queues are available. These queues manage two basic types of system messages: journal messages and dead-letter messages. Journal messages are duplicates of outgoing nontransactional messages created when a sent message reaches its destination. Journal messages are disabled by default because copies of outgoing messages quickly drain system resources. Dead-letter messages are undeliverable, expired nontransactional messages that are stored for future reference. Messages are considered undeliverable when the destination queue is unknown, the maximum number of hops is exceeded, the destination queue is filled, or a transactional message is sent to a nontransactional queue.

Message systems also adopt one or more of the following three messaging models: point-to-point, publish-subscribe, and request-reply.

Defining Point-to-Point

Point-to-point messaging enables one process to send messages to and receive messages from another specific process. In this model, messages are targeted at a single specific receiver. Other message handlers within the enterprise application should not process them. Point-to-point typically requires a message queue that the receiver monitors .

Defining Publish-Subscribe

Publish-subscribe messaging enables multiple processes to receive any given message. This model is based on the concept of a message topic. Usually, topics are broadly defined events that multiple processes listen for and act upon. This messaging model is essentially what is at the core of the Microsoft Windows operating system. Every keystroke and mouse click generates an event that the operating system handles. At the same time, the active application receives the same system messages and might decide to act upon them. Even the form controls, such as buttons and list boxes, receive the same event messages. Although MSMQ does not specifically support this methodology, you can accomplish the effect by having connected clients peek into a shared message queue containing messages marked with an expiration.

Defining Request-Reply

Request-reply messaging ensures that a process that sends a message will receive a message in response. Minimally, this might represent an acknowledgment that the message was received. In most cases, the request-reply model applies to transactions that send a request message and suspend activity until a reply is returned.

Understanding a Message Server

The message server manages one or more message queues and ensures that messages either arrive at the destination or return with a notification. Message servers maintain information about message delivery, including how many stops (referred to as hops ) a message makes before reaching its destination. Each hop represents a message queue on a server closer to the destination where individual messages can be evaluated and routed to the next hop. If a message does not reach its destination within a specified number of hops, the server holds on to the message until the destination is available. The message server also preserves the state of its message queues. When a server is brought down and later restarted, its original state will be returned.