Spring Integration Overview

1. Spring Integration Overview 1.1 background

An important theme of the spring framework is control inversion. Broadly speaking, spring handles the responsibilities of components that are managed in its context. As long as the components relieve their responsibilities, they are also simplified. For example, dependency injection reduces the coupling of locating and creating dependencies between components. Similarly, aspect-oriented programming decouples business components from common cross-sectional concerns through modular and reusable aspects. In such cases, the end result is that the system is easier to test, understand, maintain, and extend.

In addition, the spring framework and associated toolset provide an excellent programming model for building enterprise-class applications. The consistency of this model is very beneficial to developers, especially when it is based on recognized best practices, such as interface-based programming, using aggregations rather than inheritance. Spring's streamlined abstraction and powerful class libraries, in addition to the system testability and portability of colleagues, have powerfully contributed to the productivity of developers.

Spring integration is a new member of the spring project that adheres to its same goals and principles. It extends the spring programming model to the messaging realm and provides a higher level of abstraction on the basis of the enterprise integration support that spring already exists. It adds control reversals to the focus and supports message-driven schemas, such as when specific business logic should be executed, and the response should also be sent. It supports routing and message conversion, so different transport protocols and different data formats can be integrated without compromising testability. In other words, messaging and integration concerns are handled by the framework, so business components are better insulated from the infrastructure, reducing the complex integration responsibilities that developers face.

As an extension of the Spring programming model, Spring integration provides a variety of configuration options, including annotations, XML supporting namespace, generic bean elements, and, of course, the use of the underlying API directly. These APIs are based on well-defined policy interfaces and non-aggressive proxy adapters. The design of spring integration is inspired by the close connection between the common pattern in spring and the well-known enterprise integration model. The enterprise integration model is described in the 2004 Gregor Hohpe and Bobby Woolf in the book "Enterprise Integration Model" published by Addison Wesley Press. Developers who have read this book should be able to adapt directly to the concepts and terminology of spring integration.

1.2 Goals and principles

Spring integration has the following two main goals:

L provide a simple model for complex enterprise integration solutions

L add asynchronous, message-driven behavior for spring-based applications

• Enables spring users to intuitively and incrementally adopt

Spring integration is based on two principles:

L components should be loosely coupled for ease of modelling and easy testing

The framework should force separation of concerns between business logic and integration logic

The extension point should be abstract in nature and be scoped to a clear boundary to facilitate reusability and portability .

1.3 Main components

Vertically, a layered architecture facilitates separation of concerns, and the interface-based contracts for each layer are loosely coupled. Typically, spring-based applications are designed in such a way that the spring framework and toolset provide a strong foundation for compliance with best practices and full-stack development of enterprise-class applications. Horizontally, the message-driven architecture adds a landscape view, although these goals are still relevant. The layered architecture is a very general and abstract paradigm, and the message system is very much in line with the same abstract "pipeline and filter" model. "Filter" represents any component capable of producing and/or consuming messages, and "piping" transmits messages between filters, so the components remain loosely coupled. It is worth noting that these two high-level paradigms are not mutually exclusive. One of the messaging infrastructures supports packaging "pipelines" to a layer that the contract is defined as an interface. Similarly, a "filter" is typically managed in a layer that is logically located above the service layer of the application system, interacting with those services in the same way through the interface.

News

In spring integration, a message is a generic wrapper for any Java object, along with the metadata used by the framework to process the object. It consists of a load and a head. The payload can be of any type, and the head holds general request information such as ID, timestamp, expiration time, and return address. The head is also used to transmit values between various transmission protocols. For example, when you create a message from a file that you receive, you can store the file name in the header, which can be used by downstream components. Similarly, if the content of a message is eventually sent to a mail adapter that is externally connected, various attributes (recipients, senders, CC, subject, etc.) can be configured as message header values by the upstream component. Developers can also store arbitrary key-value pairs on the head.

Message Channel

A message channel represents a "pipe" in the "Pipeline and filter" schema. The message producer sends a message to the channel, and the message consumer receives the message from the channel. The message channel thus decouples the message component, and also provides a pointcut for message interception and monitoring.

A message channel may conform to point-to-point mode or publish-subscribe mode. If the channel is a point-to-point mode, publish to each message in the channel, up to only one consumer can receive. If the channel is a publish-subscribe mode, it attempts to broadcast each message to all its subscribers. Spring integration supports both of these modes.

Given that the point-to-point mode and the Publish subscription model define how many messages each message ultimately receives from the consumer, here's an important consideration: Should the channel buffer the message? In Spring integration, the polling channel (Pollable Channels) has the ability to buffer messages in a queue. The advantage of buffering is that it regulates access to message traffic, thus preventing system load overload. However, as its name implies, this adds some complexity, and only a message consumer can receive messages from this channel after the polling is configured. In addition, the subscription channel (subscribable Channels) requires consumers who connect to it to comply with simple message-driven patterns. There are also implementations of the various channels available in Spring integration, which are discussed in detail in section 3.2, "Message channel implementations".

Message Terminal

