JMS Alternative

I was reading a blog, and one of the points was 'if you're using queues, you messed up', in the context of JMS.

I was thinking, do we even need JMS? A simple alternative would be, if you need to do something asynchronously, why not just put a job request in a table somewhere, and have some process(es) polling the db every X time units looking for new jobs?

This approach is simpler than JMS开发者_如何学Python, its easy to understand, and basically removes a dependency from an application.

What am I losing if I use the alternative I described? Perhaps one loses the possibility of using JMX to be able to administer things, but if your job 'queue' is fed off a table, you can write some simple code to 'manage' the processing.

I was reading a blog, and one of the points was 'if you're using queues, you messed up', in the context of JMS.

This is simply wrong.

You might mess up by choosing to use a queue when it's not appropriate, but if it is JMS is a fine choice.

I'd be more discerning about what I read on the Internet if I were you. Sounds to me like the author liked making inflammatory statements to spice up his blog and bump up his Google Analytics statistics. It's one person's opinion, nothing more.

The polling solution is more complex, wasteful of CPU cycles, and not real time in my opinion.

You can use an Executor or FutureTask if you want asynchronous processing. Those would be reasonable alternatives to a queue if asynch is all you need.

I would really like to know where you read that. JMS is pretty much proven technology, but as with all solutions, you can also misuse it. If you need to schedule tasks, you can use one of the many task scheduling libraries. Here is an overview: http://java-source.net/open-source/job-schedulers

For very simple requirements of just asynchronous processing, you can use any suitable class from java.util.concurrent package.

If you need transactions or the guarantee that a job must be successfully completed once submitted, even in case of system failures (software or even hardware crashes), or you want to offload job processing to another process you need some other solution.

JMS approach can provide a very sophisticated solution with relatively less effort.

Messaging (or JMS) is a very standard integration solution which can solve the problem of keeping submission of jobs asynchronous and keeping submission of tasks decoupled from the actual processing. Messaging based solution can be easily scaled by increasing the number of 'job processor' threads listening on the job queue. The traffic will be automatically load balanced. Messaging systems can also provide transaction support, i.e. automatically put the message back on the queue if job processing fails so that it can be retried.

Many enterprise integration patterns are based on Messaging systems (Message oriented middlewares). This book on Enterprise Integration Patterns by Gregor Hohpe has most popular patterns of how to use messaging in your applications.

The database approach requires another process to

1) Poll the table for 'new jobs', update the status of the row when job processing starts by the processing application and eventually either update the row status of the job to 'done' (or delete the job altogether from the table). 2) If something goes wrong during the job processing, the job status should be changed back to 'new' on the table, so that the 'polling' mechanism can pick up the job again. Also, need will arise to write some 'recovery thread' on system start-up to find out jobs which might be in an inconsistent state and put them back in 'new' state to start the processing again.

Bottom line is, it takes a lot of effort to build an integration solution which is based on a database. It also tightly couples both 'job submitter' and 'job processor' applications with the database schema which breaks the encapsulation of your database. If your 'job processor' has multiple threads (which you will probably need if you want to scale) then you need to make sure that only one thread picks up the job and updates 'that' row.

A JMS solution solves this problem very easily without hand-coding all this logic.

Surely, if you are using queues you are NOT messed up. But you should have some valid use-case to introduce a messaging middleware.

This approach is simpler than JMS, its easy to understand, and basically removes a dependency from an application.

Well, that's only true if you come from a Database background. I would think there is nothing easier than sending a message for every state change and 'forget about it'.

One advantage of message oriented middleware (e.g. JMS) is the higher performance - you can have rates of 1M msgs/sec - but the bigger benefit is usually a cleaner architecture: a message bus where multiple components plug into. Right now you have your one-to-one communication, but in 2 years you might want to log that traffic, in 3 years you might want to monitor errors and in 4 years you might want to automatically record and replay and test it...