Getting Started with Spring integration

Why use Spring integration

Spring integration is another API created by the spring framework that is geared toward enterprise application integration (EAI). When it comes to integration, there is no shortage of "solutions": hard-coded Java clients, other ESB products, and more traditional application integration techniques such as Message Queuing. Spring integration has improved on all of the above solutions, and the ways to improve them sometimes have dramatic effects. Spring integration is very lightweight, easy to test, and has little entry thresholds and is conceptually simpler than any "write yourself" solution. In the long run, it is more flexible and adaptable. Once used, you will love it. Spring integration can be used in conjunction with standard technologies such as EJB, RMI, and JMS to allow you to model complex solutions in one place, thereby enhancing the standard technology. This simplifies the use of these technologies to a large extent. Because spring integration is very lightweight (deploying a Spring Integration server with an application without deploying the application to spring integration), it is focused on the development lifecycle (a convenient XML schema for configuration, Friendly Pojo form APIs, strong integration with the spring framework and JEE, so you'll find Spring integration more appropriate than many other ESB offerings.

The spring integration itself is powerful, and there is no doubt that it has strong support from the spring framework. For example, the configuration format is nothing more than a spring schema, which in turn abstracts the bean samples for you. There is nothing magical about the use of Spring integration, and you can confidently write the main (String [] args) method to accomplish everything the XML configuration does. Many of the available support for RPC and messages in spring integration are based on the support of the spring framework. All content in the spring integration configuration file is still the standard spring application context, and, like the usual spring bean, it also benefits from the aspect of dependency injection and runtime availability (Aspect). With spring integration, the application context is the bus. This, for example, makes it possible to rely on solutions that depend on application context events. This is another reason that there is no independent "runtime" because the bus exists as long as the context is available.

Background

Enterprise Application Integration (EAI) is an application technology of data and services between integrated applications. It solves infinite problems, and solutions are almost limitless. Engineers have struggled for decades to create these solutions. It is only recently that we have identified the best practices of principles and have categorized them.

The modern EAI model is usually attributed to the "Enterprise integration Model", Gregor Hohpe and others, which classifies and elaborates many integration patterns that are common to integrated solutions. Hohpe and others have listed four integration styles:

File transfer: Two systems generate files, and the payload of a file is a message processed by another system. One example of this style is to poll directories or FTP directories for files and process the file.

Shared databases: Two systems query the same database for the data to be passed. One example is that you have deployed two ear applications, and their entity classes (JPA, hibernate, etc.) share the same table.

Remote Procedure call: Both systems expose another service that can be invoked. Examples of this class are EJB services, or soap and rest services.

Message: The two systems are connected to a common messaging system, exchanging data with each other, and invoking behavior using messages. An example of this style is the well-known central-radiative (Hub-and-spoke) JMS architecture.

These styles are very different because there is no solution that works well under any circumstances. This causes the entire middleware domain to seek available solutions based on these patterns, often referred to as the Enterprise Service Bus (ESB). The ESB is the final middleman: it knows how to mediate messages on various protocols using various languages.

These architectural styles are different, and they have their own strengths. Generally, the JEE standard is inadequate (and, frankly, any development platform today), and these standards do not provide solutions when integrated with other systems. Given that many projects are maintenance projects, how much of the technology in the new platform uses the old services or functions? It's amazing how little it is.

Jee and later spring have made great strides in simplifying the enterprise programming model. JEE has standardized and commercialized common enterprise issues-database access, remote procedure calls, transactions, authentication, directory services, and so on. In addition to basic RPC and messaging, there is no direct support for EAI solutions in Jee.

JMS, rest, and soap are not platform-independent, but this is false with a single message protocol. For example, there is an old host application, its input, output are stored in some FTP endpoint of the batch file, the solution requires integration of the application is impossible. In simple terms: Today's middleware can handle common problems well, but it is not enough to deal with special cases. For most bulletin boards or e-mail lists, take a subscription process. Typically, users send e-mail to the application, apply the final receive e-mail, resolve the message for "subscribe", extract the sent message, and then send a response after registering the user in the mailing list. The first reaction may be based on cron or the Quartz build timer application to poll e-mail messages, or to check FTP for batch files that are later used. This approach will soon become monotonous and fragile.

Then the complexity will rise sharply. Over time, applications become more important, and the burden of integration with business partners, other applications, and other platforms becomes more expensive. For systems that must be maintained, each integration adds a new channel of point-to-point access between systems. Eventually, the channel that integrates each endpoint becomes a messy, complex architecture that cannot be maintained.

SpringSource's spring integration[2] simplifies programming to improve the standard ESB.

How to consolidate and comb the structure

There are many patterns of enterprise application integration, as well as many protocols that need to be addressed. The spring integration provides the modeling capabilities of an ESB-style solution, but the use of methods and their convenience is not the same as the spring framework. An ESB can provide not only the modeling capabilities of message solutions, but also other different technologies/protocols.