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.
Related
I've been recently learning about vertx and websocket.
What I understood that you can have real-time application using them, but I didn't understand the difference between them
A websocket lets you push messages from server to client and vice-versa, encouraging the publish-subscribe methodology. Then what is vertx doing? It acts as an event bus and also encourages publish-subscribe model.
I can be completely wrong in my analysis, hence please correct me and I'll be glad. thanks.
WebSockets is a stateful protocol, usually used to communicate between clients and servers.
Vert.x is a server-side framework, which has a very good support for WebSockets.
You don't have to use WebSockets with Vert.x. But if you do want to use WebSockets, Vert.x is a great option.
Here's an article I wrote a few months ago about both:
https://medium.com/#alexey.soshin/playing-ping-pong-over-websockets-with-vert-x-447c634c6c87
I'm thinking about introducing QPid Broker-J as an AMQP broker in the architecture we're developing, for it's wide support of different versions of the AMQP protocol.
We would be only producers, while third-party software over which we wouldn't have much control would act as consumer(s).
Our producers would be written in C++, so the most sensible thing to do at first seemed to adopt Proton C++ as a client library, which uses the latest AMQP 1.0.
I then read that the 1.0 specification is a lot different from all previous ones and this raises a concern about the interoperability. In example, it doesn't say anything about exchanges.
So, my question is... can the two versions communicate? Do I still have access even from AMQP 1.0 clients to all the concepts I need like exchanges and queue management that are from AMQP 0-* clients?
Or should I rather drop the idea of using Proton C++ and adopt another client for an older version (0-9-1 seems like the most commonly supported). Which one, in this case?
I found this vaguely related question and some interoperability documentation about RabbitMQ Clients with QPid Broker-J, but neither of them unfortunately answers my question. Proton's documentation is not that good as well, and I couldn't find anything interesting there either.
Thanks in advance for your time.
In general Qpid Broker-J provides full interoperability between clients of the different AMQP versions as much as it is possible to do so.
In terms of concepts such as exchanges, as you observe, these are not defined in AMQP 1.0 itself, however Qpid Broker-J allows your AMQP 1.0 clients to send messages to exchanges (and also to "consume" directly from an exchange by - in the background - creating a temporary queue and binding it to the exchange).
In terms of queue/exchange management, 0-x clients can continue to use operations like queue.declare or exchange.declare. For AMQP 1.0 clients these commands are not available, however Qpid Broker-J does offer a couple of ways to manage queues for AMQP 1.0 clients. One option would be to use Qpid Broker-J's REST API to create/bind exchanges/queues etc. The other (undocumented) option is to use management messages to the special $management address. This is an implementation of the Draft OASIS AMQP Management specification (which is subject to change, hence it is not documented currently). You can find an example of its use in some of Qpid Broker-J's tests, e.g. org.apache.qpid.systests.jms_1_1.extensions.management.AmqpManagementTest with the test method testCreateQueueOnVirtualHostManagement() giving an example as to how to create a queue over AMQP management for example.
If you have any more questions on Qpid Broker-J I'd suggest mailing the users list for Qpid (users#qpid.apache.org) where the developers would be happy to answer any questions.
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
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.
The JMS is the vendor neutral API to messaging in the Java space. AMQP's mission is "to become the standard protocol for interoperability between all messaging middleware". I'm looking for a JMS client implementation that is interoperable between AMQP vendors. Specifically, it would be nice if it could talk to either RabbitMQ or Qpid.
The Qpid JMS client (which is, for the avoidance of effort, the same code as the OpenAMQ JMS client) encodes JMS in AMQP 0-9-1. I cannot speak for the quality of the client, but that should work for both Qpid Java edition and RabbitMQ.
It won't be an entirely lossless encoding, however -- there are some bits of API in JMS that don't carry across to AMQP. Qpid may have shims in place for those; RabbitMQ, by and large, doesn't. I am thinking specifically of 'nolocal' and selectors. There are probably others.
(Actually it /kind of/ does selectors using AMQP header exchanges, but the results may not be what you expect from JMS)
There is an effort to create a JMS client that uses AMQP 1.0. But there are no Qpid nor RabbitMQ releases that support AMQP 1.0, which is after all really an entirely different protocol to 0-9-1 and other prior versions.
I have used Apache Qpid client library (qpid-client-0.32-bin.tar.gz) with RabbitMQ (AMQP 0-9-1) recently and It worked very well.
If you want to connect to AMQP 1.0 Broker you should use this Qpid lib (apache-qpid-jms-0.1.0-bin.tar.gz)
Both libs can be downloaded from here:
http://qpid.apache.org/download.html
Qpid itself has a JMS client. I've never used it, but it is listed here under AMQP Client APIs
http://qpid.apache.org/