Getting to Know Spring Integration

[img_assist|nid=6292|title=|desc=|link=none|align=right|width=108|height=144]This week at SpringONE, the Spring Integration 1.0 general access release was announced. I was lucky enough to have a chance to talk to the project lead, Mark Fisher, about the Spring Integration project. The project provides an implementation of the Enterprise Integration Patterns book by Gregor Hohpe and Bobby Woolf.

James Sugrue: What brought about the need for the Spring Integration project?

Mark Fisher: Many applications require some integration logic such as data transformation and routing among multiple endpoints (e.g. JMS and File). There are a number of ways to address these requirements spanning a spectrum from in-house implementations to heavyweight, and sometimes expensive, ESB products. The in-house approach usually results from the recognition that the full-blown ESB is overkill for the particular problem at hand. In the best of these cases, a clean in-house framework is implemented but adds the burdens associated with maintaining generic framework code rather than focusing on core business problems.

In the worst cases, the integration logic is tangled throughout the business logic leading to overly complex, untestable applications. Through consulting engagements and community feedback, we have frequently encountered these problems and received requests for providing some support as an "extension" of Spring's current offerings such as the JMS and Web Services support. We felt that this demand warranted a pragmatic solution within the Spring portfolio.

The motivation was therefore to provide the thinnest possible layer on top of the Spring Framework that is consistent at the programming model and configuration levels. This enables incremental adoption and does not require any additional dependencies other than the Spring Integration JAR. From a more internal perspective, having our own portfolio project for addressing these concerns allows us to collaborate and provide seamless integration with other Spring portfolio projects and also to focus on support for the deployment of Spring Integration applications in SpringSource dm Server. We will also be providing support in the SpringSource Tool Suite and Application Management Suite.

Sugrue: Does the project implement the entire set of patterns in the Enterprise Integration Patterns book?

Fisher: There is not a direct one-to-one mapping between implementation and pattern, because some patterns are actually high level design concepts (e.g. Pipes and Filters). Also, some are "implemented" in the interaction between components (e.g. Message Sequence). Finally, some of the patterns are implemented as part of another component (e.g. the "Return Address" is stored as a header within a Message).

That said, we do implement most of the patterns that map clearly to a component (e.g. Service Activator, Transformer, Router, Splitter, Aggregator, Wire Tap, Channel Purger, etc).

In many of these cases, what we are actually providing is the adapter that enables a developer to connect an existing POJO to perform the role. The adapter is driven by either XML or Annotation-based configuration (e.g. @Router at method-level). This is essentially why we describe Spring Integration as an extension of the Spring *programming model*. There are similarities with Spring's JMS support and even the Spring 2.5 annotation support for MVC.

There are some "composite" patterns that we plan to implement in future versions such as Routing Slip and Process Manager. We may also provide higher-level support for some composite patterns that are already supported. For example, the "Composed Message Processor" consists of a Splitter, Router, and Aggregator. We already provide support for those 3 individual patterns, but we do not yet provide an implementation of this higher level composite pattern directly.

Sugrue: What is your favourite aspect of the project?

Fisher: The simplicity of the configuration driven model and the increased productivity that results.

Sugrue: Can you give an example of how Spring Intergation simplifies things?

Fisher: Here is a simple example that should clarify how this does simplify integration logic:

<service-activator input-channel="tickers" output-channel="quotes" ref="quoteService" method="getQuote"/>

 

public Quote getQuote(String ticker) {
  ...
}

The Spring Integration Message sent to the input channel would have a ticker String payload, and a component subscribed to the "quotes" channel would receive a Message with the Quote object as its payload.

The channel abstraction also simplifies the use of different transports. For example, we have channel-adapters:

<file:inbound-channel-adapter channel="filesIn" directory="file:/some/directory/"/>

<jms:outbound-channel-adapter channel="jmsOut" destination="someQueue"/>

For more examples, you can check out the reference manual: http://static.springframework.org/spring-integration/reference/htmlsingle/spring-integration-reference.html

Sugrue: Where to from here for Spring Integration?

Fisher: In future versions, we will build upon Spring 3.0 features such as the expression language support. We are also planning to extend our existing integration with other Spring portfolio projects, such as Spring Security and Spring Web Services, and we will be adding integration with additional projects including Groovy and Grails. We have also launched a Spring Extensions project for the addition of Spring Integration adapters beyond those provided within the core distribution.