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.
Related
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.
A lot of materials about Service Bus mention that it uses AMQP 1.0. However, examples I have found use libraries that hide away AMQP layer, so it is not obvious how would one use generic AMQP 1.0 client and do things
that are listed in this Service Bus example
Being able to use independent AMQP client instead of supplied higher level clients might be important in several scenarios. For instance supplied clients might not be available at some platforms, or generic clients might provide more suitable way of working for particular problem.
Possibly related question
Little bit further from .net example I had linked in question I have found following example of how to access Service Bus with Proton AMQP 1.0 Python library. It shows how to send and receive messages.
What is lacking in that example, is how to create and manage queues and topics. It appears that this is not possible from AMQP interface, and needs to be done out of the band through either web azure console, or through REST interface.
I have just read about CORBA and JMS, they both seem to be used to implement
Broker Architecture/Pattern.
I have few questions regarding them
1.The differences between them are still not clear to me, anybody please explain ?
2.Is CORBA is used in today's IT Solutions ? Or is it losing charm ?
3.Does JMS can replace every aspect of CORBA ?
Ramon Gil Moreno is right in stating that
JMS is the Java API that allows building applications to send and
receive messages. IBM MQ or ActiveMQ are samples of JMS vendors that
implements this API.
CORBA on the other hand is a specification that specifies how objects can interact with each other over a network across programming languages and run-time platforms.
The standard includes many APIs and infrastructure definitions (language bindings, marshalling, naming etc.), that are needed to support this. CORBA is still being used, and is Open Source as well as commercial (hard to find!)
Implementations exist, but I doubt if any of them covers 10% of the standard. Ramon's statement that CORBA is closer to RMI is a bit too simple - CORBA 2.4+ definitions include a CORBA Messaging definition that allows asynchronous and (reliable) queued communication.
CORBA, which is not hot nowdays, allows objects to be used remotely by different systems. It is more similar to RMI.
JMS is the Java API that allows building applications that send and receive messages. IBM MQ or ActiveMQ are samples of products that implements this API.
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.