Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Spring Integration 2.0 Released

Spring Integration 2.0 Released

This item in japanese

SpringSource has just released Spring Integration 2.0. Spring Integration is a lightweight framework to help build event-driven and messaging oriented applications in the familiar Spring style. InfoQ caught up with project lead Mark Fisher to talk to him about the new release.

InfoQ: What is Spring Integration? What kind of problems does it solve?

Mark Fisher: Spring Integration extends the Spring programming model into the domain of Enterprise Integration Patterns as described in the Enterprise Integration Patterns book written by Gregor Hohpe and Bobby Woolf. At a high-level, the framework has two categories of functionality. First, it provides an API for lightweight messaging within Spring-based applications including configuration driven support for the core Enterprise Integration Patterns, such as Routers, Splitters, and Service Activators. Second, it provides support modules for integrating with external systems via declarative adapters. Those adapters provide higher-level abstractions over the core Spring Framework's support for remoting, messaging, and scheduling. But, as with Spring in general, the number one goal of Spring Integration is to provide a simple model for building applications - enterprise integration solutions in this case - while maintaining a clean separation of concerns so that the code is maintainable and testable in isolation.

InfoQ: Why couldn't I just use the MessageListenerContainer and other libraries directly?

MF: Well, first, for those who don't know already, the Spring Framework's MessageListenerContainer does indeed provide nice support for JMS where the listeners can be POJOs, and the application can run in any environment, including a standalone application bootstrapped by a main method or even a unit test. In fact, that support provided one of main inspirations for Spring Integration. We essentially decided it would be nice to have a similar model but at a higher level of abstraction. Instead of JMS Destinations, we define generic Message Channels. Those might exist only locally, within a single process, or they might be connected to a Channel Adapter that does actually map to a JMS Destinations, or handle any number of other APIs, protocols, or transports. Just as one example, the Spring AMQP project now applies that same model of a MessageListenerContainer to AMQP based message brokers like RabbitMQ.

So, with Spring Integration you can simply swap out a JMS Channel Adapter for an AMQP Channel Adapter, and nothing else changes. The Message Channel is still the same, and our Message objects are mapped to and from the transport-specific formats. The same technique goes beyond traditional messaging solutions as well. For example, if you want to "listen" to a directory on the File system, you can plug in our inbound File Channel Adapter. It polls behind the scenes based on the trigger that you configure, and then for each File that arrives, it publishes a Messages that contains that File object as its payload. If you want to publish Messages that in turn send emails, you can use our SMTP Channel Adapter. If you need to invoke a Web Service, you can send a Message containing the request and receive a Message containing the response. So, getting back to the original question, of course you could write code that uses the JavaMail API directly, and you could write code to scan a directory and detect new files, but with Spring Integration, it's as simple as configuring components in a message flow. All of the adapters apply the same general patterns, enabling a consistent style of configuration-driven connectivity for the source and target systems. Essentially, the power of Message-driven POJOs as supported by the core framework now extends to any of the adapters.

InfoQ: why would I use it over framework X?

MF: Spring Integration is a first class member of the Spring platform. It's built on top of the core Spring framework, and it reuses the component model and many of the abstractions provided by the framework and other projects within the platform, such as Spring Web Services and Spring Security. For those who want to explore the API, just check out the code and have a look. It is open source after all. We hope that you will notice the same readability and simplicity for which Spring has earned a reputation. Other than the actual API design, the most important distinguishing feature, in my opinion, is the degree to which Spring Integration provides consistency if you are already using Spring. If you know how to configure transactions for Spring, the exact same configuration applies within Spring Integration. The same applies to Lifecycle-management, thread-management, task scheduling, monitoring and management via Spring's JMX support, and so on. Then, there are all of the adapters, building on Spring's JMS support, Web Services support, RestTemplate, JdbcTemplate, Mail Sender, et cetera. Anyone who has worked with those service abstractions in Spring would recognize, in addition to the template pattern, the common use of the Strategy pattern. Well, the same strategy interfaces that Spring developers already know and may have already implemented are also in use within Spring Integration, such as the JMS MessageConverter, the JMS DestinationResolver, the HttpMessageConverter, the JDBC RowMapper, and many more. So, to answer the question, other frameworks do integrate with Spring at some level, but it's often limited to looking up beans from a Spring ApplicationContext or building upon Spring's Dependency Injection and AOP support. There is just no contest when it comes to the degree of reuse and consistency. If you want to rely on Spring's PlatformTransactionManager or TaskExecutor implementations, Spring Integration is already using those exact same strategies. Spring users will be pleased when they recognize that same degree of reuse throughout the framework, and of course it helps flatten the learning curve. As far as other frameworks are concerned, they typically avoid a direct dependency on Spring within their core. For Spring Integration, Spring is the core. That's one of the main reasons we created the project in the first place.

