Simple introduction of JMS (a)--JMS

What if the phone can only make real-time calls, without 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 in the time. JMS provides similar functionality, and in this chapter we will learn about the important aspects of JMS in the system.

Ø Mastering the basic concept of JMS and its scope of application

Ø difference between point-to-point model and advertisement/subscription model and use occasions

Ø familiarity with the core and common JMS APIs

Ø familiar with and understand the steps of jmsclient development

Ø the implementation of message synchronization and asynchronous reception

Ø the method of solving the problem of string package

Enterprise Messaging System

The Java Message Service, developed by Sun, provides a way for Java programs to access enterprise messaging systems. 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

Figure 1 JMS Communication

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 handles network traffic. Assuming that the network connection is not available, MOM stores the message until the connection becomes available, and then forwards the message to application B.
There's also the aspect of flexibility. Now, when application A sends its message, application B can even be out of the running state. MOM will keep this message until application B starts running and tries to retrieve the message. This also prevents application a from clogging up by waiting for application B to retrieve messages.
Such asynchronous communication requires that the design of the application is different from most applications today, but it may be a very de facto 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." Today, the order Processing feature 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 the message complete "Order Processing", and the message will still be processed.
Same, we can also replace application A, just to replace the application to continue sending messages for "order Processing", the order handler does not need to know if there is a new application in the sending order.

What is JMS

JMS is a collection of interfaces and related semantics that, through these interfaces and the methods in which they are used, jmsclient how to access the message system, completing the creation, sending, receiving, and reading of messages in the enterprise message system.
Prior to JMS, each MOM vendor used a proprietary API 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 be executed 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 these messages.

The target of JMS

JMS has been committed since its inception, for example, following several goals:
Defines a set of message common concepts and useful tools.
All Java applications are able to use the APIs defined in JMS to complete the creation, reception, and delivery of messages, regardless of what mom, which implements the JMS standard, can be used as a mediator of the message and the storage and forwarding of the message is complete.
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, each application only cares about how to receive and send messages to and from 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:

O-To-point (peer) model

Ø Announcement/Subscription (PUB/SUB) model

Figure 2 JMS Communication model

It can be seen that 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, where the client sends a message to the queue destination, where only one recipient of the message receives the message, and other visitors to the same destination do 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 such a broadcast model, a client sends a message to the subject destination (Topic), regardless of the number of consumer subscribers who are able to 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, for example, as seen:

Figure 3 Point-to-dot communication model

Features of the point-to-point model:

Ø each message has a consumer

For every single consumer, if a message is received by the recipient, other consumers will not be able to get the message.

Ø sending and receiving messages is not related to time

In other words, after the producer sends the message, the consumer can receive at random moment, but has two premise:

1. Message Not expired

2, the message is not received by other users

Consumers can also execute first, when the producer executes, sends the message to the queue, the consumer may obtain the message from the queue, this is called "to wait".

Ø the consumer must acknowledge receipt of the message

When a message is received, the consumer must confirm that the message has been received, or the JMS service provider will feel that the message has not been received, and the message can still be received by others. The procedure can be confirmed by itself, without the need for manual intervention.

Ø non-persistent messages are sent at most only once

A non-persistent message is sent at most once, indicating that the message might not have been sent, and that the reason for not being sent might be:

1, the JMS service provider is down, etc., resulting in the loss of non-persistent information

2. Messages in the queue expire and are not received

Ø persistent messages are sent strictly once

We are able to set the more important message to a persisted message, and the persisted message will not be lost due to a failure of the JMS service provider or other cause.

Publish/Subscribe Model

Announcement/subscription Model: The advertisement/subscription delivery message type is related to the subject (TOPIC). The producer publishes the message, and the consumer subscribes to the message of interest, and 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. Such types are similar in the form of published newspapers, magazines, for example with what is seen:

Figure 4 Announcement/subscription communication model

Announcement / features of the subscription model:

Ø each message can have more than one (0,1, ...). ) Subscribers

Each message can have more than one consumer, assuming that newspapers and magazines, who subscribe to who can be obtained.

Subscribers can only consume the information they have published after their subscription

This requires subscribers to subscribe first, and the producers to publish them again. That is, the Subscriber must execute first, and then wait for the producer to execute, which differs from the point-to-point type.

Ø subscribers must remain active to use these messages

That is, subscribers must remain active waiting for a message published by the publisher, assuming that the subscriber does not execute after the announcement is made by the publisher, and that the previously published message cannot be obtained.

Simple introduction of JMS (a)--JMS