[rabbitmq-discuss] JMS client impl (javax.jms)

[Jon Brisbin]

I think this topic can quickly digress into a religious war of "my API is better than your API". I don't want to send us down that road. ;)

Suffice it to say that I try and encourage people to ask the "why am I doing it this way" question as often as possible (because I ask myself that question on every project...can I do it better this time than I did last time, etc...). If it's because we don't have time or money to do any differently, that's a perfectly legitimate business decision. We do that here quite a bit, unfortunately. But if you're going down a different road altogether (AMQP), it often pays to get the larger perspective and, just because it *can* be done a certain way doesn't mean it *should*.

And don't get me started on ESBs! :) We're working on an ESB project right now and I'm amazed at how much stimulation of India's economy we're doing by paying these people to construct fantastically complicated systems of webservices and such to do simple things that can more efficiently and easily be done without the overhead imposed by the ESB paradigm. 

But that's another religious war I don't want to inflame! ;)

Jon Brisbin
Portal Webmaster
NPC International, Inc.


On Nov 17, 2010, at 9:11 AM, Paul Fremantle wrote:

>> For my own 2 cents: if you want JMS, use a JMS broker like ActiveMQ or
>> something. If you're using RabbitMQ, you're doing it because AMQP has things
>> that JMS doesn't that make the latter better than the former. If you have to
>> stick with JMS because there's a line in the sand somewhere you can't cross,
>> I'd almost say just stick with the brokers that more JMS-centric.
> 
> I understand your opinion Jon, but my own 2 cents are completely
> different. JMS offers a well-understood abstraction to a programming
> model. There are some pain points (JNDI), but its very widely used and
> adopted. The AMQP working group spent a lot of time ensuring that JMS
> can be implemented on top of AMQP. There are a lot of reasons why to
> use JMS/AMQP:
> 
> 1) Interop with other languages. Because AMQP has clearly defined and
> published semantics and a mapping of those to JMS then it makes a good
> model where JMS users can use what they know and AMQP users what they
> know but everyone can talk.
> 2) Migration from an existing JMS broker: Users who are using JMS
> today may want to position themselves for AMQP in the future.
> 3) Integration with standard software (e.g. ESBs) that already talk via JMS APIs
> 4) People who actually like JMS but want the performance, standards
> basis, etc of AMQP.
> 5) People who want to outsource their broker to StormMQ and keep
> existing JMS code.
> 
> Paul
> 
> 
> -- 
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
> 
> blog: http://pzf.fremantle.org
> paul at wso2.com
> 
> "Oxygenating the Web Service Platform", www.wso2.com