Software has been an integral part of enterprises and a key contributor to their growth. Be it analytics, user experience, social marketing, decision support systems, or any other functional domain, software has been used to aid smooth and efficient functioning. Enterprises start small and grow over a period of time, and so does their software dependency. Enterprise applications are developed over a period of time. The following aspects pose certain challenges while dealing with enterprise software:
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 files, 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.
Integration of these modules either inside organizations or with external partners is inherently complex, requiring integration of heterogeneous endpoints. This is the kind of scenario that Enterprise Application Integration tries to address. Enterprise Integration Patterns (EIP) is a collection of standard enterprise challenges and how can they be handled. Spring Integration is one of the implementations of the EIP that provides many off-the-shelf components recommended by EIP.
Many approaches have been tried to make the integration simple without compromising on vital aspects of enterprise, such as security, transaction, availability, reliability, and so on. A few of the prominent methodologies used over time are Java Connector Architecture (JCA), RMI, RPC, and CORBA for platform-agnostic integration, message brokers with system adapter, and many more. Under the hood, they try to solve integration issues through one of the following techniques:
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 tables—one 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.
Remote procedure calls: This mechanism introduces a paradigm where each system can offer services by publishing the contract. These paradigms can be a method, parameters, result, and error. For example, an EJB service or a SOAP service can be exposed for providing raw data for a reporting module that renders it in multiple formats. The most limiting aspect is synchronous behavior, where systems have to wait for the result. There are other challenges such as serialization of data, network latency, performance issues of a module, which can bring down the whole application, and so on. From a security aspect, exposing the method name and parameter invites hackers to exercise their creativity.
Messaging: This introduces the asynchronous model in which two heterogeneous modules can interact through data over a predefined connection. The greatest advantage is decoupling—none of the systems are dependent on the availability of the other and they can participate or withdraw from integration without impacting other components. JMS is an example of message-based integration. Spring Integration is based on this paradigm where multiple endpoints connect on to a channel, produce or consume messages, and perform further processing based on information in a message. We will deal with channel, endpoints, message payload, and other concepts in the upcoming chapters.
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.
As we have been discussing, the problem of enterprise integration is complex and many vendors have tried to address it in their own propitiatory ESB framework—earlier it used to be dominated by commercial vendors such as Tibco, Vitria, IBM MQSeries, Oracle SOA Suite, Microsoft BizTalk, and so on. Over time, the need for open source frameworks became evident as smaller organizations grew. Their integration needs were limited and were incapable of investing upfront with any of these biggies.
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 an open source effort to address integration challenges; it is based on the Spring Framework, which is the most widely used Java-based framework in organizations. It introduces the simple POJO-based programming model to support standard integration patterns.
It's lightweight; all it needs is couple of jars for which Maven targets are readily available. A quick comparison shows that the Service Mix download is around 55 MB while Spring Integration is just 14 MB in size.
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 1, Getting Started, explains how to set up the Eclipse IDE, a "Hello World" program, and a brief introduction of how Spring ROO can ease the configuration aspects even further. This will help overcome configuration nightmares and warm up developers to a hands-on experience.
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 processing—waiting 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 Integration—interaction 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.
You need a Java-based IDE, and Spring STS is recommended. JDK 1.6 and above is required.
This book is for developers who are already familiar with basic Java and Spring concepts. Concepts of Enterprise Integration Patterns would be helpful but not mandatory. The book has been presented in a hands-on manner; an end-to-end working example has been picked, implemented, and explained throughout the chapters. This book would serve as a strong companion for new developers trying out their hand on integration aspects, and as a hands-on guide on how to use Spring Integration components for developers already familiar with these challenges and looking for quick samples.
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "Create a Spring Integration project by navigating to File | Spring Project, as shown in the following screenshot:".
A block of code is set as follows:
<int:channel id="resultPersistenceChannel"> <int:queue message-store="messageStore"/> </int:channel> <int-jdbc:message-store id="messageStore" data-source="someDataSource"/>
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
public interface ChannelInterceptor {
Message<?> preSend(Message<?> message, MessageChannel channel);
void postSend(Message<?> message, MessageChannel channel, boolean sent);
boolean preReceive(MessageChannel channel);
Message<?> postReceive(Message<?> message, MessageChannel channel);New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "clicking the Next button moves you to the next screen".
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to <[email protected]>, and mention the book title via the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you. The code can also be pulled from https://github.com/cpandey05/siessentials.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the errata submission form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.