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)


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


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.


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.


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.


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.


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.

Critical-Thinking Questions

· What are the advantages of asynchronous delivery of messages?

· What kinds of problems are solved by storing messages and forwarding them as consumers become available?

· What are the advantages of a point-to-point messaging model as opposed to a publish/subscribe model?

Further Reading

· Hohpe, Gregor, and Bobby Woolf. "Introduction to Messaging Systems." 2003. (Accessed January 31, 2007.)

· IBM developerWorks."Asynchronous Messaging Using Web Services." August 25, 2006. (Accessed January 31, 2007.)

· The Java EE 5 Tutorial. "The Java Message Service API." September 27, 2006. (Accessed January 31, 2007.)

· Sun Developer Network (SDN). "Messaging Systems and the Java Message Service (JMS)." 2007. (Accessed January 31, 2007.)

· Wikipedia. "Message-oriented middleware." 2007 (Accessed January 31, 2007.)

· Wikipedia. "Microsoft Message Queuing." 2007. (Accessed January 31, 2007.)


ESB—Enterprise Service Bus. Acts as a shared messaging layer for connecting applications and other services throughout an enterprise computing infrastructure.

HTTP—Hypertext Transfer Protocol. A protocol that is used to transfer data on the World Wide Web. Its original purpose was to provide a means to post and get HTML pages.

Mediator—A software component that is responsible for applying message itineraries as they travel to their ultimate destination.

Message broker—An intermediary software component that translates a message from the protocol of the message producer to the protocol of the message consumer and then dispatches the message to the message consumer as the consumer becomes available.

Message itinerary—Contains the rules that determine how messages are routed and transformed as they make their way to their ultimate destination.

MOM—Message-oriented middleware. A model of an asynchronous messaging framework based around message queues.

Service Endpoint—A component, device, or other type of addressable resource to which service messages can be routed.

SMTP—Simple Mail Transfer Protocol. The standard for e-mail transmissions across the Internet.

SOA—Service-Oriented Architecture (SOA). Based on the concept of loosely coupled, protocol-independent, and location-transparent services.

Store and forward—A messaging technique in which messages are sent to a broker/dispatcher where the messages are stored and forwarded to message consumers as they become available.

XSLT—Extensible Stylesheet Language Transformations. An XML-based language that is used for the transformation of XML documents into other XML documents without changing the original document.

About the author

Jeff Hanson has more than 20 years of experience in the software industry, including work as senior engineer for the Microsoft Windows port of the OpenDoc project and lead architect for the Route 66 framework at Novell. Jeff is currently the chief architect for, Inc., and builds service-oriented reinsurance frameworks, platforms, and systems. Jeff is the author of numerous articles and books, including .NET Versus J2EE Web Services: A Comparison of Approaches, Pro JMX: Java Management Extensions, and Web Services Business Strategies and Architectures.


This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit