We currently use JMS API with ActiveMQ broker, looking over to move to RabbitMQ.
Compared to openWire vs amqp which one would give best performance with java client-producer. I Couldn't find a comparison study on amqp(RabbitMQ) vs openwire (activeMQ) native protocol. I'm looking in terms of raw performance and ease of scalability.
We currently use Spring Integration for ActiveMQ, I would like to know if its a drastic change to move to RabbitMQ(AMQP) even with Spring Integration. Is there any bridge similar to what ActiveMQ uses to do JMS<->AMQP forwarding ?
ActiveMQ also supports AMQP: http://activemq.apache.org/amqp.html
Both are binary protocols. Openwire is going to be more full-featured when using ActiveMQ.
For "raw performance" you'll have to nail down your use cases first. Chances are the protocol you choose (ampq vs openwire) is not going to make any difference from a "perfomance" standpoint.
ActiveMQ now implements AMQP.
You can specify multiple communication protocols and let ActiveMQ auto detect determine which to implement:
http://activemq.apache.org/auto.html
Related
I'd like to use regular AMQP or JMS clients to connect to a Solace message broker but don't know enough about these protocols to know if they are compatible. From what I can tell Solace implements AMQP and JMS bu possibly with incompatible extensions (e.g. "message vpn").
Does Solace have incompatible extensions, particularly for JMS, or is there a straightforward way to get a JMS client to speak to a Solace broker with "message vpn" enabled?
The choice is yours as Solace provides both a JMS client implementation and it also supports AMQP 1.0.
Keep in mind that JMS is an API and AMQP is a protocol. The JMS API can be implemented over any suitable wire protocol, and AMQP can be exposed via any suitable API. JMS is Java-based and there are many JMS implementations using different protocols under the covers. There are also many AMQP clients written in different languages on different platforms all with different APIs. There are even projects which combine both JMS and AMQP like Qpid JMS.
Solace's PubSub+ event broker works on binary payloads which means that you can indeed publish and consume messages on cross protocols and APIs.
The Solace APIs have detailed documentation on how to process the payload in a type agnostic fashion.
As you can see in this diagram, we support a wide range of APIs and protocol integrations.
There are also sample codes present over at this Github account listing examples on using Solace broker with JMS and AMQP : https://github.com/SolaceSamples?
(Answering my own question).
I basically wanted to know if it was possible to connect to a Solace/JMS broker using more popular messaging libraries. As far as I can tell the answer is no in general.
For example,
one feature of JMS is JNDI lookup of the InitialContextFactory. I don't think that is possible to do outside of a JMS library.
Does anybody has an example how to connect ActiveMQ OpenWire protocol using go please?
I used stomp & amqp with ActiveMQ for now and both are ok (testing), but our it architect will probably push for OpenWire as almost all our applications are Java based and that is standard for our company. So I would be happy for nay example, suggestions how to do it and not loose go service only because OpenWire protocol
thanks
Take a look at the ActiveMQ OpenWire documentation. It has a link to a handful of Java classes which are used to generate C, C#, C++, & Java client code. You could probably use those as examples to create your own files to generate Go client code which can speak OpenWire.
That said, you're probably better served by using the Go AMQP or STOMP clients as ActiveMQ was designed to be used by multiple protocols.
Thank you for answers. I agree with stomp & amqp as sufficient for task and agree that write OpenWire client just for sake of it is not good option. I have to convince our architects now
AMQP and OpenWire clients can co-exist and is by far the best solution for you, even though you have a Java-stack.
Your second best bet is to write some glue code in Java/C#/C++ that connects an OpenWire AMQ client with something that GO can speak to (like another ActiveMQ using AMQP or STOMP ;-) ).
If you really really really need OpenWire support, the best bet is to try to use the C++ client and call it using swig or whatnot.
Writing a native OpenWire-client in Go is a major effort and there is no point, except as a "fun" task.
I am new to JMS.
I am little aware of RabbitMq and now trying to find the difference in rabbitMQ with JMS. How it is used and why it should be used?
Thanks in advance.
JMS is a Java API (part of JEE).
JMS Vendors use a proprietary protocol to talk to the broker; they are not wire-compatible.
You can generally talk to any JMS broker by just changing vendor-specific configuration (connection factory etc).
Vendors provide a JMS client library to talk to their brokers.
AMQP is a wire protocol, not an API.
Vendors provide a Java client API.
You can use Spring AMQP, which sits on top of RabbitMQ's amqp-client library and its API.
You can use Spring JMS, which talks to any JMS broker (including RabbitMQ with the plugin) using the JMS API.
If you need to be compatible with any JMS vendor, use spring-jms; if you only intend to use RabbitMQ, I would recommend using Spring AMQP.
Or, use Spring Integration on top of either one, and you can switch between AMQP and JMS by just changing configuration.
I'm not sure what you mean by RabbitMQ for JMS. But, i'll list out the differences below.
RabbitMQ
Works on AMQP protocol and it is not a J2EE specification
Applications written in several languages can produce and consume messages(Python, Ruby, Java, C#, Perl etc.,)
Does not work with J2EE specs, so you cannot use XA Transactions, bean pools, connection factory pools which are all provided by J2EE container by default
Community is not so mature, but, if your organization needs to communicate with a lot of different types and languages of applications you can sacrifice all the beautiful features that are provided by J2EE/JMS spec.
JMS
It is J2EE specification, any application server that provides JMS support should follow the guidelines mentioned in the spec.
Only the Java/J2EE applications can produce and consume, it can be made to work for other languages but with use of adapters
J2EE container provides XA Transaction, Bean pooling, Connection pooling etc., out of the box with little configuration at your end.
If your organization only uses Java based applications, you need not look in RabbitMQ way as you have JMS support which works well.
I heard a guy from IBM give a talk about MQTT and he said that MQTT is the most lightweight messaging protocol as of today. His argument was that the smallest overhead produced for a single message is 2 bytes. However, I've heard the very same (2 bytes overhead) about HTML5 WebSockets too? Anyways, as I plan to use Open MQ as a JMS provider for a messaging application, which protocol my provider use became of interest to me. I cannot anywhere find the answer to that question and I even googled the Open MQ documentation and the documentation of GlassFish which use Open MQ as a JMS provider. Some blog posts and the like on Internet says AMQP but I cannot find a solid reference to back that statement up.
Which protocol does Open MQ use, and how would you know?
I think you mix a few things up: MQTT is an application level protocol and uses TCP as transport protocol. MQTT can also be used with Websockets as transport. MQTT is, if you will, a lightweight alternative to JMS and AMQP.
AMQP is a popular and reliable alternative to JMS and is well suited for business and mission critical messaging. It is very feature rich and widely used. Note that AMQP is a messaging protocol while JMS is an API (which can even use AMQP as transport). You can use AMQP directly in Java Applications with Libraries such as the RabbitMQ Java Client.
MQTT on the other hand is perfect fit for telemetry data and scenarios where you have many clients which communicate with a single message broker and where low bandwidth usage, memory efficiency and battery life on the clients is key.
JMS does not define any transport protocol (in contrast to MQTT) and anything could be used here. I personally think TCP is a good fit here, too.
I do not know about OpenMQ but for JMS and AMQP I can recommend ActiveMQ. For MQTT there are a few brokers out there including HiveMQ and Mosquitto.
Obligatory Disclaimer: I am a developer of HiveMQ, so I am probably a bit biased ;-)
I think OpenMQ is using STOMP as Application Level Protocl. There is no other documentation which protocol OpenMQ supports than STOMP.
Edit: found the UMS Protocol and it seems OpenMQ is using this per default. https://mq.java.net/4.3-content/ums/umsIntro.html
OpenMQ is not able to use AMQP so I would recommend RabbitMQ.
I'm developing a messaging system and I used JBoss Netty + Google protobuf for the POC. protobuf was chosen for its swiftness of serialization/deserialization, relatively low traffic cost and availability in several languages.
Still, when it comes to production under heavy load a self-coded server application can never be as good as well-established and tested frameworks.
The problem is, I can't find such a framework that would allow me using protobuf as a transport protocol. Apache ActiveMQ and ActiveBlaze are the closest things I could find but the documentation is nearly absent.
I stumbled upon something that is ActiveMQ protobuf implementation but there is no reminding of it in official ActiveMQ documentation (its not among the supported protocols).
So my question is whether AMQ supports protobuf and if it does how it can be integrated?
No, ActiveMQ uses its own OpenWire protocol or the Stomp protocol. The protobuf bits are used for the underlying KahaDB Message store not the wire level portion. You can store your protobuf data in a BytesMessage and transmit it that way to allow you to marshal and unmarshal the data on either end.