Spring Integration as alternative for ESB ?

Hi All,

I am not a pro in this topic, i knew bits and pieces in this topic enterprise integrations.

Right now I have 50+ applications solving various business requirements and they talk to each other via web services directly one to one. So it is getting tedious to maintain and know which service calls which one, and when a service is down we don't know unless otherwise user reports about it. To overcome all these we are planning to have some
kind of mediation layer which can route calls and also have provision for other messaging types..

Here i started learning about Enterprise Integration Patters and understand the ESBs are a close implementation on EAI. I would like to know where does spring integration, Spring AMQP fits in to this EAI ? How does these stack compare to
1. Oracle ESB
2. Fuse ESB (Apache Service Mix, Camel, CXF etc.. )

Is it right to compare it with these frameworks or apps ?

Regards
Cres.

Interesting and rather complex question.
Let me parse it out into a subset of smaller questions.
1. To ESB or not to ESB? IMHO ESB is nothing more then a way for a dedicated runtime environment to host EIP components. In other words ESB is yet another server you would have to maintain. Besides another server to maintain you may end up in the situation of learning new programming model as well as re-factoring and/or re-writing your existing services to fit a particular ESBs programming model. So, my conclusion is - risky and unnecessary, however the ESB vendors would probably tell you otherwise while supporting their claims with pretty pictures and diagrams that would rarely impress a seasoned developer, but could pose a threat if you (the developer) stuck with it because the were able to impress your CIO.
2. If not ESB, then Camel or Spring Integration (SI)? Both share the idea that EIP best to be realized as a light weight embedded frameworks. But that is the only thing we share. But before I get into that I want to make sure that I tie this framework concept to an ESB. With framework such as Camel or SI you can obviously build your own ESB by deploying EIP components (e.g., HTTP Inbound Gateway) to the server of your choice (e.g., Tomcat, Websphere), so the benefit is that you can accomplish everything ESB let's you without introducing the overhead if a new programming model or new runtime.
Now SI or Camel. Well my answer is obviously bios - SI by all means! However I'll try to throw a few objective comments that even Camel fans would not be able to decline.
While Camel claims tight integration with Spring, Spring Integration builds on top of Spring . In other words there is a fundmental difference between using Spring or built on top of Spring. Spring Integration is basically an extension to Core Spring which means you would only have to learn the new namespaces (the actual representation of various EIP) when it comes to estimating a learning curve if you already have experienced Spring Developers.
While Camel claims that they provide implementation of EIP, their treatment of EIP is more of a guideline vs SI treatment of EIP as specification. I'll give you one small example. At the root of EIP is a pattern called "Pipes and Filters" - a core for all other patterns to follow. As the name suggest it defines two components - Filters (e.g., router, transformer, splitter, aggregator etc.) and Pipes.
Pipes is what decouples filters - logically and physically. And such decoupling is the most fundamental concept in messaging and event drivven architectures where consumer reacts based on the arrival of the message and NOT based on knowing who sent a Message.. . . Well, I can go on and on, but the point I was trying to make is; While SI exposes pipes as first class citizens of the framework via Channels (e.g., <channel> <publish-subscribe-channel>) Camels does not. Instead they have a concept of well defined and hardwired "routes" written in the from of "from. . . to" - which in itself contradicts the principle of decoupling producers and consumers and does not correspond to any EIP that I know.

Thank you for the detailed response. I understand your points. I too see ESB as some thing huge black box. When you say ESB requires another dedicated server to maintain, isnt it the same case if i need Rabbit MQ ? Can you give me a sample architecture diagram if i am to replace ESB with SI. What are the other components i might need to use ?

My use cases will be to
1. integrate web services by abstracting the end point. (Mostly synchronous calls)
2. configure topics and subscibers
3. Include HA in to mind, so that if the mediation layer is down, I have a standby
4. monitoring (with alert) of the web services calls and statistics


- thanks.
cresc.

I don't have a diagram to give, but since you asked about Rabbit MQ vs ESB, those are two un-comparable things. ESB is usually a proprietary runtime environment to host EIP components (e.g., protocol adapters, transformers, filters and other EIP endpoints). Rabbit MQ is a messaging system which supports AMQP protocol. IN ESB world this means that two endpoints that have to communicate with one another via AMQP would have to use AMQP adapter deployed in such ESB. That often implies that those two endpoints would have to be deployed in the same ESB.
Framework based approach simply states that if you need to send a Message over AMQP you configure AMQP outbound adapter of some sort and if you have to receive message over AMQP you'd configure inbound adapter of some sort, but you do it inside the runtime environment you already have and familiar with.

For better understanding how all this come together I would suggest going through some of the samples that we have for Spring Integration which includes JMX (related to your management/monitoring question) as well as samples which include web service integration (both REST and SOAP), JMS, AMQP etc., as well as topics and subscribers via variety of messaging channels available in SI.
Link to the samples is here: https://github.com/SpringSource/spri...ration-samples

Thank you for all the details. Will try the samples and get back on this topic.