Java Message Service (JMS) and MOM

> I've been researching Java Message Service (JMS) and

> the various Message-Oriented Middleware (MOM) and

> below is a list of what I found. I need to develop a

> JMS-based application and would like to hear some

> pros and cons about these MOMs. I would like to go

> with an open source JMS like jgroups. If you know any

> other MOMs please let me know. Thank you.

That's quite a list you've compiled.

I don't have experience with all of them, but I'd have to know more about your particular situation to comment in depth.

Everything that follows is true of all Java EE technologies, not just JMS.

You should choose one that's well-known. If that's a commercial or open source product, pick a market leader. You don't want your solution to be based on technology that's not in common use.

If they all support a JMS standard, that's good. Make sure the one you choose does that.

Open source is appealing because of price, but you've got to be careful. Not all open source projects are equally active. I'd stay away from anything that hasn't been updated in a while or doesn't appear to be very active anymore.They aren't all of equal quality, either. It's good to read about them and look at the source code for yourself to see what you think of their work. If you decide that it doesn't pass your code review, perhaps it won't be a good choice.

JMS is part of Java EE. Why not get it bundled in with the rest of the Java EE stack?

These are all commercial products. I've sorted them according to my personal opinion.

> WebLogic JMS

> WebSphere MQ

> SonicMQ

> FioranoMQ

These are the open source products that I know, ranked according to my opinion.

> JBossMQ

> ActiveMQ

> SunTM ONE

> OpenJMS

I don't know of a bridge between JMS and MSMQ. I don't think this option is available to you in open source. Here's a recent blog about the issue:

http://blogs.msdn.com/smguest/archive/2005/03/17/398134.aspx

http://www.xephon.com/journals/more/MQ

> MSMQ

One last thing: You'll want to look into the Spring framework and its JMS support. You can use POJOs and JMS that way:

http://www.springframework.org

The rest of these are unknown to me.

> JRMS

> iBus//MessageBus

> WBIMB

> JGroups

> AshnaMQ

> Open3

> openadaptor

> Hermes JMS

> JORAM

> MantaRay

> Presumo

> Somnifugi JMS

> UberMQ

> MessageQ

> MsgConnect

> NetZyme

> TIBCO

> OpenMOM

> D-spheres

> xmlBlaster

> MQ4CPP

%

duffymoa at 2007-7-14 1:31:00 >

Remember that part of the job is to make it fit the application and organization you are working at and implementing with. Do you use JBoss application servers? if so, the use JBOSSMQ

If not, I personnaly would use Sun JMS because it has some very nice managment and scalability implementations. And support is not very expensive either. You pay for that with open source unless you want to depend on community and yourself only. If so, then look for active community involvement.

As to plug and play on implementations, that depends on how you use it more than the implementation. Any usage that is using specicification level operations only and not vendor specific additions (what you really 'pay' for) then yes you can easily replace one with another unless you code & architect very poorly.

BTW - the use of Spring will make your application less tightly integrated with the implementation as well. That is one of the beauties of that framework.

darteda at 2007-7-14 1:31:00 >

> These are all commercial products. I've sorted them

> according to my personal opinion.

>

> > WebLogic JMS

> > WebSphere MQ

> > SonicMQ

> > FioranoMQ

Really? What's that based on? Based on performance testing we've done, Fiorano and Sonic are much faster than the other two... like a factor of 10, throuput-wise. Fiorano also has very low latency, on the order of a few hundred ms, even with 10s of publishers at "full throttle".

RadcliffePikea at 2007-7-14 1:31:00 >

> As to plug and play on implementations, that depends

> on how you use it more than the implementation.

I found this written by Andrew Binstock;

http://www.devx.com/Java/Article/17526/0/page/3

"Since code written for JMS is pretty much portable between implementations, you can take any leading version and work with it to develop and test your code. Most versions limit the number of connections you can make to the JMS server ... enjoy the fact that if you chose the wrong JMS, you will for the first time in computing history be able to change middleware providers without rewriting your applications."

I found another, SwiftMQ.

xoxa at 2007-7-14 1:31:00 >

> > These are all commercial products. I've sorted

> them

> > according to my personal opinion.

> >

> > > WebLogic JMS

> > > WebSphere MQ

> > > SonicMQ

> > > FioranoMQ

>

> Really? What's that based on?

