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?