Spring Integration RC1 hatched: Q&A with Iwein Fuld on key benefits, deployment & future directions

Posted by Dionysios G. Synodinos on Nov 05, 2008

Community

Architecture,

Java,

SOA

Topics

Design ,

Enterprise Architecture

Tags

Enterprise Integration Patterns ,

SpringSource ,

JMS ,

Spring

Spring Integration provides an extension of the Spring programming model to support the well-known Enterprise Integration Patterns. Following the announcement of RC 1 that became available this week InfoQ has a Q&A with SpringSource’s Iwein Fuld on key benefits, deployment scenarios and future directions of Spring Integration.

Spring Integration enables simple messaging within Spring-based applications and integrates with external systems via simple adapters. Those adapters provide a higher-level of abstraction over Spring's support for remoting, messaging, and scheduling. Its primary goal is to provide a simple model for building enterprise integration solutions while maintaining the separation of concerns that is essential for producing maintainable, testable code.

InfoQ discussed with Iwein Fuld about this new addition to the Spring portfolio.

InfoQ: Iwein, what do you think are the key benefits of using Spring Integration?

Traditionally messaging has been introduced into the enterprise in the form of an ESB or at least a JMS broker. This requires the setup of a new environment or large changes in existing applications. Spring Integration is different because it approaches integration from the existing applications view point. It allows developers to declaratively enable asynchronous integration for their application without changing their service implementations.

In our implementation we have taken great care to keep things simple. It is not only important to keep the job that developers have to do to utilize the framework as simple as possible, but it is just as important to keep the code that the developers have to understand when they are debugging as simple as possible.

Like any other part of Spring we keep the plumbing out of application code. So as long as you stick to the simplest rules of concurrent programming - stateless services and immutable objects, it will be a breeze to wire your services to any producer or consumer. You won't have to change your code if you want to switch from JMS to RMI just to name an example.

InfoQ: What could be some common deployment scenarios?

Most commonly people will be using Spring Integration in combination with JMS. Just the simplification of JMS configuration is already a strong argument to start using it. Of course there are other applications, because we don't rely on JMS as a transport mechanism.

For example you could implement a waiting page in a web client using Spring Integration. Many application today block a thread in the server to wait for an external web service call. This can easily be avoided with Spring Integration without a JMS requirement or writing any concurrent code yourself. If you have a rich client that supports push you can even avoid to write your own cache that would be polled by the client.

We saw on the forums that many people have a simple EDA that is based on files being dropped in a directory or an email being sent to a certain address. We have made it very easy to write your own adapters and people have been experimenting successfully with xmmp, osgi, twitter. Because it is so easy to tie things together I expect that Spring Integration is going to help a lot to make the net a more interesting place.

InfoQ: How do you see Spring Integration growing in the future?

First of all we are increasing the variety of our adapters. The Spring Extensions project hosts a dedicated Spring Integration Adapters project that will host different adapters that you can pick and choose from. This gives the community a great way to contribute the adapters that they will find the most useful.

The second thing that we have been experimenting with is to build scalable applications with Spring Integration. Because it enables concurrent processing in a very neat way it would be a good candidate for building Grid Solutions on a multi-core environment. We expect to implement at least some samples for that in the future.

We have been asked if Spring Integration is an ESB many times, and the short answer is No. However it is very easy to build an ESB from the components that we offer. We think that an ESB is usually something that you can better live without, but seems likely that ESB builders will use Spring Integration.

Out of personal interest I have sketched up some ideas to use Spring Integration for auto scaling environments that would work with Amazon EC2. These things seem very promising, but it is usually more important to enterprises to see solutions for their current problems than to follow the latest buzz. I think it is a telling sign that we implemented FTP integration before OSGi. We care about the plumbing problems enterprises have to deal with today.

You can find more information on the Spring portfolio, SOA, Architecture and Enterprise Integration Patterns right here at InfoQ.

• Older >