Introduction to JMS

What happens if the phone only has real-time calls and no messages and text messages? A phone call came, just didn't have time to pick up, then the phone to send the message must not be received. Why not save the information first and then get the information when the user needs to see it? Along with this doubts, short-term interest and message came into being, whether the phone is turned on or not, we can get the information. JMS provides something like this, and in this chapter we will learn about the important aspects of JMS in the system.

  ? 掌握JMS基本概念及适用范围  ? 点对点模型与发布/订阅模型的区别和使用场合  ? 熟悉核心和通用的JMS API  ? 熟悉并理解JMS客户端开发的步骤  ? 消息的同步和异步接收的实现方式  

Enterprise Messaging System

The Java Message Service, developed by Sun, provides a way for Java programs to access the Enterprise messaging system. Before we discuss JMS, let's break down the enterprise messaging system.
The Enterprise messaging system, message-oriented middleware (MOM), provides a mechanism for integrating applications in a loosely coupled and flexible manner. They provide asynchronous data transmission between storage-and-forwarding-based applications, where applications do not communicate directly with each other, but rather communicate with mom as a mediator. MOM provides guaranteed message delivery, and application developers do not need to know the details of remote procedure calls (PRC) and network/communication protocols. ACTIVEMQ is a good member of MOM.

Benefits of the Enterprise messaging system

Let's take a look at this, application a sends a message to the server, and then application B receives a send from the server, and through this diagram we analyze the benefits of JMS

Provides message flexibility

Application A communicates with application B by using the Application Programming Interface (API) of MOM to send messages. MOM routes the message to Application B, so that the message can exist in MOM, and mom is responsible for handling network traffic. If the network connection is unavailable, MOM stores the message until the connection becomes available, and then forwards the message to application B.
On the other hand the flexibility of the body now, when application A sends its message, application B can even not be in the execution state. MOM will keep this message until application B starts executing and tries to retrieve the message. This also prevents application a from blocking because it waits for application B to retrieve messages.
This asynchronous communication requires that the application be designed differently from most applications today, but it can be an extremely useful method for time-independent or parallel processing.

Loosely coupled

The real power of enterprise messaging systems is the loose coupling of applications. In the diagram above, application A sends a message specifying a specific target, such as "Order Processing." Now, the order Processing function is provided by Application B.
But in the future, we can replace application B with different order handlers, and application A will no longer be a smart choice. The replacement application will continue to send a message to complete "Order Processing", and the message will still be processed.
Similarly, we can also replace application A, as long as the replacement application continues to send the message for "Order Processing", and the order handler does not need to know if a new application is sending the order.

What is JMS

JMS is a collection of interfaces and related semantics through which the JMS client accesses the message system and completes the creation, sending, receiving, and reading of messages in the enterprise message system.
Prior to JMS, each MOM vendor used proprietary APIs to provide applications with access to their products, often in many languages, including the Java language. JMS provides a standard, convenient way for Java programs to send and receive messages through MOM. Programs written in JMS can run on any mom that implements the JMS standard.
The key to JMS portability is that the JMS API is provided by Sun as a set of interfaces. The product that provides the JMS functionality is done by providing a provider that implements these interfaces. Developers can build JMS applications to implement asynchronous communication by defining a set of messages and a set of applications that exchange those messages.

The target of JMS

Since its inception, JMS has been committed to the following goals:
defines a set of message common concepts and utilities.
All Java applications can use the APIs defined in JMS to complete the creation, reception, and delivery of messages, and any mom that implements the JMS standard can act as a mediator for the message and complete the storage and forwarding of the message.
maximizes portability of messaging applications.
MOM provides guaranteed message delivery, and application developers do not need to know the details of remote procedure calls (PRC) and network/communication protocols to provide portability of the program.
maximize the degree of coupling between your application and your application system.
Because of the presence of MOM, individual applications only care about how messages are received and sent between mom, without having to focus on the other side of mom and how other programs are received and sent.

JMS Two message models

JMS provides two types of message communication models:

  ? 点到点（P2P）模型  ? 发布/订阅（Pub/Sub）模型

As you can see, Clienta and CLIENTB are message producers, sending messages to Clientc, Clientd, Cliente, and clientf, respectively, through two different destinations.
The message between Clienta, C, and D is a point-to-point model, using which the client sends a message to the queue destination, where only one message receiver receives the message, and the other recipient that accesses the same destination does not receive the message. If CLIENTC receives the MSG1 message in the queue, CLIENTD receives the MSG2 message in the queue.
The message between CLIENTB, E, and F is the Publish/subscribe model. Using this broadcast model, a client sends a message to the subject destination (Topic), and any number of consumer subscribers can receive them from this subject destination. such as: Cliente and clientf both receive this MSG3 message.

Dot-to-point model

Point-to-point delivery model: A producer sends a message to a particular queue, and the consumer gets a message from a message queue, as shown in:

Features of Point-to-point models

? Each message has a consumer

  每条只有一个消费者，如果一条消息被消息者接收，那么其他的消费者就不能得到这条消息了。

? Sending and receiving messages has no relation to time

  也就是说，生产者在发送消息后，消费者可以在任意的时刻接收，但有两个前提：        1、消息未过期        2、消息没有被其他的用户接收  消费者也可以先运行，当生产者一运行，将消息发送到队列中，消费者即可从队列中获得消息，这叫“守株待兔“。

? Consumers must acknowledge receipt of the message

  收到消息后消费者必须确认消息已被接收，否则JMS服务提供者会认为该消息没有被接收，那么这条消息仍然可以被其他人接收。程序可以自动进行确认，不需要人工干预。

? Non-persistent messages are sent at most once

  非持久的消息最多只发送一次，表示消息有可能未被发送，造成未被发送的原因可能有：        1、 JMS服务提供者出现宕机等情况，造成非持久信息的丢失        2、 队列中的消息过期，未被接收

? Persistent messages are sent strictly once

  我们可以将比较重要的消息设置为持久化的消息，持久化后的消息不会因为JMS服务提供者的故障或者其他原因造成消息丢失。

Publish/Subscribe Model

Publish/Subscribe Model: The Publish/Subscribe delivery message type is related to the subject (TOPIC). The producer publishes the message, and the consumer subscribes to the message of interest, the producer connects the message to a specific subject (TOPIC), and the messaging System (MOM) delivers the message to the consumer based on the interest of the consumer registration. This type is very similar to the form of a published newspaper or magazine, as shown in:

Features of the Publish/subscribe model

? Each message can have more than one (0,1, ...). ) Subscribers

  每条消息可以有多个消费者，如果报纸和杂志一样，谁订阅了谁都可以获得。

? Subscribers can only consume messages published after their subscription

  这就要求订阅者必须先订阅，生产者再发布。即订阅者必须先运行，再等待生产者的运行，这和点对点类型有所差异。

? Subscribers must remain active to use these messages

  即订阅者必须保持活动状态等待发布者发布的消息，如果订阅者在发布者发布消息之后才运行，则不能获得先前发布者发布的消息。

Introduction to JMS