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.
Related
What exactly is Solace JCSMP?
Is it just a more suited JMS API for Solace? What kind of other benefits does it have?
For example, I would need to create a Java application using SolaceMQ that needs to send/receive messages over to/from AMQP protocol so that all different microservices written in different languages would be able to consume them. Is JCSMP right for that? or is it just another JMS API that it only works between Java applications?
What exactly is Solace JCSMP?
JCSMP is the Classic Java API for Solace's SMF (Solace Message Format) protocol. Note that Solace recently introduced a more modern messaging API for java devs using their event brokers that is just referred to as the "PubSub+ Messaging API for Java". If you are new to Solace and using Java it may make sense to use that instead of JCSMP.
Is it just a more suited JMS API for Solace? What kind of other benefits does it have?
JCSMP allows developers to take advantage of the full feature set offered by the Solace Broker whereas the Solace JMS implementation only covers the features defined in the JMS specification itself. For example, use of Solace features such as Replay or having Queues subscribe to Topics are not programmatically possible via the JMS API and would have to be done administratively if using JMS.
For example, I would need to create a Java application using SolaceMQ that needs to send/receive messages over to/from AMQP protocol so that all different microservices written in different languages would be able to consume them. Is JCSMP right for that? or is it just another JMS API that it only works between Java applications?
Solace PubSub+ Event Brokers provide protocol translation between any of the protocols supported by the broker. It doesn't matter whether you are using SMF (which both Solace JMS and JCSMP use), MQTT, AMQP 1.0, etc. or what programming language you are using. For example when you send a message using JCSMP you can receive it using a Java app using JMS, a Python app using AMQP and a Go app using MQTT. The Solace Event Broker even has support for calling a RESTful webhook using it (Check out Solace "Rest Delivery Endpoints"). Just a heads up that if you're using headers you'll want to checkout the Solace docs to see how they're mapped during protocol translation.
NEWBIE Question here, maybe I am way off...
When I send a JMS text message to an ActiveMQ topic using the activemq-all jar, is a JMS message actually sent over the wire, or does ActiveMQ actually map/transform the message to pure AMQP?
Thanks.
JMS is an API specification and not a wire level protocol specification. It defines a set of APIs a Messaging provider must implement to call the messaging provider a JMS provider. How the JMS APIs are implemented is internal to the implementer. ActiveMQ might(or does) use AMQP protocol under the hood to implement JMS APIs. Others, for example, IBM MQ uses it's own proprietary protocol.
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/
We use RabbitMQ and Spring-AMQP for our messaging system.
However there are many Java libraries that use JMS that I would rather not rewrite to AMQP.
I failed to Google a JMS client that will use AMQP.
Should I just rewrite the library to use AMQP directly?
qpid , which also speaks amqp , has a JMS client library. Perhaps that also works with rabbitmq.
There's some (old) indications the OpenAMQ library works works with rabbitmq
Depending on what you're actually building, you'll probably find that Spring Integration is useful:
http://www.springsource.org/spring-integration
It abstracts the concepts of end points, such that they are pluggable and there is built-in support for JMS & AMQP.
It's fairly trivial to build a simple AMQP <-> JMS adapter.