Internet of Things Communication Protocol – JMS

Overview

JMS (Java Messaging Services) is a network used to establish successful communication between multiple units and applications within a specific system. Typically, it takes the form of an Application Programming Interface (API) that delivers messages from one application to another with the help of a queue path. JMS has the following characteristics:

• It is an API interface protocol that sends messages from one application to another.
• Assuming one application server is located in China and another application is located in another country/region, JMS creates a message and sends it from the host application to the recipient application that receives the message.
• JMS consists of a queue where it creates a message from one application, and the message will reside in the queue until the recipient application receives it.

A simple one-sentence description is: The Java Message Service (JMS) API is a messaging standard that allows Java Platform, Enterprise Edition (Java EE)-based application components to create, send, receive, and read messages. It enables loosely coupled, reliable, and asynchronous distributed communication.

Development History

Java Message Service was developed by Sun Microsystems (acquired by Oracle on April 20, 2009) as part of the Java Platform, Enterprise Edition. The first version of JMS, JMS 1.0.2b, was released on June 26, 2001. The stable version of JMS is JMS 2.0, released on May 21, 2013.

• JMS 1.0
• JMS 1.0.1 (October 5, 1998)
• JMS 1.0.1a (October 30, 1998)
• JMS 1.0.2 (December 17, 1999)
• JMS 1.0.2a (December 23, 1999)
• JMS 1.0.2b (August 27, 2001)
• JMS 1.1 (April 12, 2002)
• JMS 2.0 (May 21, 2013)
• JMS 2.0a (March 16, 2015)

The Java Community Process maintains JMS 2.0 under the name JSR 343.

JMS Technical Specifications

Messaging Models

JMS provides support for both Point-to-Point (P2P) and Publish/Subscribe (Pub-Sub) domains, and some JMS clients combine the use of both domains within a single application.

Point-to-Point (P2P)

1. This is a communication method where a sender (the one who creates and sends the message) can send a message to only one receiver (the recipient who receives the message) at a time.
2. This method uses a queue mechanism where messages are sent to a queue, i.e., the destination point. The sender sends the message to the destination, and the receiver in the destination can consume the message.
3. It is important that the receiver is registered to the destination; otherwise, the receiver cannot consume the message.
4. If no receiver is registered to the destination, the message will reside in the destination until any receiver registers with the destination to receive it.
5. Any sender can send a message, but only one receiver can consume that message.

Publish/Subscribe (Pub-Sub)

1. This communication method allows a sender to communicate a message to many receivers.
2. Unlike queues, it uses a topic as the destination point.
3. Therefore, in this method, all consumers must subscribe to the destination point.
4. After a message is sent from the sender to the destination point, all active receivers subscribed to the Topic can consume the message.
5. Unlike queues, a topic destination point cannot hold messages unless a subscribed consumer is inactive at the time of message delivery.
6. Such a subscription is called a durable subscription.

JMS Model Architecture

The JMS system consists of the following components:

• JMS Provider: A messaging system that implements the JMS specification.
• JMS Clients: Java applications that send and receive messages.
• Messages: Objects used to convey information between JMS clients.
• Administered Objects: Preconfigured JMS objects created by an administrator for use by JMS clients.

JMS Programming Model

A JMS application consists of a set of application-defined messages and a set of clients that exchange these messages. JMS clients interact by sending and receiving messages using the JMS API. A message consists of three parts: header fields, properties, and a body.

1. Header Fields: Every message requires header fields, which contain information used for routing and identifying the message. Some of these fields are set automatically by the JMS provider during message generation and delivery, while others are set by the client on a per-message basis.
2. Properties are optional and provide values that clients can use to filter messages. They provide additional information about the data, such as the process that created it, the time it was created. Properties can be thought of as an extension of the header, consisting of property name/value pairs. Using properties, clients can fine-tune their message selection by specifying certain values that act as selection criteria.
3. The Body is also optional and contains the actual data to be exchanged. The JMS specification defines six types or message classes that a JMS provider must support:

• Message: This represents a message without a message body.
• StreamMessage: A message whose body contains a stream of Java primitive types. It is written and read sequentially.
• MapMessage: A message whose body contains a set of name/value pairs. The order of entries is undefined.
• TextMessage: A message whose body contains a Java string... such as an XML message.
• ObjectMessage: A message whose body contains a serialized Java object.
• BytesMessage: A message whose body contains a stream of uninterpreted bytes.

JMS Interface Programming

1. ConnectionFactory Interface: (Connection Factory) A factory for creating Connections. Depending on the message type, users can choose to use a queue connection factory or a topic connection factory, corresponding to QueueConnectionFactory and TopicConnectionFactory respectively.
2. Destination Interface: Destination is a managed object that wraps a message destination identifier. A message destination refers to the location where messages are published and received, either a queue or a topic. There are two main types of objects: Queue and Topic.
3. Connection Interface: Connection represents a wrapper for an established connection (essentially corresponding to TCP/socket) between a client and the JMS system. A Connection can correspond to one or more Sessions. Like the connection factory, Connection also has two types: QueueConnection and TopicConnection.
4. Session Interface: Session is the interface for actually operating on messages, representing a single-threaded context for sending and receiving messages. Session is also divided into QueueSession and TopicSession.
5. MessageProducer Interface: A message producer is created by a Session and used to send messages to a Destination. Consumers can receive messages from queues and topics either synchronously or asynchronously. There are two types of producers: QueueSender and TopicPublisher.
6. MessageConsumer Interface: A message consumer is created by a Session and used to receive messages sent to a Destination. There are two types of consumers: QueueReceiver and TopicSubscriber.
7. Message Interface: The object passed between consumers and producers.
8. MessageListener: A message listener. If a message listener is registered, it will automatically call the listener's onMessage method when a message arrives.

Resources

JMS Specification

Eclipse Foundation

JSR 343: Java Message Service 2.0