Where does Spring Integration fit in?

While synchronous communication can take place using either procedure calls or messages, by its nature, asynchronous communication is message-driven. We explored the benefits of the messaging paradigm compared to the service-interface approach, and we found the message-driven approach superior, so here’s what happens next: Spring Integration allows you to focus on the most important part of your system, the logical blueprint that describes how messages travel through the system, how they are routed, and what processing is done in the various nodes.

This is done through a structure of channels and endpoints through which the information-bearing messages travel to carry out the functionality of the application. It’s a very abstract structure. To understand the actions that’ll be taken in response to various messages, what transformations they’ll undergo, or where to send a particular message in order to get certain results, you don’t need to know whether the communi- cation will be synchronous or asynchronous.

Let’s consider the following example:

<channel id="input"/>

<payload-type-router input-channel="input">

<mapping type="siia.fundamentals.Order" channel="orders" />

<mapping type="siia.fundamentals.Notification" channel="notifications" /> </payload-type-router> <channel id="orders"/> <channel id="notifications"/> <service-activator ref="ordersProcessor" input-channel="orders" output-channel="results"/> <service-activator ref="notificationsProcessor" input-channel="notifications" output-channel="results"/> <channel id="results"/>

Without getting into too much detail, this configuration means the following: All requests made to the system are sent to the input channel where, depending on their payload (either Order or Notification), they’re routed to the appropriate services. Services in this context are just POJOs, completely unaware of the existence of the messaging system. The results of processing the requests are sent to another channel where they’re picked up by another component, and so on.

Figure 2.6 provides a visual representation of the same message flow.

The structure doesn’t seem to tell what kind of interaction takes place (is it synchro- nous or asynchronous?), and from a logical standpoint, it shouldn’t. The interaction

37

Synchronous and asynchronous communication

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 interaction model doesn’t affect the logical design of the system (how many channels, what endpoints, how they’re connected). But to improve the performance, you may want to free the message sending thread (which belongs to the main applica- tion) from executing the processing of orders and notifications and do that work asyn- chronously in the background, as seen in figure 2.8.

SEDA The technical name for this design is staged event-driven architec- ture, or SEDA, and you saw it in a previous section.

Both types of channels are configured using the same <channel/> element. By default, its behavior is synchronous, so the handling of a single message sent to the input-channel, including routing, invocation of the appropriate service, and what- ever comes after that, will be done in the context of the thread that sends the mes- sage, as shown in figure 2.7. If you want to buffer the messages instead of passing them directly through a channel and to follow an asynchronous approach, you can use a queue to store them, like this:

<channel id="input"> <queue capacity="10"/> </channel> input orders cations orders processor cations Processor results router

Figure 2.6 Wiring of the order processing system: channels and endpoints define the logical application structure.

input router orders cations orders Processor cations Processor results Order

Order Order Confirmation

Figure 2.7 Synchronous order processing: the continuous line indicates an uninterrupted thread of control along the entire processing path.

38 CHAPTER 2 Enterprise integration fundamentals

Now the router will poll to see if any messages are available on the channel and will deliver them to the POJO that does the actual processing, as shown in figure 2.8. All this is taken care of transparently by the framework, which will configure the appro- priate component. You don’t need to change anything else in your configuration.

The configuration can also specify how the polling will be done or how many threads will be available to process notifications or orders, enabling the concurrent processing of those messages.

In this case, your application is implemented as a pipes-and-filters architecture. 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. In some environments, it might be desirable to implement a full traversal of the messag- ing system as a synchronous operation (for example, if the processing is done as part of an online transaction processing system, where immediate response is a require- ment, or for executing everything in a single transaction).

In this case, using synchronous DirectChannels would achieve the goal while keeping the general structure of the messaging system unchanged. As you can see, Spring Integration allows you to design applications that work both synchronously and asynchronously, doing what it does best: separating concerns. Logical structure is one concern, but the dynamic of the system is another, and they should be addressed separately.

This overview of synchronous and asynchronous communication wraps up our dis- cussion about coupling. Over the years, the effort to reduce coupling and to take advantage of the available communication infrastructure has led to the development of four major enterprise integration styles, which are the focus of the next section.

2.3

Comparing enterprise integration styles

As the adoption of computer systems in enterprise environments grew, the need to enable interaction between applications within the enterprise soon became apparent.

input router orders cations orders Processor cations Processor results Order Order cation cation Order Order Confirmation 1 2 Order Order

Figure 2.8 Asynchronous order processing: the introduction of a buffered channel creates two threads of control (indicated by a continuous line)—delivery to the router takes place in Band processing takes place in C.

39

Comparing enterprise integration styles

This interaction allowed organizations to both share data and make use of functional- ity provided by other systems. Though enterprise application integration can take many different forms, from extract-transform-load jobs run overnight to all-encom- passing SOA strategies, all approaches leverage one of four well-known integration styles:

 File-based integration  Shared-database integration  Remote Procedure Calls  Message-based integration

In this section, we provide an overview of these four integration styles and their advan- tages and disadvantages, noting that although Spring Integration is built on the message-based paradigm, the other three forms are supported by the framework. 2.3.1 Integrating applications by transferring files

The most basic approach is for one application to produce a file and for that file to be made available to another system. This approach is simple and generally interopera- ble because all that’s required is for interacting applications to be able to read and write files. Because the basic requirements for using file-based integration are simple, it’s a fairly common solution, but some of the limitations of filesystems mean that additional complexity may be created in applications having to deal with files.

One limitation is that filesystems aren’t transactional and don’t provide metadata about the current state and validity of a file. As a consequence, it’s hard to tell, for example, if another process is currently updating the file. In general, to work prop- erly, this type of integration requires some strategies to ensure that the receiver doesn’t read inconsistent data, such as a half-written file. Also, it requires setting up a process by which corrupt files are moved out of the way to prevent repeated attempts to process them. Another significant drawback is that applications generally need to poll specific locations to discover if more files are ready to be processed, thus intro- ducing additional application complexity and a potential for unnecessary delay.

Considering these drawbacks, before deciding to use file-based integration, it’s always good to see whether any other integration style would work better. Neverthe- less, in certain situations, it may be the only integration option, and it’s not uncom- mon to come across applications that use it. It’s important in such cases to be diligent and to address the limitations through appropriate strategies, like the ones men- tioned previously, and Spring Integration addresses some of them through its support for file-based integration, as discussed in chapter 11.