Article: Getting Started With Spring Integration

Nice article, thanks.

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

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.

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?

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

"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.

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.

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

Are we heading towards more heavyweights?!

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

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

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</--></--></--></--></--></-->

Hello Srini,

I am new to spring integration.
I an trying to run spring integration

I downloaded sample from
www.javacodegeeks.com/2013/09/spring-integratio...

I imported it in STS File-->Maven-->Maven Existing Project
then run it on the server.

Can you please help me how to run the Spring Integration

Regards,

Vaibhav