As the Spring Integration project slowly gains more adoption and interest, developers in the enterprise integration or enterprise development space will most likely come across it. They may find it interesting, but not fully understand what it is, what problems it was created to solve, where they can get more information, and where it fits within the open-source ecosystem of ESBs and other SOA infrastructure. Here’s my attempt at a normal-person’s description of what it is.
Up first, what is it?
It’s an open-source project commissioned by SpringSource to leverage the current capabilities of the Spring Framework to focus on the problems found in the application-integration space. Without a concrete example, or a more fundamental understanding, that last sentence is probably just as vague as the other information you may have seen about Spring Integration or integration in general. So let me go into a little more detail to help make that statement a little less vague.
So why did the Spring folks decide to create a project specifically focused on integration? Doesn’t the Spring Framework itself provide a lot of that already? Spring does have fantastic abstractions for dealing with JMS, JDBC, transaction management, object-xml mapping, http/rmi invocation, and many others. It also provides a dependency-injection based framework which promotes cleaner, decoupled, and easier to test code. But if you take a step back and realize what Spring provides it really is just general purpose building blocks, a component model, that can be used in a limitless variety of solutions. So when it comes to system/application integration, you could implement your own, very capable, solution using these building blocks. However, application integration, and the problems inherent in solving those problems are not new. There are quite a few “patterns” that emerge once you’ve experienced a handful of attempts at integrating two systems for data exchange, process invocation, event notification, etc. These patterns were very well captured by Gregor Hohpe and Bobby Woolf in their timeless book “Enterprise Integration Patterns.” As I’m sure I’ve mentioned in previous blog posts, I highly recommend this book for anyone in the enterprise development space. These patterns are well known and proven for addressing most integration problems.
The Spring folks decided to take the building blocks of their Spring Framework and the patterns presented in Hohpe’s book to create a more-focused framework that specifically deals with integrating applications.
So what are the problems in the integration space? Like I said, they are described far better than I can in EIP, but here’s a simple description of a problem that is almost always present. Two applications need to share a piece of data, for example, a customer report which is originated on system A needs to be available in another system B. System A can only communicate with outside applications through a direct TCP connection and system B has a simple web-service for loading report information to it and is unwilling to change to anything else. How do you go about doing this? You could write some custom integration “glue code” that runs periodically: set up a batch process or a cron job, break out Java’s socket, or socket-nio libraries, connect up to system A, read and write to an input stream, grab the useful data, convert it to some kind of intermediary format, map some of that data to a SOAP xml message so that system B can understand it, break out AXIS or HttpCommons and send the xml to system B. A lot of the coding involved in creating this integration can be classified as infrastructure and not really “custom.” For example, connecting to TCP and reading/writing streams. Why should we have to write that code? There’s nothing custom about that. Delegate that to a framework/library. What about the polling to see whether an application is available? Delegate that too, that’s not a custom concern. And the webservice call? Generic components for TCP communication, polling or event handling, Web Service calls, routing and transforming, and many others. is exactly what Spring Integration provides. And it tries to mimic the full power of the patterns described in the EIP book while using a component model familiar to previous Spring Framework users.
One question that I find comes up a lot in discussions about “what is Spring Integration” is how does it relate to an ESB or SOA architecture, and if one were to do an analysis about Spring Integration vs its competition, what specifically is its competition? First, Spring Integration is NOT an ESB. It is a *routing* and *mediation* framework. When i say it’s a mediation framework, I mean that it allows two different systems with different messages and protocols to talk with each other by “mediating” the message: resolve/negotiate differences between the two so they can exchange data. This mediation and routing framework can be used anywhere and doesn’t need to be deployed into a heavyweight ESB container, or any ESB container. It can be deployed within in application (either stand alone application or part of a Java EE solution within an application server), within an ESB if you need, as part of a message broker, etc. It’s flexible regarding deployment. Spring Integration itself should not be compared to ServiceMix, MuleESB, TIBCO, IBM or Oracle’s ESB solutions or other ESBs. One open-source project that comes to mind that would be a fair comparison is Apache’s Camel project which too is a mediation and routing engine. Apache Camel is also a very powerful and highly capable solution to the integration problem space and it also implements the patterns from the EIP book. I can do a comparison in a future blog post if readers show interest.
For more information about Spring Integration, I recommend visiting their project page , taking a look at a recent book Pro Spring Integration, and of course reading and fully understanding the EIP book