We're currently writing an application for which IT has already purchased hardware for. Their approach was to buy big hardware on which we would deploy. In order to add more processing, they plan on adding additional servers with identical software. In order to accomodate this design, we are using Terracotta to provide the ability to run multiple JVM's as though it was one large one. Regardless of whether or not this is a wise way to go (which I'm still not convinced), this is the situation I'm dealing with.
Anyway, we have a portion of the application that uses a standard producer/consumer type queue. With Terracotta, we're able to create a single queue that works with multiple JVM's. This is pretty slick and it works well.
But now, we are finding additional opportunities to run asynchronuous processes. To make all of our queuing logic more consistent, we're considering using JMS to abstract out common logic. Since we're not going to use JMS as a remote queue (at least for the foreseeable future), I'm wondering if JMS is just adding unneeded complexity.
Any suggestions or thoughts? Should we just continue to build queues as concurrent structures, or treat them as separate, potentially remote objects?
A message queue is essentially just Queue data-structure that has some fancy options. If your project is like most other projects, you're not using any of the JMS features that make JMS different from any old Queue implementation, especially since Terracotta is handling persistence and distribution.
So JMS is probably just adding complexity to your application, which is something JMS is quite good at. Like all unneeded drivers of complexity, get rid of it. If you ever decide to use JMS for one or more reasons, do it then.