SpringIntegrationRamble

Why SpringIntegration

Translated from JoshuaLong, Getting Started With Spring Integration

Spring Integration is another framework created under the Spring system, aimed at enterprise application integration (EAI). Speaking of integration, there is no shortage of "solutions": hard-coded Java clients, other ESB products, and more traditional application integration technologies such as message queues.

Spring Integration has improved the above solutions. Spring Integration is very lightweight and easy to test; it has almost no entry barriers, and is conceptually simpler than any "written by yourself" solution. In the long run, it is more flexible and adaptable. Once used, you will fall in love with it.

Spring Integration can be used in conjunction with standard technologies such as EJB, RMI, and JMS, allowing you to model complex solutions in one place, thereby enhancing standard technologies. This greatly simplifies the use of these technologies. Because Spring Integration is very lightweight (imbed directly into SpringApp) and pays great attention to the development life cycle (configurable XML schema, friendly POJO form API, powerful integration with Spring framework and JEE), you will find that Spring Integration is more applicable compared to many other ESB products.

Spring Integration is powerful in itself and there is no doubt that it has strong support from the Spring framework. For example, the configuration format is nothing more than Spring schema, which in turn abstract the bean example for you. There is nothing special about using Spring Integration. You can write SpringIntegration code like other Spring applications.

Many of the available support for RPC and messages in Spring Integration are based on the support of the Spring framework. Everything in the Spring Integration configuration file remains a standard Spring application context, and like the usual Spring beans, it benefits from dependency injection and runtime availability aspects (Aspect). With Spring Integration, the application context is the bus. For example, this can make solutions that rely on application context events possible. This is another reason why there is no standalone "runtime" because the bus exists as long as the context is available.

Background

Enterprise Application Integration (EAI) is an application technology that integrates data and services between applications. It can solve many problems and the solutions are diverse. Engineers around the world have been working hard to create these solutions for decades. Just recently, we have identified best practices for principles and categorized these programs. The modern EAI model is usually attributed to the Enterprise Integration Model, edited by Gregor Hohpe and others, which classifies and elaborates on many of the integration models that integrate integration solutions. Hohpe et al. listed four integration styles:

• File transfer: Two systems generate files, and the payload of the file is the message processed by another system. One example of this class style is to poll a directory or an FTP directory for a file and process the file.
• Shared database: Two systems query the same database to obtain the data to be passed. An example is that you deploy two EAR applications whose entity classes (JPA, Hibernate, etc.) share the same table.
• Remote procedure call: Both systems expose another service that can be called. Examples of this class include EJB services, or SOAP and REST services.
• Message: Two systems are connected to a common messaging system, exchange data with each other, and utilize message calling behavior. An example of this style is the well-known hub-and-spoke JMS architecture.

These styles are very different because there is no solution to all problems. This leads to the entire middleware field seeking available or better solutions based on these patterns, often referred to as Enterprise Service Bus (ESB). ESB is the ultimate agent: it knows how to mediate various messages delivered on various protocols using various languages.

These architectural styles are different, and they each have their own strengths. In general, there are shortcomings in JEE standards (frankly, any development platform today is the same), and these standards do not provide solutions when integrating with other systems. Considering that many projects are maintenance projects, how many technologies in the new platform will use old services or features? Very few!

JEE and later Spring have made great progress in simplifying the enterprise programming model. JEE has standardized and commercialized common enterprise problems—database access, remote procedure calls, transactions, authentication, directory services, and more. Apart from basic RPC and messaging, there is no direct support for EAI solutions in JEE.

JMS, REST, and SOAP are all platform-agnostic, but this assumes there is a single messaging protocol. For example, there is an old host application whose input and output are batch files stored on some FTP endpoints. It is impossible to integrate the application if the solution requires. Simply put: today's middleware can handle common problems well, but there are some shortcomings in handling special cases.

The complexity will rise sharply afterwards. Over time, applications become more important, and the burden of integrating with business partners, other applications, and other platforms has become more expensive. For systems that must be maintained, each integration adds a new point-to-point channel between systems. Ultimately, the channels integrating each endpoint will become a mess and complex architecture that cannot be maintained.

SpringIntegration simplifies programming, thereby improving standard ESB.

Consolidate Architecture

How to unify enterprise-level application integration solutions and eliminate architectural barriers?

