Spring Integration Standalone vs Spring Integration in App server Container

[balaji44]

Hi,
i am new to SI. I am planning to use SI for my project. My project has got front end and backend. Communication is based on JMS queues. I am planning to use SI in backend. Planning to use multiple instances of SI so as to achieve scalability/failover. My requirement is just the backend process not the web app. I want to achieve scalability, robustness and failover, etc., Can i achieve this by standalone deployment (just the main wrapper class to start the application context) or should i place the spring application in container such as tomcat. is there any advantage if the spring application is deployed in container. Please advice.

[Mark Fisher]

If the only "endpoints" for your backend app are the adapters connecting to JMS queues, then you don't need to run in a servlet container... the logical spring container (ApplicationContext instance) is sufficient. There are some reasons you might still want to run in a container (management/monitoring/shared-library) so you should weigh the option based on those factors. Even then there are some options that do not require a container (e.g. Spring Integration exposes tons of JMX metadata, and all you need is a single <mbean:export> in the configuration).

Hope that helps.
-Mark

[Gary Russell]

Either will work fine; folks sometimes choose to use a lightweight container, such as Tomcat, because the ops folks are used to managing/monitoring them. But Spring Integration doesn't need a container (unless you are using http or web service inbound endpoints). Another possible benefit of using a container is you can provide a simple web interface to perform operations, such as starting/stopping adapters, etc (but this can also be achieved over JMX, which avoids the need to write a web interface).

Running a main() is fine, but you might want to use a shell script that can re-start the JVM after a failure, and be installed as an init.d script for auto startup on reboot.

It often just comes down to corporate policies and what the ops people are more comfortable with.

[balaji44]

Thanks Mark and Gary for your response. You were telling about the possibilities of having standalone rather than web container but i would like to know how far we can achieve failover, cluster, scalability of Spring Integration. Does standalone achieve all the scalability, clustering stuff etc., or Spring integration inside web container could be the better option for these requirement?

Note: My case is we would use JMS inbound endpoint and we may use http outbound endpoint.

[Gary Russell]

The deployment type makes no difference in this case - those facilities are provided by your JMS provider library. From a client perspective, all the instances are peers and the JMS broker decides which instance gets a message; if an instance goes down, the message will be sent to another instance.

When your JMS broker itself is a cluster, the client library configuration determines how failover is achieved.

So, none of this is dependent on how you deploy your app.