| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Comparison between IBM MQ and Apache ActiveMQ |
« View previous topic :: View next topic » |
| Author |
Message
|
| romankhar |
 Posted: Mon Mar 02, 2015 10:27 am Post subject: Comparison between IBM MQ and Apache ActiveMQ |
 |
|
Novice
Joined: 23 Jan 2014
Posts: 12
|
|
| Back to top |
|
 |
| JLRowe |
| Posted: Thu Jun 18, 2015 7:41 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
having used both products for a long time I would add the following from my experience:
slide 15:
XA is virtually useless on mq since you need to compile the switch files, we moved from WMQ 5.3 to 6.0 on oracle and dropped XA since the switch file was no longer supplied and we did not have expertise to compile our own
Atomikos is very easy to setup with AMQ and is an excellent XA manager
slide 16:
Give me JMX over MQAI any day, JMX can be exposed out of the box as REST, SNMP and is an open standard, MQAI is 100% proprietary. We monitored AMQ with nagios which has a JMX connector, whereas nagios support for WMQ is clunky because of the need to use MQAI
Command line tools:, active mq has plenty of command line tools, including the ability to browse messages which is missing from WMQ
The need for 3rd party tools is negated by open standards: java, imx, logging. ldap etc - as sited with the nagios example above, there simply isn’t the need for 3rd party activemq specific tooling
slide 17:
IP blocking / Proxy support / tunnelling etc - do what everyone else does and use other tools, this is not the job of MOM, use iptables, squid proxy etc
slide 23:
to me the biggest advantage of AMQ is that it is lightweight and can be spun up in unit tests (2/3 seconds max to start a broker), and then you can run performance tests as part of your unit tests, thats worth 10x a redpaper on performance in my book, shows that MY code/setup/config performs adequately every time I run a unit test
And this above is the BIG one, activemq is java, wmq is native code. WMQ needs to be installed, whereas AMQ lives in maven central and can be pulled into my build in seconds
slide 26:
ActiveMQ is a pure JMS provider, WMQ shuffles/maps parameters around and JMS on WMQ is a real PITA, plus the WMQ MQMD headers are fixed length. This is the disadvantage of a 1st mover, WMQ has a lot of of legacy to support
Managed file transfer: run camel, embeds within an AMQ broker and a lot more powerful than MQFT
slide 27:
TCO: most users don’t pay for AMQ and use it for free |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 18, 2015 7:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| JLRowe wrote: |
having used both products for a long time I would add the following from my experience:
slide 15:
XA is virtually useless on mq since you need to compile the switch files, we moved from WMQ 5.3 to 6.0 on oracle and dropped XA since the switch file was no longer supplied and we did not have expertise to compile our own |
I'm not sure that's true for later versions of MQ. Certainly problems with v6 should not be considered to be reasonable expectations of problems with v8.
| JLRowe wrote: |
| Atomikos is very easy to setup with AMQ and is an excellent XA manager |
Ok. It's probably pure java, too.
| JLRowe wrote: |
Give me JMX over MQAI any day, JMX can be exposed out of the box as REST, SNMP and is an open standard, MQAI is 100% proprietary. We monitored AMQ with nagios which has a JMX connector, whereas nagios support for WMQ is clunky because of the need to use MQAI
Command line tools:, active mq has plenty of command line tools, including the ability to browse messages which is missing from WMQ
The need for 3rd party tools is negated by open standards: java, imx, logging. ldap etc - as sited with the nagios example above, there simply isn’t the need for 3rd party activemq specific tooling |
This is certainly a reasonable idea. Except for your notion of what a third-party tool is. If AMQ doesn't come with it's own monitoring suite, that allows you to monitor your entire enterprise, then anything you use to monitor AMQ is in fact a third party tool.
| JLRowe wrote: |
slide 17:
IP blocking / Proxy support / tunnelling etc - do what everyone else does and use other tools, this is not the job of MOM, use iptables, squid proxy etc |
Right. For example using the MQ HTTP bridge that comes with the product, or the IPT supportPac that is fully supported by IBM.
| JLRowe wrote: |
slide 23:
to me the biggest advantage of AMQ is that it is lightweight and can be spun up in unit tests (2/3 seconds max to start a broker), and then you can run performance tests as part of your unit tests, thats worth 10x a redpaper on performance in my book, shows that MY code/setup/config performs adequately every time I run a unit test |
Except that those performance tests will be run on an environment that does not strongly simulate production hardware and tuning and does not necessarily match the software levels and configuration on the production hardware. So you still need additional performance testing.
And spinning up and deleting a queue manager is relatively quick for a very small environment. And faster to drop and recreate queues as needed.
Not to mention running WMQ inside docker.
| JLRowe wrote: |
| And this above is the BIG one, activemq is java, wmq is native code. WMQ needs to be installed, whereas AMQ lives in maven central and can be pulled into my build in seconds |
WMQ only needs to be installed once, and doesn't have to clutter up your source control system and doesn't have to be reinstalled every time you want to run a test.
| JLRowe wrote: |
slide 26:
ActiveMQ is a pure JMS provider, WMQ shuffles/maps parameters around and JMS on WMQ is a real PITA, plus the WMQ MQMD headers are fixed length. This is the disadvantage of a 1st mover, WMQ has a lot of of legacy to support |
which is only useful if you're running a lot of JMS.
| JLRowe wrote: |
| Managed file transfer: run camel, embeds within an AMQ broker and a lot more powerful than MQFT |
I've not run either of them, so I'm not going to express an opinion. But file transfer is very much a more complicated problem that people think it is, and requires well behaved applications on both ends. And the file transfer tooling doesn't fix that.
| JLRowe wrote: |
slide 27:
TCO: most users don’t pay for AMQ and use it for free |
That's not TCO. That's license cost. TCO encompasses the entire life cycle of the product, including the time needed to resolve production issues.
I'm glad you have an environment that works well for you with technology that you're happy with. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