There are many modes of enterprise application integration, and there are also many protocols that need to be processed. Spring Integration provides modeling capabilities for ESB-style solutions, but its usage and convenience are no different from the Spring framework. ESB not only provides modeling capabilities for messaging solutions, but also has different technologies/protocols.

ESB service

Most ESB products have some commonalities. The most important ones are:

• Routing: Can route messages according to conditional logic or configured routing rules.
• Message delivery: For any complex solution, it is crucial to convert the payload of a message from one type to another. In messaging, the standard data model pattern requires the system to provide a common format. Processing messages is naturally another important part of ESB.
• Mediation: Adapter and service mapping.
• Complex Event Processing (CEP): The ability to process events on the bus as aggregation based on correlation.
• Call: This should be the most obvious one. Every ESB must be able to consume and provide services.

In addition to the services listed above, ESB usually also includes mechanisms such as logging, auditing, authentication (security) and management. If your needs are more complex, then ESB will provide great value. It's valuable to compare what you've already obtained on the JEE platform with what ESB can bring to you.

Popular Solutions

Spring Integration is a new thing and of course it will be questioned.

Mule is a very popular ESB product that deserves close attention. Mule seems to have a lot of influence and is impressive in the flexibility of the solution. Open source extensions implemented through MuleForge make it a compelling choice for nearly every problem. It is a standard server: able to deploy and run solutions. Maven plug-ins contribute to the life cycle of development.

ServiceMix is ​​also popular. ServiceMix was originally based on the Java Business Integration Specification (JBI; JSR 208[9]). JBI is the JCP specification for building ESB products. ServiceMix is ​​not as flexible as Mule due to its JBI, but it is being improved. Containers are turning to OSGi infrastructure.

There are no other valuable ESB products listed here, and if you have the chance, you should still learn more about them. Some are very valuable and worth studying.

Spring Integration performs well out of the box and is very easy to use. The development use cases are very eye-catching: If you have been spoiled by POJO and test-friendly frameworks in recent years, this framework is also your best bet. You can use interfaces or standard framework classes as long as you want, and you can also completely encode POJO and your domain model, or you can use both.

Getting Started

Spring Integration applications are simple Java programs configured using Spring schema. If you tend to configure everything with regular Spring configurations, you can do without schema. Schema will make things simpler, which is roughly the same as using schema to configure transactional capabilities in Spring. Spring Integration provides convenient schemas for general concepts (integrated namespaces), as well as adapter specific configurations, such as configurations for message queues, email or file types.

Overview

Spring Integration Applications process the concept of messages delivered from the channel. The life cycle of a message begins with an endpoint, usually a reaction to the adapter. During the process of passing through the processing pipeline, messages will be converted, routed to other channels, distributed, responded, or interrupted and sent to a dead message channel, that is, the message life is over.

message

The Message class is a wrapper that wraps the payload of the processed messages. Operating on it makes it easy to get the payload and message header. You can type the payload and check and change the message header. Spring Integration does not require you to use the Message interface directly, but should convert it into the data transfer object required by the application.

For example, messages from a file adapter (adapter that can send messages from a file system) may be changed to an instance. For messages from the MQTT adapter, it may be converted from binary to JavaBean.

channel

Messages are passed in a channel, and the channel is always passed from one end to the other. For example, the message often starts with the adapter and flows into the channel. After some columns of operations, the message leaves the channel and completes its mission.

There are multiple components in the channel:

• Converter: Get the message content (i.e., load), and change the message itself. For example, when entering the channel, it is a binary message of MQTT, and then it becomes a JavaDomainBean or something else. After the conversion, the message will continue to go down
• Filter: Filter out messages that need to be processed according to their own business requirements.
• Router: Send processed messages to other SpringIntegration components, or SpringService, or even Events. . . The host of SpringIntegration is SpringApplicationContext, so all accessible places in the IOC container can be the next destination of the message
• More components. . .

consume

There are two ways to consume messages. The first is streaming processing method; the second is to use @ServiceActivator annotation.

flow