InfoQ: Is Spring Integration an ESB?

MF: No. Spring Integration is a framework, but it does enable solutions to the types of problems that make people consider an ESB. Obviously, a big distinction is that it is not itself a "server". Rather, Spring Integration applications are just Spring applications with some extra "beans" that can be run in any server. Another distinction is that we emphasize messaging over services. Personally, I think a lot of unnecessary pain has been tolerated over the years from trying to push RPC model where messaging would be more appropriate. So, we typically describe Spring Integration as an "embedded message bus" since all of the integration components are simply Spring-managed objects and can run anywhere you can run a Spring application. We also aim to be a developer-friendly alternative to ESBs. Because Spring Integration reuses the Spring idioms that so many developers know and appreciate, the learning curve is relatively flat. Just include whatever Spring Integration JARs you need, and define some components within your configuration.

InfoQ: How does Spring Integration relate to other Spring platform projects besides the core framework?

MF: Spring Integration does build on many other SpringSource projects. There is support for Web Services through Spring Web Services and security through Spring Security. Spring Integration and Spring Batch fit together quite nicely for event-driven batch processing and batch jobs that take advantage of EIP patterns such as Scatter/Gather. There's also support for Spring Integration Message Channels on the server side of Flex applications when using the Spring BlazeDS Integration project. All of those are available as of this 2.0 release. As far as tool support is concerned, developers using the latest SpringSource Tool Suite version already have an amazing visual editor for Spring Integration message flows. We are continuing to build on new Spring projects as well. For example, in the sandbox we are building support for AMQP through Spring AMQP and Gemfire through Spring Gemfire. Also in the sandbox, there is a workflow gateway that integrates with the Alfresco Activiti project, an open source Apache 2 licensed BPMN 2 implementation. We are also working on two Spring Roo addons, one for building Spring Integration applications and another for actually creating new Spring Integration adapter projects.

InfoQ: why would I upgrade to 2.0 if I'm a 1.0 user? What are some of the big new features?

MF: First of all, we are taking advantage of and exposing some powerful new features of Spring 3.0. Probably the most obvious is the ability to use the Spring Expression Language across many of our components. As an example, if some transformation or routing logic is simple enough to be captured in an expression, then it's not necessary to even define a POJO for that logic. Similarly, we now support Groovy scripts for any of the core EIP components. Another Spring 3.0 feature is the Trigger strategies that are used by TaskSchedulers. Another addition that takes our POJO-centric model even further is the annotation-based, AOP-driven message publisher which supports Message publication as a by-product of any method invocation without requiring any direct dependency on the framework. Starting with Spring Integration 2.0, we also provide support for many additional Enterprise Integration Patterns, such as Message History, Message Store, and Claim Check. The Message Store alone is rather useful, providing storage options for stateful Aggregators relying on either a database or a distributed cache like Gemfire. The Message Store actually backs the Claim Check as well. Moving beyond the core, we have added many new adapters, such as TCP, UDP, JDBC, FTP, SFTP, XMPP, RSS, and Twitter.

InfoQ: if people want to ask questions or feedback, where can get they get access to the code, forums, and JIRA (...)

MF: The home page is at, and that provides all of the relevant links. There they can find where to download the distribution, how to configure their Maven POMs, how to build from source, where to access the reference manual, where to report issues, and where to post questions. Beyond that we provide a number of links there to blogs and articles about Spring Integration.

InfoQ: will you start working on SI 3 tomorrow, or will there be iterations? How frequently should we expect iterations? For example, Spring 3.1's due any minute now :-), will there be an update that aligns with that?

MF: The next release will build on Spring 3.1, which is due in the first half of next year. A lot of the functionality in the sandbox should be included in the next release as well. We're not only building on Spring 3.1. Many of the modules in the sandbox build upon other relatively new additions to the platform that will be having their first GA releases during the first half of next year as well. For example, we have Channel Adapters that build directly on top of the Spring AMQP project. We also have adapters and Message Store implementations that build on top of the Spring GemFire project. There are many more interesting extensions in the works, including support for a wide variety of "NoSQL" data stores as well as social media and mobile platforms. Wherever it makes sense to provide some higher level support via Spring Integration, you can expect that we will be doing exactly that.

Rate this Article