This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
Yes, this forum is for Spring Integration framework, which ironically is the framework that is an alternative to ESB and Mule and is competing with Mule.
So, I would ask a different question. If you are looking at Mule what are your requirements and why Mule and not Spring Integration?
If you are already using Spring and also have a need for integration and EIP, then why not use a uniformed programming model and use Spring Integration - an embedded messaging framework (messaging bus) that provides components that implement Enterprise Integration Patterns (EIP) that is built on top of Spring?
I am interested in the scalability issues of the spring framework fo integration more than 4 applications and have read that mule shines in this respect and that spring for eai applications is a smaller scale esb approach. i am looking at reducing code and mapping as other applications come across.
It's funny that you mention "smaller scale", because the best way to *scale* is to keep things *small* (as in "lightweight"), and that is in fact one of the main goals of Spring Integration. The idea is simple: the smaller the unit to deploy, the more you can deploy.
With Spring Integration, we are not trying to be an ESB. However, we are trying to provide the framework and all the components you need to do the same things that would make you consider an ESB in the first place.
A Spring Integration application is really just a Spring application with some beans in the context that handle the integration concerns. That means you can deploy anywhere and at any scale. More importantly it means you only need a single "container" (Spring itself, not Spring as a container-within-a-container). The lifecycle, threads, scheduling, transactions, and so on are all "Spring as usual". Many of the strategy interfaces that you use in Spring applications - such as Converters, TaskExecutors/TaskSchedulers, Triggers, TransactionManagers, JMS MessageConverters, DestinationResolvers, OXM Marshallers, HttpMessageConverters, etc. - are all reusable where relevant within the components provided by Spring Integration.
Unlike the alternative solutions, we are the only one that is simply Spring at every layer.