I try to dive into messaging in java. I am investigating RabbitMq and AMQP protocol. First of all I repeated several examples from https://spring.io/guides/gs/messaging-rabbitmq/ and examples from https://www.rabbitmq.com/
Now I want to learn it more detailed.
Official site feature section looks like advertisement. It says that RabbitMQ supports several protocols:
AMQP 0-9-1, 0-9 and 0-8, and extensions
STOMP
MQTT
AMQP 1.0
HTTP
But I can't understand why should I choose one of them.
Can you share your thoughts?
RabbitMQ is a way of exchanging data between processes, applications, and servers. As you say, you can choose one of the several protocols it support.
Your election will depend on which applications or systems you want to interconnect. For example:
MQTT: is a lightweight protocol with a low footprint ideal for communication between resource-constrained devices with low bandwidth, like embedded systems.
STOMP: is text-based, making it more analogous to HTTP and useful in messaging with web servers.
As you can see, each protocol has its advantages and drawbacks and your election will depend on which one adapts better to the application you want to build.
For a more detailed description of each protocol see this link
The protocol only defines the communication between the client and the server and has no impact on a message itself. One protocol can be used when publishing and you can consume using another protocol.
AMQP (Advanced Message Queuing Protocol): RabbitMQ was originally developed to support AMQP which is the "core" protocol supported by the RabbitMQ broker. AMQP was designed to efficiently support a wide variety of messaging applications and communication patterns. Routing is a feature in AMQP, the process by which an exchange decides which queues to place your message on. Messages in RabbitMQ are routed from the exchange to the queue depending on exchange types and keys. (You got more complex routing options in AMQP compared to MQTT). RabbitMQ implements version 0-9-1 of the specification today - with legacy support for other versions. AMQP 1.0 is a radically different protocol from AMQP 0-9-1 / 0-9 / 0-8.
MQTT (Message Queue Telemetry Transport) with its minimal design makes it perfect for built-in systems, mobile phones and other memory and bandwidth sensitive applications. A specific task may as well be achieved using AMQP, but MQTT might be a more appropriate choice of protocol for this specific type of scenarios.
HTTP (Hypertext Transfer Protocol) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP is not a messaging protocol. However, RabbitMQ can transmit messages over HTTP.
STOMP (Simple or Streaming Text Oriented Message Protocol), is a simple text-based protocol used for transmitting data across applications. It is much simpler and less complex protocol than AMQP, it is more similar to HTTP. STOMP clients can communicate with almost every available STOMP message broker, this provides easy and widespread messaging interoperability among many languages, platforms and brokers. It is, for example, possible to connect to a STOMP broker using a telnet client.
Source: https://www.rabbitmq.com/protocols.html and https://www.cloudamqp.com/docs/protocols.html
I'm new to JMS and now trying to integrate it with my applications. I've decided to use apachemq jars at the client side.
So, if I avoid the communication through the message broker ApacheMQ and communicate between the parts of the application directly, will it make a sense? Is the main benefit of the JMS API lost in that case?
Couldn't someone explain it in a nutshell?
JMS is a API specification that describes how applications can send and receive messages through messaging middle-ware in a standard way and is portable across multiple JMS providers. Without a middle-ware (or broker), just the JMS APIs is of no use. So you need both, broker and JMS API implementation provided by that broker.
I want to know if JMS API uses any protocol to transfer messages or if uses its own. If the former, which protocol?
I have read many articles over the net but I couldn't find an answer for this.
The standard JMS API is merely a set of interfaces; JMS providers (such as WebSphere MQ) provide their own implementations for these interfaces.
The only thing that you can say for sure about all JMS implementations is that they all adhere to the JMS API; other than that, a JMS implementation may use any protocol whatsoever in order to fulfill the JMS API contracts.
Now, when you're asking specifically about "protocols", you should also define which "layer" in the communication you are referring to (have a look at the OSI Model, for example). When your JMS client has to talk to a JMS server that is located on another machine on the network (a typical case), the protocol used between the client and the server will be based, in one way or another, on TCP/IP. Over the wire, you'll be able to see TCP/IP packets being exchanged back and forth.
At the higher level, there are no guarantees; you are likely to find proprietary protocols varying between different implementors. Remember that, with JMS, performance is often crucial; JMS vendors put a lot of efforts into ensuring that their protocols ("above" TCP/IP) perform well. HTTP, for example, won't do.
There is no protocol as such that is mentioned in the JMS specs. It is purely dependent on the JMS provider and his approach to offer efficiency and security.One thing that er can be sure of is that whatever protocol provider uses to communicate between server and client will be built upon the TCP/IP protocol(Transport layer). You may have HTTP which is an application layer protocol or if the provider provides it you may have SSL which is a Presentation layer protocol.
For example ActiveMQ supports following protocols
AMQP
List item
MQTT
OpenWire
REST
RSS and Atom
Stomp
WSIF
WS Notification
XMPP
More details here.
It uses AMQP protocol. You can use JMS to do 1-to-1 communication using Message Queue provided by Middleware. If you want to send 1-to-many using JMS, the middleware provides Topic. Both of them use binary format in a bit stream at least in IBM MQ.
I am getting into Message Queueing recently (with ActiveMQ) and experimenting.
So far I have been able to set up one producer with 2 consumers written in Java implementing JMS over Tcp. The producer sends 2 types of messages to the queue in ActiveMQ, while at the other end, 2 consumers from a different machine pick up the messages based on the message properties.
My question was:
Does the consumer/producer need to implement the same protocol, or
Would it be possible to have a producer send messages to the Queue with JMS and
have a client (like node js) use another protocol (like AMQP) and collect messages from the same queue?
Thank you for your advice,
Probably the answer to your question is documented at Oracle's JMS as a MOM Standard:
It’s important to note that JMS is an API standard, not a protocol standard. Because all JMS clients implement the same interface, it is easy to port one vendor's clinet to another vendor's JMS provide implementation. But different JMS vendors typically cannot communicate directly with one another.
ActiveMQ implements the standard JMS client library using it's own protocol (OpenWire) however it also supports several other protocols allowing you to connect from other client like an MQTT client, STOMP client or an AMQP client and consume / produce from a Queue.
To see how to use AMQP for instance refer to the ActiveMQ docs and for best results use the latest release of ActiveMQ.
I am trying to understand what JMS and how it is connected to AMQP terminology.
I know JMS is an API and AMQP is a protocol.
Here are my assumptions (and questions as well)
RabbitMQ uses AMQP protocol (rather implements AMQP protocol)
Java clients need to use AMQP protocol client libraries to connect / use RabbitMQ
Where does JMS API come into play here? JMS API should use AMQP client libraries to connect to RabbitMQ?
Usually we use JMS to connect Message brokers like RabbitMQ, ActiveMQ, etc. Then what is the default protocol used here instead of AMQP?
Some of the above may be dumb. :-) But trying to wrap my head around it.
Your question is a bit messy but Let's see its bits one by one.
General concept:
The Java Message Service (JMS) API is a Java Message Oriented Middleware (MOM) API for sending messages between two or more clients. JMS is a part of the Java Platform, Enterprise Edition, and is defined by a specification developed under the Java Community Process as JSR 914. It is a messaging standard that allows application components based on the Java Enterprise Edition (Java EE) to create, send, receive, and read messages. It allows the communication between different components of a distributed application to be loosely coupled, reliable, and asynchronous.
Now (from Wikipedia):
The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The
defining features of AMQP are message orientation, queuing, routing
(including point-to-point and publish-and-subscribe), reliability and
security.
And the most important thing (again from Wikipedia):
Unlike JMS, which merely defines an API, AMQP is a wire-level
protocol. A wire-level protocol is a description of the format of the
data that is sent across the network as a stream of octets.
Consequently any tool that can create and interpret messages that
conform to this data format can interoperate with any other compliant
tool irrespective of implementation language
Some important things you should know:
Keep in mind that AMQP is a messaging technology that do not implement the JMS API.
JMS is API and AMQP is a protocol.So it doesn't make sense to say that what is default protocol of JMS, of course client
applications use HTTP/S as the connection protocol when invoking a
WebLogic Web Service.
JMS is only a API spec. It doesn't use any protocol. A JMS provider (like ActiveMQ) could be using any underlying protocol to
realize the JMS API. For ex: Apache ActiveMQ can use any of the
following protocols: AMQP, MQTT, OpenWire, REST(HTTP), RSS and Atom,
Stomp, WSIF, WS Notification, XMPP. I suggest you read Using
JMS Transport as the Connection Protocol.
Good Luck :)
Let's start from the basis.
RabbitMQ is a MOM (Message Oriented Middleware), developed with Erlang (a TLC-oriented programming language) and implementing the wire protocol AMQP (Advance Message Queuing Protocol).
Currently, many Client APIs (e.g., Java, C++, RESTful, etc.) are available to enable the usage of RabbitMQ messaging services.
JMS (Java Messaging Service) is a JCP standard defining a set of structured APIs to be implemented by a MOM. An example of MOM that implements (i.e. is compatible with) the JMS APIs is ActiveMQ; there's also HornetMQ, and others. Such middlewares get the JMS APIs and implement the exchange patterns accordingly.
According to above, taken the skeleton of JMS APIs, an instance of RabbitMQ and its Java Client APIs, it is possible to develop a JMS implementation making use of RabbitMQ: the only thing that one has to do, at that point, is implementing the exchange pattern (over RabbitMQ) according to the JMS specification.
The key is: a set of APIs, like JMS, can be implemented no matter of the technology (in this case, RabbitMQ).
JMS, when it was defined did not define a protocol between the JMS client and a messaging server. The JMS client, which implement the JMS API can use whatever protocol to communicate with messaging server. The client just need to be compliant with JMS api. Thats all. Ususally JMS clients use a custom protocol that their messaging server understands.
AMQP on other hand is a protocol between a messaging client and messaging server. A JMS client can use AMQP as the protocol to communicate with the messaging server. And there are clients like that available.
http://www.lshift.net/blog/2009/03/16/openamqs-jms-client-with-rabbitmq-server
Where does JMS API come into play here? JMS API should use AMQP client libraries to connect to RabbitMQ?
JMS is an API, so some JMS API's are implemented over the AMQP protocol (like Apache QPID JMS) while most JMS APIs use other protocols. If the version of the AMQP protocol is the same, such a client should be able to communicate with another AMQP client.
Usually we use JMS to connect Message brokers like RabbitMQ, ActiveMQ, etc. Then what is the default protocol used here instead of AMQP?
It depends on your configuration of that JMS API. For ActiveMQ, it could be AMQP but by default it is 'openwire'
What is JMS?
JMS is a Java standard that defines a common API for working with message brokers.
Why do we need JMS?
It was introduced in 2001 and was adopted approach for a very long time for asynchronous messaging.
Before JMS, what used to happen was each message broker had a proprietary API, making an application’s messaging code less portable between brokers.
With JMS, all compliant implementations can be worked with via a common
interface. So, if you are changing your broker say "Apache Active MQ" to "Apache ActiveMQ Artemis" you don't have to worry about the portability issues as the JMS interface ensures your code portability.
Cons of JMS?
JMS in 2001, when it was defined didn't enforce any protocol between the JMS client and the JMS messaging server. JMS client could have used any protocol for communication and the client needed to make sure a protocol that was compliant with the JMS API.
JMS is limited to Java applications.
What is AMQP?
AMQP (Advanced Message Queuing Protocol) is kind of an open standard application layer protocol for delivering messages.
AMQP 0.9.1 was published in November 2008.
AMQP provides a description of how a message should be constructed. Unlike JMS, it doesn't provide an API on how the message should be sent.
Why AMQP?
AMQP is just a protocol between a messaging client and the messaging server. So even a JMS client can use AMQP as the protocol to communicate with the messaging server.
AMQP is a messaging protocol that stands across all platforms. It doesn't matter which AMQP client is used, as long as it's an AMQP complaint, it will hold.
JMS is an API from Sun - Oracle.
There are drivers that implement this API. For each language and each messaging system, there will be at least one driver. E.g. for Java + RabbitMQ -> a driver, for Java + ActiveMq, for C# + RabbitMQ, Go + IBM MQ etc.
AMQP is a wire level protocol much like MQTT or STOMP or Openwire. It is not an API. This brings up two new things:-
Messaging system may need a plugin to support the wire level protocol, e.g. ActiveMQ STOMP plugin etc.
Driver needs to support the wire level protocol by converting standard JMS API calls to STOMP, aMQP etc calls.
Finally, thus you can have one driver per -> messaging system + API + wire level protocol
Java code -> API -> Driver -> wire level protocol -> plugin -> Messaging system
https://spring.io/understanding/AMQP
AMQP (Advanced Message Queueing Protocol) is an openly published wire
specification for asynchronous messaging. Every byte of transmitted
data is specified. This characteristic allows libraries to be written
in many languages, and to run on multiple operating systems and CPU
architectures, which makes for a truly interoperable, cross-platform
messaging standard.
AMQP is often compared to JMS (Java Message Service), the most common
messaging system in the Java community. A limitation of JMS is that
the APIs are specified, but the message format is not. Unlike AMQP,
JMS has no requirement for how messages are formed and transmitted.
Essentially, every JMS broker can implement the messages in a
different format. They just have to use the same API.
I suspect you may be looking for this documentation which says, in part:
JMS Client for vFabric RabbitMQ is a client library for vFabric
RabbitMQ. vFabric RabbitMQ is not a JMS provider but has features
needed to support the JMS Queue and Topic messaging models. JMS Client
for RabbitMQ implements the JMS 1.1 specification on top of the
RabbitMQ Java client API, thus allowing new and existing JMS
applications to connect with RabbitMQ brokers through Advanced Message
Queueing Protocol (AMQP).