views:

295

answers:

5

Hi all, I've a WEB application (with pure Java servlet) that have some heavy computational work, with database access, that can be done in asynchronous mode. I'm planning to use a dedicated server to execute such batch jobs and I'm wondering which tools/techniques/protocols to use for communication between servlets in the WEB server and batch jobs in the new dedicated server. I'm looking at JMS. Is it the right choice? There are industry standard and/or widely adopted techniques? I need also queue and priority handling for multiple simultaneous jobs.

+2  A: 

Messaging is one of the best options.

Make the messaging framework very generic so that it can handle any type of batch jobs.

One approach is to have an event/task manager where you put an event on the queue and the queue consumer processes the event and converts it into a set of tasks. The tasks can then be executed by separate task handlers. A task can also generate some more events that can be again put on the queues to provide a feedback loop. This way you can add work flow like features to the framework and allow your batch jobs to have dependencies on each other.

Rahul
+3  A: 

JMS is a pretty standard solution. The high-end platforms (Sun's JCAPS, for example) makes heavy use of JMS to partition and manage the workload of web services.

There are many advantages to buying a high-end JMS implementation from Sun (or IBM or Microsoft). First, you get things like reliable message queues that are backed to the file system. No message can get lost. Second, you get some monitoring and management tools.

One cool thing is to have a JMS queue with (potentially) multiple subscribers to do workload balancing.

Another cool thing is to have JMS topic which has a logging process as well as the real work process subscribed. The logging process picks off the messages and simply records the essential stages of the job being started and stopped.

S.Lott
+1  A: 

JMS would be the appropriate solution for sending your batch jobs from the servlet. It may not be the best solution for the batch server to communicate with the servlet though, as it cannot be a listener to messages.

As I don't know what the communication from the batch server to the servlet is supposed to entail, I can only say that there are probably several options you can use (yes JMS is one of them). But they all basically rely on polling calls to the servlet which will then check in some way to see if there is anything from the batch server waiting. This could simply be a servlet on the batch server or making receive calls to a JMS response queue. Other solutions are available, but the point is it is not asynchronous, unless you have the ability to push from the batch server all the way to you client end (a browser I am guessing) via something like AJAX.

Anyway, just something to keep in mind.

Robin
+1  A: 

Another alternative for asynchronous processing is to have the web application store the request in the database, and have the batch process poll the database for new batch jobs to process. Since your application appears to be smaller (pure Java Servlets) this may be a simpler and lower cost solution.

Hope it helps.

Neal Swearer
That's the "building JMS with a database" solution. It can be made to work. But... it can turn into a performance problem because it isn't a simple message queue.
S.Lott
A: 

We use JMS with web services:

  1. Client requests computation via web service
  2. Server writes JMS message, and creates an ID value which is stored in a database along with a status (initially "Pending"). Server returns the id to the client.
  3. Server (can be separate server) reads JMS message, does computation, and when finished updates the status to "Completed" in the database
  4. While the computation is ongoing, the client is polling the server to determine the status using another web service (along with the id). The server returns the status which is retrieved from the database. Once the server computation is completed, the client will see the "Completed" status and know that the computation is complete.
Marcus