ALTERthought Blogs

home
company
Feed Icon

10 March 2006

Choosing a JMS Provider: Harder than it should be

So I am in the process of evaluating several leading commercial JMS (Java Messaging Service) vendors for recommendation to a client. All of the typical things you might expect are in the hunt as part of the criteria:

And a few things that may/may-not be typical thrown in for good measure:

So what’s so hard about this seemingly straightforward task? Well to start with most vendors don’t seem to publish much in the way of comparisons against their competitors. They provide plenty of information as to why you should choose them, but little in the way data that distinguishes them from their competition. All such comparisons that I have been able to obtain to date have concerned themselves with performance criteria only. Don’t get me wrong, performance is important, but so are any number of things.

The documentation provided by most vendors is equally lacking, or difficult to find, or simply non-existent.

As such, I am (frustratingly) left with having to download, install, learn and play with most of the vendor products. Sigh. Stay tuned to this one. I will update this entry with my findings.

Technorati Tags: , , , ,

    del.icio.us

Comments are locked.

ks says:

Did you try TIBCO EMS? http://www.tibco.com/software/enterprise_backbone/enterprisemessageservice.jsp

Damien says:

I highly recommend JORAM –> http://joram.objectweb.org/

Damien says:

Oops, I missed the part where you said commercial. If by that you mean; pay for software license and professional services, as opposed to open source software and pay for professional services…. Well, then good luck with that.

Mike Richardson says:

To everyone that is reading this post/and comments: if you have experience using queuing vendors for .NET messaging applications other than MSMQ, please give me some information on your experiences with other vendors. MQ Series is a wonderful product, but there .NET API is terrible. As a matter of fact, just to implement transactions requires the use of COM+ interop (not good). Sonic suffers from the same issue. I am currently testing the .NET API with Tibco Rendevous and it looks pretty useful so far. As soon as I am done my functional and performance testing, I will be posting my results.

Bruce Snyder says:

ActiveMQ 4.0 supports all of your requirements and more, without any license costs because it is Apache Licensed open source. Services and support can be purchased from LogicBlaze (http://www.logicblaze.com/). In addition, ActiveMQ outperforms nearly all other JMS implementations, most by a large margin - see the performance report here:

http://logicblaze.com/AMQ_data_sheet.pdf

Mike Richardson says:

Bruce,

Interesting point - I am definitely interested and am going to download it now to run some basic performance tests. I am also very interested in its support of the REST protocol, which could make for some interesting messaging scenarios.

Mark Nickel says:

There is support for REST, but you should probably check out this posting in the forums before getting too excited:

http://forums.activemq.org/posts/list/143.page

IMO, the REST support in ActiveMQ is really in place so that you could implement a new client in a non-Java language. From my experimentation, using the REST interface is fairly complex… But that’s definitely not the fault of ActiveMQ. :)

For easier scripting you are probably going to want to play with STOMP or the AJAX as these build on the REST and hide the complexities of how REST is implemented within ActiveMQ.

I think it’s great to have these simpler clients that hide the majority of the gritty details of a JMS client. Most implementations really just need to send and receive messages… The infrastructure should take care of the details… If you really need the low level stuff for nailing that last few percentage points of performance, you can do it because the details are still available.

Mike Richardson says:

Mark,

Thanks for the suggestions. I am doing some testing right now with ActiveMQ and I have to say it is pretty nice. Now its time to put a .NET wrapper around this sucker! :-)

- Mike

don says:

Thanks for all the suggestions and info from the comments. As was noted in an earlier post, this evaluation (at the clients request) is currently limited to conventional commercial vendors, but ultimately may not be (they make heavy use of jBoss and MySql, for example, so they are no strangers to OpenSource in the enterprise.) It will likely be a week or two before the dust settles, but I will update this post with ultimate results of the survey.