Spring Integration stands on the shoulders of two giants.

First is the Spring

Frame-
work, a nearly ubiquitous and highly influential foundation for enterprise Java
appli-
cations that has popularized a programming model which is powerful because of its
simplicity. Second is the book Enterprise Integration Patterns (Hohpe and Woolf,
Addi-
son-Wesley, 2003), which has standardized the vocabulary and catalogued the
patterns
of common integration challenges.

From the 10,000-foot view, Spring Integration consists of two parts. At its core,
it’s a
messaging framework that supports lightweight, event-driven interactions within an
application. On top of that core, it provides an adapter-based platform that
supports
flexible integration of applications across the enterprise. These two roles are
depicted
in figure 1.1.

Channel Adapter applies to any unidirectional inbound or outbound

adapter. In other words, an inbound channel adapter supports an in-only message
exchange, and an outbound channel adapter supports an out-only exchange. Any
bidirectional, or request-reply, adapter is known as a Gateway in Spring
Integration.

The same holds true for Spring Integration. At the lowest level, it has simple
building blocks based on the pipes-and-filters style.As you move up the stack to
more
specialized components, they exhibit the characteristics and perform the roles of
other patterns described in Enterprise Integration Patterns.

The only point we’re trying to make

so far is that dependency injection plays a role in connecting the collaborating
com-
ponents while avoiding hardcoded references.

Spring Integration aims to provide a clear line between code and configuration.
The components provided by the framework, which often represent the enterprise
integration patterns, are typically configured in a declarative way using either
XML or
Java annotations as metadata. But many of those components act as stereotypes or
templates. They play a role that’s understood by the framework, but they require a
ref-
erence to some user-defined, domain-specific behavior in order to fulfill that
role.

*Enterprise integration fundamentals*

model is determined by the type of channel that’s used for transferring the
messages
between the endpoints. Spring Integration supports both approaches by using two
dif-
ferent types of message channels: DirectChannel (synchronous) and QueueChannel
(asynchronous).

The behavior of each component encapsulates one specific operation (transforma-

tion, business operation, sending a notification, and so on), and the overall
design is
message-driven so that the coupling between components is kept to a low level

*messaging*
you can use Spring Integration’s
MessageBuilder when you need to create a new Message instance.It should be noted
that the MessageBuilder initializes a num-
ber of headers that are needed by default by the framework, and this is one of the
sig-
nificant advantages of using the MessageBuilder over instantiating messages
directly:
you don’t have to worry about setting up those headers yourself.

The reason no methods are provided for receiving messages is because Spring Inte-
gration differentiates clearly between two mechanisms through which messages are
handed over to the next endpoint—polling and subscription—and provides two dis-
tinct types of channels accordingly.

In Spring Integration, the default channels are SubscribableChannel s, and the mes-
sage transmission is synchronous. The effect is simple: one thread is responsible
for
invoking the three services sequentially, as shown in figure 3.2.