Spring Integration - Spring Enterprise Recipes: A Problem Solution Approach - page 311

embodied in a landmark book called Enterprise Integration Patterns , by Gregor Hohpe, Bobby Woolf,
et al. Today the patterns are canonical and are the lingua franca of the modern-day ESB.

How It Works

Picking an Integration Style
There are multiple integration styles, each best suited for certain types of applications and requirements.
The basic premise is simple: your application can't speak directly to the other system using the native
mechanism in one system. So you can devise a bridging connection, something to build on top of,
abstract, or work around some characteristic about the other system in a way that's advantageous to the
invoking system. What you abstract is different per application. Sometimes it's the location, sometimes
it's the synchronous or asynchronous nature of the call, and sometimes it's the messaging protocol.
There are many criteria for choosing an integration style, related to how tightly coupled you want your
application to be, to server affinity, to the demands of the messaging formats, and so on. In a way,
TCP/IP is the most famous of all integration techniques because it decouples one application from
another's server.
You have probably built applications that use some or all of the following integration styles (using
Spring, no less!). Shared Database, for example, is easily achieved using Spring's JDBC support; Remote
Procedure Invocation is easily achieved using Spring's exporter functionality.
The four integration styles are as follows:
• File Transfer : Have each application produce files of shared data for others to

consume and consume files that others have produced.

• Shared Database : Have the applications store the data they want to share in a

common database. This usually takes the form of a database to which different
applications have access. This is not usually a favored approach because it means
exposing your data to different clients who might not respect the constraints you
have in place (but not codified). Using views and stored procedures can often
make this option possible, but it's not ideal. There's no particular support for
talking to a database, per se, but you can build an endpoint that deals with new
results in a SQL database as message payloads. Integration with databases doesn't
tend to be granular or message-oriented, but batch-oriented instead. After all, a
million new rows in a database isn't an event so much as a batch! It's no surprise
then that Spring Batch (discussed in Chapter 9) included terrific support for JDBC-
oriented input and output.

• Remote Procedure Invocation : Have each application expose some of its

procedures so that they can be invoked remotely, and have applications invoke
them to initiate behavior and exchange data. There is specific support for
optimizing RPC (remote procedure calls such as SOAP, RMI, and HTTP Invoker)
exchanges using Spring Integration.

• Messaging : Have each application connect to a common messaging system and

exchange data and invoke behavior using messages. This style, most enabled by
JMS in the JEE world, also describes other asynchronous or multicast publish/
subscribe architectures. In a way, an ESB or an EAI container such as Spring
Integration lets you handle most of the other styles as though you were dealing
with a messaging queue: a request comes in on a queue and is managed,
responded to, or forwarded onward on another queue.