One of the main goals of Spring integration is to simplify the development of enterprise integration solutions through control inversion. This means that you should not need to directly implement the message consumers and producers, and not need to build and invoke the details of the send receive operation in the message channel. Instead, you only need to focus on specific domain models that you implement based on ordinary objects. Then, with declarative configuration, you can "connect" your domain-specific code to the message infrastructure provided by spring integration. The code responsible for these connections is the message terminal. This is not to say that you must connect directly to your existing app's code. Any existing enterprise integration solution requires some code for integration related, such as Routing and Protocol translation. One of the key points is to achieve the separation of the integration logic and business logic focus points. In other words, as the MVC pattern in a Web application, the goal should be to provide a simple and dedicated layer, transform the incoming request to the service layer call, and then transform the service layer return value to the response received. The next section describes the various message endpoint profiles that deal with these responses, and the next sections show you how spring integration provides a non-intrusive way to use each of the manifesto-style configuration options.

1.4 Message Endpoint

A message endpoint represents a "filter" in the pipeline and filter schema. As mentioned earlier, the main role of the endpoint is to connect the application code to the message framework, and of course it uses a non-intrusive approach. In other words, the application code should be completely unaware of the presence of the message object or message channel. This is analogous to the controller role in MVC mode. Just as the controller processes the HTTP request, the message endpoint processes the message. While the controller is mapped to the URL pattern, the message endpoint is mapped to the message channel. The same goal exists in these two examples: Detach the application code from the underlying settings. These concepts and their various models are discussed in detail in the Enterprise application integration book. Here we only outline the main endpoint types supported by spring integration and their roles. This chapter provides an example code and is elaborated in detail.

Message Converters

The message converter is responsible for translating the content or structure of a message and returning the modified message. The most common converters may be converters that convert message payloads from one format to another (for example, converting from an XML document to a java.lang.String string). Similarly, converters can be used to add, remove, and modify values in the message header.

Filter filters

The message Filter ultimately determines whether the message is sent to the output channel. This simply relies on a Boolean test method that checks whether a message contains a specific payload type, a property value, whether it contains a message header, and so on. If a message is accepted, it will be sent to the output channel, otherwise the message will be discarded (or, in a more restrictive implementation, an exception message should be thrown). Message filters are typically used in conjunction with the Publish subscription channel, where multiple consumers receive the same message, while using filters under certain conditions can reduce the number of messages that need to be processed.

Attention You should be careful not to confuse the "filter" in the "Pipeline and filter" schema mode with the specific endpoint type that selectively restricts the flow of messages between two channels. The endpoints in Spring integration are closer to the "Filters" in the "Pipeline and Filter" schema mode: Any component can be connected to the message channel to send and/or receive messages.

Routing

Message routing is responsible for determining which channels the next message will be received by. Typically, this decision is based on the content of the message and/or the available metadata in the header of the message. A message route is often used as a dynamic choice for dynamically configuring an output channel, either on a message activator or other endpoint that can send a response message. Similarly, message routing provides an active way to be used by multiple subscribers, as described above, relative to the passive message filter approach.

Message decomposition Device

A message decomposition is another type of message endpoint that is responsible for receiving a message from an input channel, splitting the message into multiple messages, and then sending them to the appropriate output channel. A typical example is the decomposition of a composite payload object into a set of messages containing the various sub-payloads.

polymeric device

A collector is basically a mirror image of a decomposition device, which is also a message endpoint that receives multiple messages and merges them into a single message. In fact, aggregators are often used with the decomposition in the pipeline to reduce the number of consumers. Technically, the aggregator is more complex than a decomposition because it needs to maintain state (multiple messages that are aggregated), determine when the entire set of messages are available, and process timeouts if necessary. In addition, in the case of timeouts, the aggregator needs to know whether to send a portion of the message or discard them to a separate channel. Spring integration provides a configurable timeout processing policy, sending partial results over time, or sending to a channel that collects discarded messages.

Service Activator

A service activator is a generic endpoint that connects a service instance to a messaging system. The input message channel must be configured, and then if the invoked service method can return a value, the output message channel may also be provided.

	Attention An output channel is optional, because each message can also provide its unique "return address" header information, which applies to all consumer endpoints.

The service activator invokes some operations on the service object, processes the request message, takes out the payload of the request message, and transforms if necessary (if the method does not require a message-type parameter). When a method of a service object returns a value, the return value is also converted to a response message if necessary (if it is not yet a message). This response message is sent to the output channel. If the output channel is not configured and the return address of the message is available, it is sent to the channel specified by this address.

The request-response "service Activator" endpoint connects to a target object's method to the input-output message channel.

Channel Adapter

A channel adapter is an endpoint that connects a message channel to another system or to a transmission. The channel adapter can be either connected or connected. Typically, a channel adapter can do some mapping between a message and any other object or resource that is sent to/received by another system (file, HTTP request, JMS message, and so on). Depending on the transport, the channel adapter can also construct or modify the value of the message header. Spring integration provides some channel adapters, which are described in the next sections.

An Access "Channel adapter" endpoint connects a source system to a message channel

One access "Channel adapter" endpoint connects a message channel to a target system

Spring Integration Overview