Topic: Design Decisons

[webwhy]

I'm working on a side project with a couple of friends of mine.  Most of the project will be built in Java/J2EE using the Spring Framework and Hibernate.  While I primarly work with php and lately ruby in my professional life, I have some limited experience with Spring and hibernate.  Nevertheless I'm far from an expert.

Basically this application will be exposed to other web apps as a service with a REST based api.  Basically commands are issued by communicating over known web endpoints.

Here's the debate:

My idea is to have all the commands that are received through the web funnel into a queue, and have the command processor threads consuming from the queue.  I want to use a free JMS implementation, ActiveMQ, for the queue.  It seems possible to implement asynchronous messaging without an EJB container, and JMS will  ensure that the commands will reach their intended targets.    

Since I'm not familar with java (i was out voted.  i wanted to do the project in ruby), I not sure of the approach.  While it seems that it will work, it's relatively complex.  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.  If a "simpler" RDBMS based solution was chosen, how would you implement the consumers, would thread and transaction safety become just as complex?

[Perspective]

>Most of the project will be built in Java/J2EE
> It seems possible to implement asynchronous messaging without an EJB container


I'm not sure I understand. It sounds like your trying to build a J2EE application without an EJB container, that basically means reinventing the wheel many times. Without a J2EE application server (which would include an EJB container) you can't really build a J2EE application.

[webwhy]

J2EE is a collection of technologies/specifications.  You are free to choose any combination of those technologies. Servlets, JSF and JSP are some of those technologies.

This application will run in Tomcat with an independent JMS implementation.  No EJB container (such as JBOSS, Weblogic or Websphere) will be necessary.  EJB is only one of the technologies in J2EE.  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.

[incognito]

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.