Article: Getting Started With Spring Integration
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.
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.
"Vend" or "Send"?
Spring Integration vs. Apache Camel
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
Do we even need ESB?
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
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.
Spring Integration Adapters project in Spring Extensions.
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:
Re: quite similar to the new OpenAdaptor
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.
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.....
Ralph Winzinger Nov 25, 2014
John Krewson, Steve Ropa and Matt Badgley Nov 24, 2014