Spring Integration or JmsTemplate?

[noob78]

Seems like I have a tough choice ahead of me...

I could either create a stand alone Spring Integration JMS Consumer or embed the Spring JmsTemplate into existing Spring Web application. Without regard to performance, which route should I take? The reason I said to ignore performance is because we have less than 10 users at most. So, I'm hesitant to create another server using Spring Integration. At the same time, if there's any benefit in using Spring Integration over JmsTemplate then I'm all ears. Also, please assume that I'm "only" using JMS... don't need any Spring Integeration w/ files, emails, rmi, web services, and etc... I guess I'm really looking for "valid" reason to use Spring Integration for technical learning purpose or to convince my co-workers.

[Mark Fisher]

Spring Integration doesn't really add any overhead; it's just calling JmsTemplate methods for you while exposing a more generic interface. Can you describe the use-case a bit? You are sending a Message from within a Controller?

[noob78]

Spring Integration doesn't really add any overhead; it's just calling JmsTemplate methods for you while exposing a more generic interface. Can you describe the use-case a bit? You are sending a Message from within a Controller?

Thanks for the response. No, it's not from the controller. This is only for in-bound JMS process that performs CRUD operation on to the DB.

[Mark Fisher]

Without knowing too many details, it sounds like using Spring's basic Message-Driven POJO support might be sufficient. That does not even require the use of JmsTemplate. Instead, you would simply point to a POJO via configuration and let all the JMS details be handled behind the scenes.

If you think you need to take advantage of a pipes-and-filters model for transformation, routing, etc., then you could look at Spring Integration.

Can you describe why you think Spring Integration might be useful beyond what you get from Spring's Message-Driven POJO support?

[noob78]

Without knowing too many details, it sounds like using Spring's basic Message-Driven POJO support might be sufficient. That does not even require the use of JmsTemplate. Instead, you would simply point to a POJO via configuration and let all the JMS details be handled behind the scenes.

If you think you need to take advantage of a pipes-and-filters model for transformation, routing, etc., then you could look at Spring Integration.

Can you describe why you think Spring Integration might be useful beyond what you get from Spring's Message-Driven POJO support?

As of now, I don't need any of transformation, routing, and etc... The only reason I thought of Spring Integration is that I can create stand alone JMS provider server. For example, the flow would be JMS stand alone server -> DB <- Web App

Then, I don't need to include JMS code into Web Server. Yeah..it's not a compelling reason... but I think I'll go w/ Spring Core way of doing this and be part of Web App.

[Mark Fisher]

The only reason I thought of Spring Integration is that I can create stand alone JMS provider server. For example, the flow would be JMS stand alone server -> DB <- Web App

Then, I don't need to include JMS code into Web Server. Yeah..it's not a compelling reason... but I think I'll go w/ Spring Core way of doing this and be part of Web App.

I'm not following what you mean by "JMS stand alone server". There is no difference in the way Spring Core or Spring Integration would handle the JMS reception. In other words, you can easily use Spring Core's JMS support for Message-driven POJOs as a standalone Application Context that is not part of the webapp.

Does that make sense?