Chapter 11. Messaging

Your application is done. Time to sit back and relax, right? Well, generally, no. You see, there's this thing that people in business tend to do when confronted with new applications. "Wonderful," they say. "Now can we connect it with our other system?" And the dance of development begins again.

In fact, the future often arrives before the application is even finished. More and more, the usefulness of any given system depends on how well it can connect to other systems, sharing data and participating in ever more elaborate processes. Sometimes every system is shiny and modern, and all the interactions take place directly in Java. But usually many of the systems are old, incompatible, or both: they could include COBOL, thick Client/Server, and even Java and .NET applications created by other developers or spread across many organizations and isolated by heavy-duty firewalls. Each of these systems has different interfaces and different data formats. Some are always accessible, and some are available only transiently. Some interactions are vitally time sensitive, and some aren't. It's like a railway through a jungle—hard enough to navigate to begin with, but even worse when most of the tracks are a different gauge. The task of the enterprise integrator is to keep the traffic moving effectively.

In earlier chapters, we talked about remote procedure calls and web services as an approach for addressing integration issues. This chapter focuses on solving these problems by using messaging to create more flexible, less tightly-coupled systems.

Messaging is an important component in an increasingly service-oriented enterprise environment. In the past, providing the same service to multiple applications involved either rebuilding it each time or developing custom integration software. Messaging makes it easier to build or purchase specialized tools for particular applications, since a variety of applications can share a single expensive resource without each development team having to spend a lot of time developing interfaces.

Messaging provides great new opportunities to enterprise designers. Of course, there is a drawback: messages are by nature asynchronous. Messages sent by one application to another don't immediately arrive at the recipient, and the sender doesn't have any automatic confirmation of delivery. Of course, this situation can work to your advantage: you don't need 100% uptime for every system and network in your organization. And it's surprising how many applications don't require an immediate response, as long as the message is delivered.

On the integration front, centralized Extract, Transform, and Load (ETL)^[1] applications have begun to incorporate messaging support to support multiple different applications sharing a single ETL server. The systems accept commands and input data from messages. In custom development, applications that require expensive or difficult-to-maintain software can be centralized as well: if 10 web applications need to send faxes, a centralized fax server can provide that service to all of them, rather than requiring a fax modem on each web server with all the attendant hardware and administration. The web applications, whether running on Solaris, Linux, or something else entirely, can communicate with the fax service via messaging.

^[1] ETL applications provide data translation and conversion for integration activities: synchronizing data between different schemas, translating from COBOL output files to relational databases, and so forth.

The patterns in this chapter focus on two aspects of messaging. We start by discussing message distribution strategies, including different ways to use a message within an application. The second half of the chapter presents patterns for baking messaging into your applications; they cover retrieving messages from a message service and developing strategies for processing messages in the most flexible way possible.