Article: Getting Started With Spring Integration

by Abel Avram on Jan 20, 2009 |

In this article, Joshua Long introduces the readers to Spring Integration, an extension of the Spring framework supporting the Enterprise Integration Patterns. After a short introduction into Enterprise Application Integration (EAI), the article presents an example of the integration between an email application and a blogger one.

Read: Getting Started With Spring Integration

Joshua’s integration example allows one to publish an email containing a blog post to a certain address where it is automatically processed and published on the blog. The example focuses on the Spring Integration’s XML configuration which directs the framework to do the messaging job between the two applications.

Resource: the source code.

Related Editorial

Impact of Java EE Frameworks on the Structural Quality of Applications

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

The Rise of the Composite API Platform, a ‘Best-of-Breed’ API Management Solution

Application Performance Management Buyer's Guide

Getting Ahead in the Cloud: The Need for Better Identity and Access Controls

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Re: Getting Started With Spring Integration by Sasa Vender Posted

"Vend" or "Send"? by Dave Macpherson Posted

Great article by Srini Penchikala Posted

Spring Integration vs. Apache Camel by Lari Hotari Posted

Re: Getting Started With Spring Integration by Gaetano Miranda Posted

Do we even need ESB? by Oleg Zhurakousky Posted

SOA without the Complexity by Tom McCuch Posted

Great article... by Adam FitzGerald Posted

Distributed Spring? by Dhirendra Negi Posted

Very interesting by Tai Truong Posted

Application architecture by Kshitiz Garg Posted

Re: Getting Started With Spring Integration by Sasa Vender

Nice article, thanks.

"Vend" or "Send"? by Dave Macpherson

I'm assuming the the word "vend" throughout this article is "send"? Perhaps a quick "vind and veplace" is in order ;)

Great article by Srini Penchikala

Hi Josh, Great article. I was able to run the sample application w/o much extra setup effort. The example is simple but it's a good introduction to Spring Integration framework architecture. SI brings the power of Dependency Injection (DI) that Spring Framework has been famous for and EIP patterns implementation together to nicely manage the resources (there are more than few of these resources when you are working on a real-world asynchronous messaging system) and lets you focus on business logic rather than messaging infrastructure code.

Spring Integration vs. Apache Camel by Lari Hotari

How does Spring Integration compare to Apache Camel (camel.apache.org/)?

Camel uses Spring for configuration (integrates nicely to spring based approach) and it's possible to deploy Camel "applications" to a OSGI container (cwiki.apache.org/confluence/display/CAMEL/tutor...). Is Camel a direct competitor?

Re: Getting Started With Spring Integration by Gaetano Miranda

Nice article. I'd like to remark that I don't think SOAP(doc/lit) and REST are examples of RPC integration style.

Thank You

Do we even need ESB? by Oleg Zhurakousky

"Because Spring Integration is so lightweight (you deploy the Spring Integration server with your application; you don't deploy your application to Spring Integration). . ."

Well said and raises an interesting point.
Do we even need ESB as a product onto which we deploy applications specifically designed around such product or EAI in general should be looked at as an enabling framework used inside of your JEE or any other type application allowing integration concerns to be handled as they arise. Spring Integration allows just that.

SOA without the Complexity by Tom McCuch

Great article, Thank you!

SOA is an architectural pattern. A pattern, by definition, is the encapsulation of a complex system into a reusable component. Patterns are meant to describe "building blocks" for YOUR solution - they are not meant to be solutions in of themselves. Patterns therefore lend themselves to be best implemented by lightweight, embeddable frameworks that serve to support your solution, not heavy, commercial-off-the shelf products that aim to control it. This is where the big vendors have all gone wrong with SOA - and where SpringSource, yet again, has gotten it right with Spring Integration.

Great article... by Adam FitzGerald

Thanks for the great article, Josh. I have added it to the SpringSource community web site. I also want to point out something regarding adapters. If users of Spring Integration want to share the adapters they develop with others they should check out the new
Spring Integration Adapters project in Spring Extensions.

Adam FitzGerald
SpringSource

Distributed Spring? by Dhirendra Negi

Are we heading towards more heavyweights?!

Very interesting by Tai Truong

I am also watching on Spring Integration (SI) from the very beginning and since its release I have succesfully used SI for implementing a lightweight integration platform. It is in production for some customers and runs pretty stable :-).
One of things I like in SI is how they it takes care of many thinks to make integration transparent: it wires all the endpoints together into an integration flow and encapsulates the message processing. It is component-base and I can implement by translators, processors and any other endpoint without a dependency to any Spring class. This I haven't seen from other API like Mule or OpenAdaptor.

In the near future I will post my experiences in my Blog. If you are interested I have also posted a summary about the concepts of Messaging and EI:
taitruong.wordpress.com/2009/04/20/enteprise_in...

Cheers Tai

Re: quite similar to the new OpenAdaptor by Sarwar Bhuiyan

Hi there,

I was wondering if you had a look at the new Open Adaptor as it is also spring based and for the most part you can use their out of the box components in a spring xml file. If you need to write processors and endpoints, you can extend some basic interfaces that they have. I guess that may or may not always be necessary but it's still quite flexible in case you have a lot of custom requirements.

Sarwar

Application architecture by Kshitiz Garg

Hi Josh,

Thanks for your post!

I am aiming to create a notification server (a pub/sub and p2p model) and excited to use Spring Integration's features. To make that notification server an isolated black box, I m thinking to expose its functionality thru rest based APIs. Since ActiveMQ is highly configurable so probably going to use it for the message management part.

Do You think that it's a feasible & a wise decision to go for an architecture like this considering scalability & extensibilty ?

External systems <--> Restful APIs on Tomcat <--> Spring Integration acting as lightweight ESB <--> ActiveMQ (+MySql for message persistence and tomcat i.e. not the 'embedded' jetty) <--> Spring Integration <--> Restful APIs <--> External systems

What all pros & cons do you suggest in this scenario.....

Many thanks,
Kshitiz</--></--></--></--></--></-->