To be quite honest, I'm basing it on my familiarity with the product. I don't have any performance numbers at all. 8)

> Based on performance

> testing we've done, Fiorano and Sonic are much faster

> than the other two... like a factor of 10,

> throuput-wise. Fiorano also has very low latency, on

> the order of a few hundred ms, even with 10s of

> publishers at "full throttle".

Sounds like you've got much better data than I ever dreamed of.

I thought I made it clear that this was purely my opinion, but I'm glad you asked. This way I can admit to being a blowhard in public, where EVERYONE can see. 8)

%

duffymoa at 2007-7-14 1:31:00 >

> Yeah, we use BEA quite a bit and it is very nice

> overall. Stable, robust, etc. Admin can be a bear,

> but I think that's the way it goes with J2EE servers.

> I was somewhat surprised to see their performance was

> far behind some of the other vendors.

How big a debit? Half as fast? We're a WebLogic shop, but we don't do asynch heavily, just the odd queued message here and there.The volume isn't so high that you'd notice a performance problem. (Most of our performance problems are caused by inefficient data access, which is caused by a poor understanding of object-oriented design.)

> I was fortunate that we had a bunch of equipment (15

> Sun V210s) that came in and was not immediately

> pressed into service, so I was able to set up a nice

> test environment to punish some JMS providers. We're

> in the requirements analysis phase of a large

> integration project that has some high throughput

> requirements, and we're looking to do so in a

> "loosely coupled" manner. Sonic and Fiorano met our

> requirements, but the others didn't. Interestingly,

> every one of the open source implementations

> crashed under heavy punishment. All the commercial

> vendors survived, well, except our good buddies at

> Sun, that is. We could've done a lot more testing,

> though with all the configuration parameters and

> possible topologies, etc...

That's some very nice work. You're lucky to have had the chance.

It's especially pertinent in this day and age of SOA and loose coupling, isn't it? We're talking and thinking about it, but no one in our area is doing the fundamental work that you've done.

> Unfortunately, all my machines have been taken away. :-(

Bastards!

> Ah, don't worry, its just a bunch of Java nerds round

> here, nobody that matters is paying attention.

But it's your opinion I care about. 8) Nice work, and thanks for talking about it.

%

duffymoa at 2007-7-14 1:31:00 >

> I was fortunate that we had a bunch of equipment (15

> Sun V210s) that came in and was not immediately

> pressed into service, so I was able to set up a nice

> test environment to punish some JMS providers.

RadcliffePike, could you post your test results? What JMS providers.did you test? The list is long. Did you test SwiftMQ?

Thank you

xoxa at 2007-7-14 1:31:00 >

> How big a debit? Half as fast?

Sonic and Fiorano were both network limited (100 mps, full duplex), BEA was about 1/8 of that speed. I did as much parameter tweaking as I could but I didn't find the magic "go fast" button for BEA. BEA offered to send an engineer to do some tweaking, but we didn't have time to do that. Otherwise, BEA was very robust, no crashes or lost messages.

> We're a WebLogic

> shop, but we don't do asynch heavily, just the odd

> queued message here and there.The volume isn't so

> high that you'd notice a performance problem. (Most

> of our performance problems are caused by inefficient

> data access, which is caused by a poor understanding

> of object-oriented design.)

Yeah, we're mostly weblogic here too. We've got a dedicated BEA guy here and they're always very reponsive whenever we have a problem.

Argh, don't get me started on data access problems...

> It's especially pertinent in this day and age of SOA

> and loose coupling, isn't it? We're talking and

> thinking about it, but no one in our area is doing

> the fundamental work that you've done.

Yeah, its a hard problem. I think SOA is sometimes a hard sell to SW engineers, because it gets too bogged down in the technical details of XML and SOAP and all this ****. The subtle points of loose coupling, etc, get lost.

RadcliffePikea at 2007-7-21 8:28:59 >

> What versions? We did a major integration with

> decent throughput and are using SonicMQ (what we

> have) and persistant queues. We managed to make

> Sonic choke and had to do some tuning but got around

> it. I have since tested the new (last years) Sun MS

> and had no problems so was curious.

Ah, this is all non-persistent messaging, so your results may vary. I don't have the version for Sun we used in front of me, but I don't think it was the latest and greatest.

RadcliffePikea at 2007-7-21 8:28:59 >