Spring Integration provides an extension of the Spring programming model to support the well known Enterprise Integration Patterns. It embodies some of the finest and most popular design patterns, helping developers to avoid rolling their own. Spring Integration provides a lot of powerful components that can greatly enhance the interconnectivity of systems and processes within an enterprise infrastructure.

Goals and Principles

Spring Integration is motivated by the following goals :

• Provide a simple model for implementing complex enterprise integration solutions
• Facilitate asynchronous, message-driven behavior within a Spring-based application
• Promote intuitive, incremental adoption for existing Spring users

Spring Integration is guided by the following principles :

• Components should be loosely coupled for modularity and testability
• The framework should enforce separation of concerns between business logic and integration logic
• Extension points should be abstract in nature (but within well-defined boundaries) to promote reuse and portability

Main Components

From a vertical perspective, a layered architecture (i.e., domain (entities) layer, dao (repository) layer, services layer, application layer) facilitates separation of concerns, and interface-based contracts between layers promote loose coupling. Spring applications are typically designed that way, and Spring Framework provides a strong foundation for following this best practice for the full stack of an enterprise application. Message-driven architectures add a horizontal perspective, yet the same goals are still relevant. Just as “layered architecture” is an extremely generic and abstract paradigm, messaging systems typically follow the similarly abstract “pipes-and-filters” model. The “filters” represent any components capable of producing or consuming messages, and the “pipes” transport the messages between filters so that the components themselves remain loosely-coupled. “Layered architecture” and “pipes-and-filters” are not two mutually exclusive paradigms. The underlying messaging infrastructure that supports “pipes” should still be encapsulated in a layer whose contracts are defined as interfaces. Likewise, the “filters” themselves should be managed within a layer that is logically above the application’s service layer, interacting with those services through interfaces in much the same way that a web tier would.

Message

In Spring Integration, a message is a generic wrapper for any Java object combined with metadata used by the framework while handling that object. It consists of a payload and headers :

public interface Message<T> {
        T getPayload();
        MessageHeaders getHeaders();
}

Message headers is a key-value container that can be used to transmit metadata. Message payload is the actual data that is of value to be transferred.

Channel

A channel in Spring Integration is the basic plumbing in an integration architecture. It’s the pipe by which messages are relayed from one system to another. It can be thought of as a literal pipe through which an integrated system or process can push messages to (or receive messages from) other systems. Point-toPoint (P2P) channels are used to establish 1-to-1 communication lines between systems or components. One component publishes a message to the channel so another can pick it up. There can be only one component at each end of the channel. Publish-Subscribe (Pub-Sub) channels are used to establish a one-to-many communication line between systems or components.

Bridge

A Bridge in Spring Integration is used to connect two message channels if for any reason they can’t connect directly. For instance, to connect Pub-Sub channel to several different P2P channels (because P2P and Pub-Sub channels can’t be connected directly).

Service Activator

The Service Activator is any POJO that defines the @ServiceActivator annotation on a given method. This allows to execute any method on a POJO when a message is received from an inbound channel, and it allows to write messages to an outward channel.

Adapter

The Adapter is an enterprise integration pattern-based component that allows one to “plug-in” to a system or data source. Adapters fall into two broad categories – inbound and outbound.

• Inbound adapters are used to bring in messages from the external system. @InboundChannelAdapter annotation marks the bean configuration as an adapter – its value attribute points to the channel to which the adapter will feed its messages, its poller attribute configures an interval of polling for new messages to feed new messages to channel
• Outbound adapters are used to send messages outwards. Spring Integration supports a large variety of out-of-the-box adapters for various common use cases