Chapter 2. Message Ingestion

As mentioned in the Preface, Spring Integration is an implementation of Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison Wesley Signature Series), Gregor Hohpe and Bobby Woolf, Addison-Wesley Professional. EIP (short for Enterprise Integration Patterns) defines patterns for many integration challenges, and one of them is the exchange of messages between heterogeneous systems. In this chapter, we will explore patterns and concepts around message exchange.

Heterogeneous endpoints use messaging to communicate. There are primarily three aspects of messaging: messages being exchanged, the endpoints that participate in the communication, and the medium through which messages are delivered. In an EIP paradigm, we define them as messages, message endpoints, and message channels. Let's discuss each one at a time and then we will discuss the pattern.

What is a message? In simplest terms, messages can be understood as a piece of information that can be used as an enabler for intercommunication and collaboration between heterogeneous components. It is composed of primarily two parts: header and payload. Headers contain metadata and commonly require values such as ID, timestamp, and so on, but a header's use can be extended for passing other values as well, for example, a channel name for a router, file components for a filename, and so on. Payload can be of any type: standard Java object, XML, or any custom or user-defined value. It can be a simple information-sharing payload too (for example, a registration module can notify an audit module when a new user is registered), or it can be a command (for example, an administration module can instruct the mail service to notify all the users who've registered for the course), or it can be an event (for example, a mail service that, after sending all the mails, dispatches an event back to the admin module specifying that all the mails have been sent and it's good to go with the next step).

We noticed a pattern here; there is a communication between two components via these messages—in formal terms, we call these components message endpoints. Similarly, we can observe that message endpoints are of two types: producer endpoint and consumer endpoint. As their names suggest, a producer, such as registration module, generates a message in the given example, while a consumer consumes it—for example the audit module in the given example. An endpoint can be a producer as well as a consumer, for example, a mail service. Endpoints are typically smart components that can validate messages before passing them on to the next subsystem or can route, filter, aggregate, transform, or do a lot more so that the message can be in a format expected by the next in the chain.