package ;
 import .;
 import .;
 import .;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import .slf4j.Slf4j;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import ;
 import static .DYNAMIC_RESOURCE_INFO_HASH;
 import static .NEED_SAVE_AIRCRAFT_STATE;
 import static .*;
 @Slf4j(topic = "biz-logger")
 @RequiredArgsConstructor
 @Configuration
 public class BizOsdRouter {
 private final RedisTemplateGeneric<OsdDeviceDto> redisTemplateGeneric;
 @Bean
 public IntegrationFlow bizOsdRouterFlow() {
 return IntegrationFlows
 from(ChannelName.INBOUND_OSD)
               .transform(, source -> {
 try {
 TopicOsdRequest response = ().readValue((byte[]) (), new TypeReference<TopicOsdRequest>() {
                         });
 ("custom router" + ());
                                         String topic = (().get(MqttHeaders.RECEIVED_TOPIC));
 return (((THING_MODEL_PRE + PRODUCT).length(), (OSD_SUF)));
                     } catch (IOException e) {
 throw new CloudSDKException(e);
                     }
                           }, null)
                 .<TopicOsdRequest>handle((response, headers) -> {
 ("Raw data={}", (response));
 Long timestamp = ();
 String deviceSn = ();
                                 Object data = ();
                                 String needSaveKey = NEED_SAVE_AIRCRAFT_STATE;
 Integer needSave = 1;
 if ((().hasKey(needSaveKey))) {
 needSave = (Integer) (needSaveKey);
                     }
 if (null != data && needSave == 1) {
 ("Raw data-data: {}", (data));
 JSONObject dataObj = ((data));
 JSONArray cameras = ("cameras");
 JSONObject camera = (0);
 String payloadIndex = ("payload_index");
 JSONObject payload = (payloadIndex);
 Double pitch = ("gimbal_pitch");
 Double roll = ("gimbal_roll");
 Double yaw = ("gimbal_yaw");
                             OsdDeviceDto osdDevice = ((data), );
 (timestamp);
 (deviceSn);
 (new Timestamp(timestamp).toLocalDateTime());
 (());
 (yaw);
 (pitch);
 (roll);
 ("Get osdDevice:{}", (osdDevice));
 Double longitude = ();
 Double latitude = ();
 //Convert 84 coordinates to baidu09 coordinates
 double[] coord = CoordinateTransform.transformWGS84ToBD09(longitude, latitude);
 //Converted longitude
 (coord[0]);
 //Converted latitude
 (coord[1]);
 String key = (deviceSn);
 ("osdDevice after latitude and longitude conversion:{}", (osdDevice));
                                 ().leftPush(key, osdDevice);
 //Seave 15 pieces, insert data from the left, and delete the excess
                                 ().trim(key, 0, 14);
 //Save latitude and longitude into dynamic resource redisKey
                                     ().put(DYNAMIC_RESOURCE_INFO_HASH, deviceSn, () + "," + ());
 ("Save redis successfully");
                     } else {
 ("The data in the mq message body is empty, or the drone real-time state data is not required (the value of need_save_aircraft_state in redis is 0)");
                     }
 GatewayManager gateway = (());
 OsdDeviceTypeEnum typeEnum = ((), ().equals(()));
 ("gateway={},typeEnum={}", (gateway), (typeEnum));
 return (().convertValue(data, ()));
                               })
                 .<TopicOsdRequest, OsdDeviceTypeEnum>route(response -> (().getClass()),
                                 mapping -> (()).forEach(key -> (key, ())))
                 .get();
     }
 }

ServiceActivator

@ServiceActivator(inputChannel = "inputChannel")
public void handleMessage(Message<?> message) {
    ("Received message: " + ());
}

Fall Short

Spring Integration is brand new and powerful. You can have confidence in the value of SpringSource behind it and its continuous development. But that doesn't mean it is perfect - it's still far from perfect!

Application integration is not a new field, and it has been decades of consideration for solutions and architectures. Some usages of application integration include heavyweight adapters by convention, such as those integrated with SAP or JDEdwards OneWorld. Spring Integration cannot directly support these specific situations.

Although Spring Integration supports a lot of out-of-the-box features, it lacks support for some typical adapters, such as SFTP, HTTPS, or AS2.

Currently, some proprietary solutions can better support these needs. Some solutions are very expensive, so you can try to revamp third-party libraries for Spring Integration and write your own adapters. If you are interested, you will be surprised that writing an adapter for Spring Integration is quite simple. If you want to start creating solutions,

Based on various circumstances, it may end up being Spring Integration may not be your best solution right now.

Conclusion

Spring Integration is a clean, concise EAI method and a good replacement for ESB products. Today's ESB solutions are heavy and difficult to introduce into some environments. Spring Integration is a powerful, low-friction alternative that gently solves some of the most complex integration problems.

Quote

• /articles/Spring-Integration-Joshua-Long/