We have been doing some POCs with RabbitMQ. However there is some debate going on if we need to move away from RabbitMQ to Webshpere MQ.
So ignoring the licensing factors purely from a technical standpoint can some one explain how this will work.
What is the performance for Webshpere MQ vs Rabbit MQ.
What are the integration aspects of Webshpere MQ with Spring framework.
Internally Websphere MQ i understand uses MQI, so how does this compare with AMQP.
Appreciate any pointers on the above questions.
I can't/won't speak to performance, but it shouldn't be too hard for simple PTP and Pub/Sub use cases.
RabbitMQ is much more flexible than JMS due to its many exchange types and decoupling of publishers and subscribers due to the rich exchange/binding mechanisms.
You can get some of that functionality using message selectors on the consumer side.
Spring (main framework) provides a JMS abstraction in the spring-jms jar - see the Spring Framework documentation.
Related
I wish to programmatically manage exchanges, queues, bindings, and view resource usage of my rabbitmq server. I can do all these by making REST API calls made available by rabbitmq management plugin. However, is it possible to achieve all that using AMQP protocol instead of using the management plugin? In other words, will an AMQP client allow me to do everything that the management plugin does?
If there is no alternative, is there any performance concern if I enable and use the management plugin?
In theory someone could implement a way that all the info is delivered via an AMQP queue. But it would have to be so that no consumer should ACK any of the messages because then they would be gone from the queue and the publisher would have to figure this out and publish the same thing again. In other words, it shouldn't be done.Also it would be semantically (?) wrong, since AMQP by it's nature is designed with flowing/changing/dynamic data in mind, and all this data about resources, queues etc is static (and in some cases meta) info.
No performance concerns (in this context of course).
Additionally you can also use the command line tool if it's more comfortable
AMQP 0.9.1 does not have any way of discovery or listing of queues and exchanges. Management plugin, on the other hand, has APIs such as GET /api/exchanges and GET /api/queues. Due to this requirement, management plugin was my only solution.
The only answer that I can find seems to say that the datapower appliance only support Websphere MQ, and it doesn't understand ActiveMQ brokers.
And, the documentation for Front Side Handler mentioned Queue managers, which ActiveMQ does not have.
Is there another way in datapower to fetch/poll messages from an activeMQ?
WDP does not support all possible brokers but just a few of them (Tibco, IBM etc). If you configure AMQ to provide a REST interface you can consume messages from it using plain HTTP instead of messaging.
REST/HTTP access to ActiveMQ won't be nearly as good as traditional OpenWire/AMQP connections. It will lack support for transactions and other things, but you can at least read messages.
I do not suggest using an ActiveMQ as messaging backbone for DataPower - go for IBM WebSphere MQ instead as they are nicely integrated. If you need to occasionally pull a message or two from an ActiveMQ broker - go for the above setup.
Is not Apache Kafka another implementation of JMS?
I am using JMS+AMQ in my application, and migrating to Apache Kafka. Do I have to change all JMS codes?
No, Kafka is different from JMS systems such as ActiveMQ.
see ActiveMQ vs Apollo vs Kafka
Kafka has less features than ActiveMQ, as the stress has been put on performances. So before migrating, check that the features you use in AMQ are in Kafka.
However, there is an open suggestion for a bridge between JMS and Kafka, to allow exactly what you need. Maybe the provided links can help you
https://issues.apache.org/jira/browse/KAFKA-1995
Actually, the two are not the same. And with a little more time seeing the two co-exist - and listening to problems and happy points from those deploying each in the field - there is a little more to say about each one.
Firstly, JMS supports both point-to-point messaging (where messages are sent to single consumers; the consumers themselves maintain their message queues) and the publish-and-subscribe (pub/sub) model (where messages are written to a single topic, and consumers, independently, decide which messages to consume).
In a point-to-point messaging architecture, message producers and consumers know each other, where as in a pub/sub model they do not. Apache Kafka focuses on a pub/sub model, maintaining a separate log/topic from which consumers read from offsets. Kafka is also built for the cloud, with high-throughput a core consideration.
Many in our community and at meetups throw their hands up in frustration at MOMs (message-oriented middlewares) like JMS and switch to Kafka, for, what boils down to one reason: scalability. They argue that Kafka is better suited for scale than other MOMs because Kafka maintains a partitioned topic log. In so doing, Kafka can split up message flow to groups of consumers by partition and batch transmit the messages.
This concept also allows Kafka to have more granular control over ACLs (access control) to Kafka Consumers, although there are some issues there, which Apache Pulsar is addressing.
Finally, on Kafka, since the client/consumer decides which messages to consume (by offset in the topic), this removes some of the producer-side complexity of routing rules built into MOMs like JMS.
There's more differences than that, but this is a distillation of some of the ones that keep coming up! Hope this helps.
No, Kafka uses its own non-standard protocol and clients.
However, there's a 3rd-party JMS Client for Kafka from Confluent.
NServiceBus Distributor/Worker pattern makes perfect sense for MSMQ due to the hard requirement of local input queues.
But this is not the case with RabbitMQ, I am trying to understand how and when the NServiceBus distributor is relevant with RabbitMQ. With RabbitMQ multiple workers can read from the same remote queue.
The actual scenario is similar to using an AWS auto-scaling group to scale out workers pointing to a high available RabbitMQ cluster. Now avoiding distributor altogether makes the setup much simpler to build, test and provision.
Thoughts?
As RabbitMQ transport falls into the broker style bus, so, in your use case, it would make more sense not to use the distributor.
The same goes for all broker-style transports, where you can use a competing consumer pattern to scale out.
NServiceBus is an excellent system and does wonders in most message queuing system where you don't have an integrated distributor (which you do with exchanges in RabbitMQ). We use NServiceBus here at our company.
Azure Queues and MSMQ are perfect examples of such queuing technologies.
NServiceBus handles the distribution internally and therefore reproduces this capability for you.
However... If you are blessed with the possibility of imposing what queuing technology you can use, then I would highly encourage you to look into RabbitMQ and a product (Open Source) called MassTransit
http://masstransit-project.com/
MassTransit can in turn function in the two modes and will either delegate or simulate the distribution for you - however I nonetheless have a soft spot for NServiceBus as do our senior devs here.
Per this page...
http://docs.particular.net/nservicebus/load-balancing-with-the-distributor
Using the distributor is only useful when using MSMQ - if you aren't using MSMQ then there is no point. RabbitMQ and other transport will allow access to the same queue from multiple consumers, while MSMQ will not. The distributor in a nutshell will take messages from the main queue and distribute them across multiple worker queues as they report that they are done with whatever they are working on.
We are looking at using ActiveMQ as the message transport with NServiceBus, instead of MSMQ, to enable Java endpoints to directly integrate with .NET endpoints over ActiveMQ.
By default NServiceBus endpoints run in a distributed transaction involving MSMQ and SQL Server. Is there the same level of support for distributed transactions in NServiceBus when the message transport is ActiveMQ? Are there any other drawbacks to using ActiveMQ with NServiceBus as compared to MSMQ?
We've actually uncovered issues with the .net client of ActiveMQ - it doesn't support distributed transactions well enough. While we've tried to work with the committers over there, we still haven't been able to get this fully resolved.
At this point in time, if you want to use ActiveMQ on .net (with or without NServiceBus) you'll have to take care of deduplicating any messages flowing through your system.
We're working hard to build this kind of infrastructure-level deduplication logic into NServiceBus such that queues like RabbitMQ and Azure Service Bus that don't support distributed transactions give the same behavior as MSMQ.
From the book Learning NServiceBus by David Boike:
Like MSMQ, ActiveMQ supports the DTC which ensures that our message handlers remain fully transactional.
As far as drawbacks go:
ActiveMQ server does not support DTC transactions for deferred messages.
Other issues are reported on the NServiceBus.ActiveMQ GitHub site. I recommend perusing the list.