Turn: The brief introduction of JMS (a)--JMS

Reprint Address: http://blog.csdn.net/aking21alinjuju/article/details/6051421 Aking21alinjuju

Directory:

1. Enterprise Messaging System
1. Benefits of the Enterprise messaging system
2. Provides message flexibility
3. Loosely coupled
2. What is JMS
1. The target of JMS
3. JMS Two message models
1. Dot-to-point model
2. Publish subscription model

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.

Learning Goals:

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

Ø difference between point-to-point model and publish/subscribe model and use occasions

Ø familiarity with the core and common JMS APIs

Ø familiarity with and understanding of JMS client Development steps

Ø the implementation of message synchronization and asynchronous reception

Ø the solution to the problem of string package

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

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 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:

O-To-point (peer) model

Ø Publish/Subscribe (PUB/SUB) model

Figure 2 JMS Communication model

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:

Figure 3 Point-to-dot communication model

Features of the point-to-point model:

Ø each message has a consumer

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

Ø sending and receiving messages is not related to time

In other words, when a producer sends a message, the consumer can receive it at any time, but there are two prerequisites:

1. Message Not expired

2, the message is not received by other users

Consumers can also run first, and when a producer runs and sends messages to the queue, consumers can get messages from the queue, which is called "Waiting."

Ø 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 assume that the message is not received, and the message can still be received by someone else. The program can be automatically confirmed without the need for manual intervention.

Ø non-persistent messages are sent at most 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 can set the more important message as 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

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:

Figure 4 Publish/Subscribe communication model

Publish / features of the subscription model:

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

Each message can have more than one consumer, if the newspaper and magazine, who subscribe to who can get.

Ø subscribers can only consume messages they have published after their subscription

This requires subscribers to subscribe, and the producers to redistribute them. That is, subscribers must run first and wait for the producer to run, which differs from point-to-point types.

Ø subscribers must remain active to use these messages

That is, the Subscriber must remain active waiting for a message published by the publisher, and if the Subscriber does not run after the publisher publishes the message, the message cannot be obtained from the previous publisher.

Turn: The brief introduction of JMS (a)--JMS