Message Queue for RabbitMQ provides a Java Message Service (JMS) client library for JMS clients to connect to Message Queue for RabbitMQ. This topic introduces the concepts related to the JMS client library that Message Queue for RabbitMQ provides. This topic also describes the limits of the JMS client library and shows you how to obtain and use the library.

Background information

JMS is a messaging standard that allows application components based on the Java Platform, Enterprise Edition (Java EE) to create, send, receive, and read messages. JMS enables communication between distributed applications in a loosely coupled, reliable, and asynchronous manner. The JMS client library of Message Queue for RabbitMQ supports JMS 1.1.

JMS client library of Message Queue for RabbitMQ

The JMS client library of Message Queue for RabbitMQ is the JMS API provided by Message Queue for RabbitMQ. To connect JMS applications to Message Queue for RabbitMQ by using the JMS API, you need only to modify a small amount of code. Then, JMS applications can use Message Queue for RabbitMQ as a JMS provider. You can use the JMS client library of Message Queue for RabbitMQ to create JMS connections, sessions, producers, and consumers.

For more information about differences between JMS and AMQP, see Differences between AMQP and JMS.

Obtain the JMS client library

You can use one of the following methods to obtain the JMS client library of Message Queue for RabbitMQ:

  • Add the following dependency to the pom.xml file in your Maven project: 
    <dependency>
    <groupId>com.alibaba.mq-amqp.jms</groupId>
    <artifactId>mq-amqp-jms-client</artifactId>
    <version>1.11.2-1.0.0</version>
    <exclusions>
        <exclusion>
            <groupId>com.rabbitmq</groupId>
            <artifactId>amqp-client</artifactId>
        </exclusion>
    </exclusions>
</dependency>
  • Download the JAR file of the dependency.

Limits

The JMS client library of Message Queue for RabbitMQ has the following limits:

  • Server sessions are not supported.
  • The interfaces for XA transactions are not implemented.
  • Topic selectors are supported. Queue selectors are not implemented.
  • Secure Sockets Layer (SSL) and socket options are provided. However, only the default SSL connection protocol provided by JMS clients for Message Queue for RabbitMQ can be used.
  • The NoLocal subscription feature is not supported. This feature prevents a consumer from sending messages from its own connection. You can call a method that contains the NoLocal argument. However, the call will be ignored.

For more information about the implementation of the JMS API provided by Message Queue for RabbitMQ, see Compatibility.

Tutorial

The following table describes how to use the JMS client library of Message Queue for RabbitMQ.

Messaging model Description References
P2P The JMS point-to-point (P2P) messaging model has the following features:
  • Each message has only one consumer. After a producer sends a message to a queue, a specified consumer registered for the queue can receive the message.
  • Producers and consumers have no timing dependencies. Producers can send messages to queues regardless of whether consumers are active. Consumers can receive messages from queues regardless of whether producers are active.
Pub/Sub The publish/subscribe (Pub/Sub) messaging model has the following features:
  • Each message can have multiple consumers. After a producer sends a message to a topic, all consumers that subscribe to the topic can consume the message.
  • Producers and consumers have timing dependencies.
    • If a consumer creates a nondurable subscription, the consumer must subscribe to a topic before a producer sends a message to the topic. In addition, the consumer must remain active to consume all the messages sent to the topic. If a message is sent when the consumer is inactive, the consumer cannot consume the message after it becomes active.
    • If a consumer creates a durable subscription, the consumer must subscribe to a topic before a producer sends a message to the topic. However, the consumer does not need to remain active to consume all the messages sent to the topic. If a message is sent when the consumer is inactive, the consumer can consume the message after it becomes active.