Spring Integration Essentials - Sample Chapter
Spring Integration Essentials - Sample Chapter
Spring Integration Essentials - Sample Chapter
ee
Sa
pl
Acknowledgments
I would like to thank the team at Packt Publishing. Richard, thanks a lot for finding my
blog on Spring Integration and presenting me with an opportunity to share my knowledge
in a more formal way and with a wider audience, and thanks for answering all of my
questions with such patiencea few of which often took pages! I would like to thank
Sharvari and Ritika, who are the content development editors for this book. Sharvari's
support and help with the technical review and incorporation of subsequent feedback was
unprecedented. Aman Preet, the technical editor of the book, did a brilliant job with the
final edit.
The greatest support is not what we see but the silent love and prayers of all our wellwishers. My parents' blessings have always been with me. They are not technical and
they do not understand what I dobut their unflinching confidence in me that whatever I
am doing must be correct not only pumps up my confidence, but also puts a lot of
responsibility on me. I hope I will not disappoint them ever.
Without a supportive family, it's extremely difficult to achieve anything significantand
I consider myself lucky on that front. I am indebted to the charming smiles of my 2-yearold son, Aadish, and my 4-year-old daughter, Aashiryatheir innocent smiles always
remind me that happiness is beyond material success or anything else. As for my better
half, Priyanka, I honestly believe that her work is more creditable than mine. Bringing up
two small kids without any help from me, while at the same time supporting me
throughout this assignmenta simple "thanks" will be too small a word for her, so I will
leave it up to her to understand my gratitude!
They are distributed across a set of domains, for example, payroll, inventory,
reporting, and social integration.
Each of these modules might have been developed independent of each other and
may be on different platforms, for example, employee self-portal in J2EE stack,
legacy records management on mainframes, CRM system using Salesforce, with
some real-time application in their proprietary implementation.
These modules need to interact with each other and with external systems as
well. They may have to consume data from external sources through SOAP
services or shared fi les, or they themselves have to share data though one of
many data-sharing techniques.
As software grows old, we need to introduce new platforms and replace existing
modules to alleviate the growing maintenance cost. A rip and replace strategy
would not work; rather, this should be done in a homogenous way without
disturbing the sanity of existing modules during the transitions.
Shared File: This is the simplest approach. Systems can write data in a
predefined format to a file, which can be read by other endpoints. An adapter
might be needed to convert a format between two different endpoints. Let's
consider an example, a daily report used to be generated in a CSV file. Over
time, the organization established a web presence and reports need to be pushed
online now. How can this be achieved? The simplest way is to dump it in files
that will be read by an adapter and fed into the CMS system. A filesystem is
simple but not the best solution; it is not transactional. What if a particular file is
corrupt, or what if at poll interval files are not available due to network failure?
This necessitates the introduction of a complex system that has a retry
mechanism, filter capabilities, and many more nonfunctional aspects such as
secure access, archival, and so on.
Shared database: This addresses a few of the challenges that are addressed by
the filesystem, such as transactional behavior, role-based access, performance
tuning, distributed support, and so on. The common mechanism is a set of join
tablesone application writes data in a schema that is understood by others. On
the flip side, this introduces tight coupling; if there is a change in schema, both
the systems need to be updated accordingly. Evolving applications will become a
challenge, as they will have to factor in the external system limitations. The
integration effort might itself start with lot of hiccups, for example, compatibility
issues between the SQL provided by database vendors of the application, data
format, and types in their table. For example, if one system stores only the date
while the other stores the date with time stamp, depending on need, at least one
will have to change format.
Even if we use one of the preceding techniques, enterprise systems are way outward from
each other and all of them might not be working all the time. This necessitated the use of
middleware that can orchestrate reliable communication between these disparate
endpoints, typically called an Enterprise Service Bus (ESB). In layman's terms, ESB can
be defined as the middle man who enables communication to and fro between
heterogeneous interfaces.
Some of the prominent open source integration frameworks, apart from Spring
Integration, are Camel, Service Mix, Mule ESB, Open ESB, and so on. A comprehensive
comparison of these frameworks is beyond the scope of this book but a small summary of
two other major open source frameworks, has been provided here for the sake of
emphasizing Spring Integration simplicity:
Mule ESB: It is a standard server, solutions are developed and deployed inside
them. Mule is one of the most prominent and stable solutions on the market. The
point to be observed here is that, it's a container that holds the application.
Service Mix (SM): Apache Service Mix is built over JAVA legacy JBI (Java
Business Integration). Service Mix tries to solve almost all aspects of enterprise
integration by unifying the features and functionality of ActiveMQ, Camel, CXF,
ODE, and Karaf. It provides a complete, enterprise-ready ESB, exclusively
powered by OSGi. Since it tries to address a lot of modules, it is pretty bulky
compared to Spring Integration.
Spring Integration is just a set of standard Java libraries; the solution gets
deployed in the application instead of that application getting deployed in some
containers, as in the case of SM and Mule.
For enterprises that are already using Java and Spring, it eases the integration effort as it
follows the same idioms and patterns of the Spring Framework.
Chapter 2, Message Ingestion, introduces channels through which messages can be read
and processed. It describes the point-to-point and pub-sub models, which one is best
suited for a given scenario, how errors can be handled in a decoupled manner on a
channel, and finally how in-memory channels can be backed up with persistence for
failover and recovery solutions.
Chapter 3, Message Processing, explains how to define components that can apply
business logic on messages, introduces decoupled logging that can used for auditing, and
discusses adding transactional behavior.
Chapter 4, Message Transformers, deals with processing message formats, its conversion
to a homogenous format, and how annotations can help keep the configurations clean.
Messages can be introduced in heterogeneous formats such as XML, JSON, and so on
that need to be converted to a format understood by the system.
Chapter 5, Message Flow, will introduce flow aspects to messages such as filtering
messages that do not comply to validation rules, routing them to an error branch, splitting
messages, and redirecting them to components appropriate for their processingwaiting
for incomplete payloads, aggregating partial messages, and finally the chaining of
business processing handlers.
Chapter 6, Integration with External Systems, will give a hands-on overview of
integration points. Integration with external systems is the most interesting and powerful
aspect of Spring Integrationinteraction with external systems is a matter of a few lines
of configuration. Spring Integration has introduced adapters, gateways, and other
components that make it a breeze to interact with filesystems, SQL, NoSQL persistence
store, HTTP services, and other widely used external entities such as different servers,
social media, and so on.
Chapter 7, Integration with Spring Batch, will introduce how to use Spring Integration
and batch module for scheduling, triggering, and monitoring batch jobs.
Chapter 8, Testing Support, will explain how to leverage the readily available mocks for
different components, what to test, and how much to test.
Chapter 9, Monitoring, Management, and Scaling Up, will cover using Spring
Integration configuration to leverage JMX to get performance statistics of different
configured components in the system. We will also peek into ways to scale up Spring
Integration components.
Chapter 10, An End-to-End Example, has an end-to-end hands-on example that will help
you to recollect concepts introduced in different chapters and reassert their
understanding. Code will be pushed to a social repository as GitHub, but this chapter will
give users enough instructions to use it and run it.
Getting Started
In this chapter, we will set up our development environment and discuss how
we can leverage SpringSource Tool Suite (STS) to its maximum. Although any
popular Java development IDE such as Eclipse, intelliJ, NetBeans, and others can be
used for developing Spring Integration solutions, pivotal, the company spearheading
Spring Integration, recommends that you use STS which is an Eclipse-based IDE.
Setting up STS
STS comes with many off-the-shelf plugins, visual editors, and other features, which
ease the development of Spring-powered enterprise applications. The look and feel
of the IDE is very similar to Eclipse. Install STS by following these steps:
1. JDK 1.6 and above is a prerequisite, download and install it from
http://www.oracle.com/technetwork/java/javase/downloads/javaarchive-downloads-javase6-419409.html.
Getting Started
[ 10 ]
Chapter 1
4. Click on Finish; this will create a project with the name that was provided by
us (sisimple), as shown in this screenshot:
[ 11 ]
Getting Started
This project is as simple as it can be. Let's take a quick look at the generated Java
classes in the following points:
sample. Right-click on this file from the package explorer and click on Run
As | Java Applicationthis will start the program. This class has the code to
bootstrap Spring Integration configuration files and load components defined
in it. Additionally, it converts user input to upper case.
This is the service interface that is used to convert user input to upper case.
service classes.
pom.xml: This is the file used for rmaven dependency management, located
in /sisimple/. It has entries for all the dependencies used by the project.
[ 12 ]
Chapter 1
[ 13 ]
Getting Started
In the same editor, clicking on the Integration-graph tab will open a visual
editor, which can be used to add/modify or delete endpoints, channels, and other
components of Spring Integration. The following screenshot contains the integration
graph for our sample project:
Let's have a quick look at the generated Maven POMoverall, there are three
dependencies; only one for Spring Integration, and the other ones for Junit and
log4j, as shown in the following screenshot:
[ 14 ]
Chapter 1
Summary
In this chapter, you learned how to set up your IDE and created a basic project.
We also tried our hands at the visual editor of STS and covered a quick introduction
of the upcoming Scala DSL for Spring Integration. We will leverage this knowledge
to build a compelling Spring Integration application using STS throughout the rest
of the chapters.
In the next chapter, we will cover how to ingest messages in the application and then
how to process them.
[ 15 ]
www.PacktPub.com
Stay Connected: