spring integration vs ESB

[Pradeep bhatt]

Dear Mark Fisher, Jonas Partner, Marius Bogoevici, and Iwein Fuld,


It looks like spring integration is like an ESB ? Do you' agree ? If true do you think we need ESB if we are using java?

Thanks,
Pradeep

[Padmarag Lokhande]

Hi Pradeep,
I had similar thoughts, however it looks like Spring integration is light-weight compared to the ESB's.

[megan smith]

If true do you think we need ESB if we are using java?

If you are developing an enterprise application that requires integration with third party application to send messages then,yes. It would be wise to opt for ESB. Camel's learning curve is very less and requires min effort for installation and configuration.

[Mark Spritzler]

Personally, like App Servers, I don't know whay anyone would want ot use an ESB instead of Spring Integration or Camel. Both are lightweight, easy to use, FREE, and can run anywhere.

Mark

[Pradeep bhatt]

Then a question crops up in mind, can spring integration work across JVMs

[Mark Spritzler]

Pradeep bhatt wrote:Then a question crops up in mind, can spring integration work across JVMs

Can you give example on what you mean? I can definitely send messages across JVMs with something like RabbitMQ/AMQP. Is that what you mean? It can also call via RMI. And you don't have to have Spring Integration on both sides either with something like RabbitMQ.

Mark

[Bill Gorder]

For that matter I can use webservices or HTTP. In the case of HTTP for example I would convert the message to JSON or XML (Spring integration can do this) and map the spring integration headers to from HTTP headers (Spring Integration will do this too)

[Gunnar Hillert]

Hi,

I think two major advantages that Spring Integration brings to the table is that it is extremely lightweight and that it reuses the features of the Spring ecosystem to the fullest extend.

Thus, you can use Spring Integration easily as a library within (existing) applications. This means Spring Integration is also very suitable for intra-application integration and not just for business-to-business (B2B) or application-to-application integration (EAI).

What I mean by that is that you may have pieces of your application that you want to logically separate in order to break down complex business requirements into more manageable components but you still want to keep everything as part of the same application (at least initially). This give you the infrastructure, as your application scales, to add asynchronous behavior to your application or to refactor out components to un on difference machines etc. as the need arises. In that regard it is worth to mention that you can use Spring Integration in any type of application - be it stand-alone applications (jar) or web-applications (wars).

Therefore, yes, you can create applications with Spring Integration that run similar to a traditional ESB but you can also create application using Spring Integration that are almost embedded in nature. I have heard of an example where Spring Integration is used as part of an ATM stack using the TCP/IP adapters in a financial institution.

I hope this provides some insights regarding how Spring Integration fits into the landscape compare to a traditional ESB.

Cheers,

Gunnar

Disclaimer: I am a committer on the Spring Integration project

[Mark Spritzler]

Hey Gunnar. Welcome to JavaRanch. Thanks for coming by and helping us out.

I skyped with Marius today and he and the guys will be around shortly.

Mark Spritzler

[Iwein Fuld]

Pradeep bhatt wrote:
It looks like spring integration is like an ESB ? Do you' agree ? If true do you think we need ESB if we are using java?

Both an ESB and SI support EIP. But SI is definitely not an ESB. The comparison between messaging frameworks and an ESB stops when you consider how EIP is enabled. SI gives you language semantics, an ESB gives you architectural building blocks.

In my opinion it is often a better architecture if you enable messaging inside the nodes that need to communicate with other nodes. This you cannot to with an ESB. The philosophy behind an ESB is to abstract away the complexities of messaging so that the developers of a single service need not worry about them. The fallacies of distributed computing are empowered by this arrogant architectural standpoint, but some development cultures might actually benefit from it. If you have stupid developers and smart architects, an ESB makes sense. This is more often believed to be so than it is actually the case however.