I would really go with a message driven bean, since it already handles load balancing and some session management, threading, etc. But if EJBLESS is what you're looking for then you can make just use plain vanilla flavored JMS, and implement a consumer yourself. I believe tomcat has plugins for EJB containers.
>>>>>>.The trend is toward lighter frameworks such as Spring (springframework.org) and using heavyweight beans only when necessary. In this project, they're not necessary.
Lighter than what? What are you comparing Spring with?
>>>>Is it overkill? Can anyone think of a simplier way to create a threadsafe queue that will garantee commands in the queue are not lost in the event of a service interruption
When an exception or something abnormal is encountered in a MDB, the message does not get cosumed and it keeps looping
. Though you can work around this with your own implementation also.
I am not sure I am following what you're trying to do, who's going to consume these messages once in the queue? Other apps? are they java enabled apps?
You can also have a table with all the requets or "messages" and have a thread in the background check for new transactions and execute them, this way you wouldn't need a message driver bean, or even a JMS queue. You can use a java Timer or something.