Comparison with Queue & ESB based solution

[stlecho]

Hi,

I've read through the documentation and looked at the samples provided with the SI distribution. Concepts used in SI are closely - but not surprisingly - related to some other concepts: message queues, JMS and ESB.

So I was wondering if SI could/should be considered as an alternative for queue/JMS-based (but what about transaction support, management through JMX, ...) or ESB-based (provider of "services" that can call other "services, ...) solutions ?

Regards, Stefan Lecho.

[iwein]

Spring Integration is not intended to be and ESB, but it is definitely a good alternative for certain applications of an ESB.

In terms of transactionality and guaranteed delivery it doesn't have the features that ESB's and JMS implementations provide. Also the channels in Spring Integration do not connect different jvm's, but they run inside a jvm. There are many reasons though that you might not want those features. For example if you're running on a grid or if you're using idempotent receivers and compensating actions.

If you design your system in such a way that if you lose everything on a queue the system is still in a consistent state you can get a lot of performance gain from using Spring Integration. If you can't you might need to use Spring Integration together with JMS. Of course you could also add the features you think are missing in a custom way or through submitting JIRA feature requests.

Like the rest of the Spring Framework, SI is very extensible.