Messaging Technology: A Solutions Perspective

J. Jeffrey Hanson

January 2008

Revised February 2008

Summary: In this article, you'll learn how an ESB can help you manage the complexity of interconnecting systems and services to allow seamless information flow. (7 printed pages)

Introduction
First-Hand Experience
Message Broker: Framework Traffic Cop
Message-Content Selectors: Filtering Message Delivery
Critical-Thinking Questions
Further Reading
Glossary

Introduction

Message technologies allow cooperating entities—such as users, applications, and systems—to interact with each other by sending and receiving messages that can be understood by each entity. Messaging technologies typically allow messages to be sent to a receiver, even if the receiver is not connected to the messaging system. In this case, messages are stored and forwarded by the messaging system to interested receivers until all receivers have received the messages or until a threshold has expired. Messaging technologies should provide features such as message security, message uniqueness, and others.

Figure 1 shows a typical e-mail messaging system.

Cc168610.06_13_Messaging_Fig01(en-us,MSDN.10).gif

Figure 1. E-mail messaging system

Messaging systems such as an e-mail system fulfill a very specific messaging need, such as guaranteed delivery of message across a specific protocol such as SMTP. Business messaging systems must be able to adapt to many types of message content begin transported across multiple protocols to a dynamic list of message consumers.

First-Hand Experience

Working for Consolidated Messenger has given me a unique opportunity to experience integrated messaging requirements being presented by enterprise customers and modernized systems offered as solutions. Modernization of these systems includes such features as dynamically transformable XML message content, mediator-driven message delivery, message-content signing, and service-endpoint targeting.

Early message-integration efforts at Consolidated Messenger fulfilled very specific and static needs with very little change required. Presently, demand for integrated messaging is a primary concern and a concern that changes very rapidly. Consolidated Messenger took advantage of their loosely coupled, service-oriented architecture by enabling it with mediator-driven messaging to respond to messages received from multiple protocols with varied message formats. Existing clients experienced no problems due to modernization of the system, because the modernization provided a smooth migration path.

Figure 2 illustrates how this migration happened.

Cc168610.06_13_Messaging_Fig02(en-us,MSDN.10).gif

Figure 2. Messaging-system modernization

Shown here is a path that is being taken by many enterprises making the move to a message-based, service-oriented architecture. That which evolved into tightly coupled systems must now be refactored into separate services that can be invoked from many possible client types. Service invocations must be very flexible, too, in order to respond to customer needs as quickly as possible. This requirement is met by building configurable invocation paths using technologies such as mediators and message itineraries.

Using mediators and message itineraries, a message travels along a configurable path on its way to the target service or services. Along the way, the message might be augmented using transformation technologies, encryption and decryption technologies, and others.

Figure 3 illustrates how a message travels through a typical message itinerary.

Cc168610.06_13_Messaging_Fig03(en-us,MSDN.10).gif

Figure 3. Message-itinerary flow

The mediator, as shown, handles duties involving such things as message-format conversions, protocol transposing, and security validating to facilitate exchange between message producers and message consumers.

Customers of Consolidated Messenger expressed the urgent need to integrate their business services with the Consolidated Messenger platform in order to take advantage of existing service reuse and to promote these services to new scenarios that would most certainly emerge. This forward-thinking requirement validated the work already completed at Consolidated Messenger to evolve our platform to a loosely coupled, service oriented framework driven by mediated messaging.

The lessons learned at Consolidated Messenger were applied to external customer-framework integration. Since the Consolidated Messenger business services were already being invoked with a mediator-driven messaging system, the addition of HTTP protocol adapters and a few message-augmentation services is all that was needed to address the customers' integration requirements.

By applying mediator-driven messaging, Consolidated Messenger was able to transform message content from one format to another. This proves especially important when a message producer and a message consumer do not support the same message format. A mediator employs transformation and conversion services, perhaps involving XSLT transformations, in order to perform the necessary conversions.

Message Broker: Framework Traffic Cop

Message-driven programming revolves around the concept that a message consumer doesn't care where or why a message originates; instead, a message consumer is concerned that it will be passed all the information it needs to perform its duties when a message is received. This decoupled relationship between message producers and message consumers, sometimes referred to as publish/subscribe messaging, is one of the most powerful concepts in a message-driven system.

A system that decouples message producers from message consumers typically relies on a message dispatcher/broker to maintain message queues that hold messages passed between producers and consumers.

Figure 4 illustrates the relationships between message producers, message consumers, and message queues.

Cc168610.06_13_Messaging_Fig04(en-us,MSDN.10).gif

Figure 4. Message queuing in a messaging system

The role of the message queue is to store messages received from producers and transmit these messages to consumers as each consumer becomes available, typically, in a first-in-first-out (FIFO) fashion or another message prioritization algorithm.

Message-driven frameworks employing a publish/subscribe methodology are sometimes referred to as Message-Oriented Middleware (MOM) frameworks. MOM is an incarnation of an asynchronous messaging framework based around message queues.

MOM offers two messaging models:

· Point-to-Point. This model is based on message stores known as queues, in which messages are dispatched from one or more message producers to a single message consumer.

· Publish/Subscribe. This model is based on message stores known as topics, in which messages are dispatched from one or more message producers to an arbitrary number of subscribed message consumers.

A messaging system typically employs some form of message-content selector routing, which allows messages to be delivered to consumers, based on specific criteria.

Message-Content Selectors: Filtering Message Delivery

Message selectors allow the work of message-delivery filtering to be handled by the message broker/dispatcher rather than by each individual application.

A message selector can be any form of filtering/querying mechanism, but is often times implemented as a string of characters representing the filtering expression. The selector expression is typically applied against message metadata in order to filter message delivery.

Message brokers typically expose an interface that will allow a message consumer to specify a message selector when registering as subscriber to messages. The message consumer then receives only messages whose metadata matches the selector.