Mule ESB vs. Spring Integration [closed]

Question

The Mule ESB project explains its difference to Spring Integration on its website. However, regarding dcterms.date 2012-07-19T18:43-03:00 of the document, the text might be outdated.

The main points of the quoted paragraph are

• "Spring Integration takes [...] an 'application-centric' approach to integration".
• "Rather than implement a shared bus, [...] Spring Integration is aimed at providing 'just a little' ESB-style integration to specific applications".
• "Spring Integration is best suited to situations where a small number of components must be integrated, usually internally".
• "[Spring Integration has a] very small number of supported transports and transformers available".
• "[The] scope of Spring Integration is deliberately limited to small-scale integration within the Spring Portfolio context".

Are these points still valid? Does any more detailed and, if so, up-to-date comparison exist?

Mule ESB vs. Spring Integration

Recently, a new component called Spring Integration was added to the Spring Portfolio, which allows ESB-like functionalities and EIPs to be created and managed within the Spring Framework. Spring Integration takes what is known as an "application-centric" approach to integration.
Rather than implement a shared bus, which allows all integration and messaging between components and systems to be managed, administered, and configured centrally, Spring Integration is aimed at providing "just a little" ESB-style integration to specific applications by providing frameworks for implementing common EIPs such as a message bus and simple routing. Due to its limited scope, Spring Integration is best suited to situations where a small number of components must be integrated, usually internally, and the infrastructure in question is made up of a large number of other Spring components. For anything more complicated, the lack of a common bus, coupled with the very small number of supported transports and transformers available for the young project makes Spring Integration unsuited for the task.
The advantage of using Mule ESB to handle integration in a Spring environment is that Mule ESB is not simply an ESB - it is an integration platform. Whereas the scope of Spring Integration is deliberately limited to small-scale integration within the Spring Portfolio context, Mule's intentionally modular architecture allows teams to quickly deliver the lightest possible integration solution for any scenario, from simple point to point integration to complicated SOA, cloud and partner ecosystem scenarios.

Answer 1

Full disclosure: I am the current a past Spring Integration project lead and have been a committer for over 10 years.

While it is true that Spring Integration promotes modularity and loose coupling within an application, it is also very well suited for integrating systems together without the need for a central ESB. I am personally aware of a number of very large enterprises that integrate all their business systems together using only Spring Integration, with no central bus server(s) to configure/administer.

Its POJO programming model makes it incredibly easy to customize/extend; if some transport/protocol is not supported out of the box, you can simply wrap it in a POJO and invoke it (or consider writing a more formal adapter and contribute it back to the framework!).

We are particularly excited that it forms the basis of the new and important Spring Cloud Stream.

You may want to take a look at DZone's recent Guide to Enterprise Integration which talks about Spring Integration as well as the competing technologies.