JMS Messaging Server (i)--basic knowledge

1. Overview

Heterogeneous integration (heterogeneous integration) is an area in which messaging mechanisms play a key role. Whether it's a merger, a merger, a business need, or just a change in the technology direction, more and more companies are facing the problem of integrating disparate systems and applications across the enterprise.

The messaging mechanism also has the ability to process requests asynchronously , providing solutions for system architects and developers to mitigate or eliminate system bottlenecks and improve end-user productivity and overall system scalability. Systems that use this mechanism also have a high degree of architectural flexibility and agility because messaging mechanisms enable high levels of decoupling between components.

By using message-oriented middleware , messages are routed through the network from one application to another. Enterprise Middleware products Ensure that messages are distributed correctly in the middle of the application. In addition, these products often provide fault tolerance and load balancing, scalability, and transactional support for businesses that need to reliably exchange messages in large quantities.

2. Message Delivery model

MS supports two types of messaging models: The Point-to-point model and the Publish/Subscribe model . These messaging models are known to be messaging domains. The point-to-point messaging model and the publish/subscribe Messaging model are often abbreviated to peer and pub/sub, respectively.

The Publish/subscribe model is designed for one-to-many (one-to-many) message broadcasts, while the point-to-point model is designed for one-to-one (one-to-one) messaging. Such as

2.1, point-to-point model

The point-to-point messaging model allows JMS clients to synchronously and asynchronously send and receive messages through this virtual channel of queues. In a point-to-point model, the message producer is called the Sender (sender), and the message consumer is called the receiver. A prominent feature of the point-to-point messaging model is that messages sent to the queue are accepted by one and only one recipient, even if it is possible for multiple recipients to listen for Unified Messaging in the same queue .

The point-to-point messaging model supports asynchronous " send-and-discard (fire and forget)" messaging, and also supports synchronous request/reply message delivery methods. The point-to-point messaging model is more coupled than publish/subscribe, and the sender usually knows how the message will be used and who will accept the message .

The point-to-point model supports load balancing , which allows multiple recipients to listen on the same queue and allocate the load. As shown in 1-4, the JMS provider is responsible for managing the queue, ensuring that each message is consumed by the next available recipient in the group, and only once .

2.2. Publish/Subscribe Model

In the Publish/subscribe model, messages are published to a virtual channel called a topic. The message producer is called the publisher (publisher), and the message consumer is called the Subscriber (subscriber). Unlike point-to-point models, messages published to a topic using the Publish/Subscribe model can be accepted by multiple subscribers. Sometimes, this technology is also called the Broadcast (broadcasting) message . each Subscriber will receive a copy of each message . In general, the Publish/subscribe messaging model is basically a (push)-based model in which messages are automatically broadcast by the message, and they do not need to request or poll the subject to obtain new messages.

The decoupling capability of the publish/subscribe model is stronger than the peer model, and the message Publisher usually does not realize how many subscribers or those subscribers are handling the messages.

Within the Publish/subscribe messaging model, there are many different types of subscribers. Non-persistent subscribers are temporary subscription types that accept messages only when they actively listen on the subject. On the other hand, persistent subscribers will accept a copy of each message that is published, even when they are in the "offline" state when they publish the message.

3. JMS API

JMS itself is not a messaging system; It is an abstraction of the required interfaces and classes for messaging clients and messaging system communication . Like the JDBC Abstract Access database, Jndi abstract access to the naming and directory services, the JMS abstraction can access the message provider . With JMS, messaging clients for applications can migrate across messaging server products.

The JMS API can be divided into 3 main parts: The public API, the peer-to-peer API , and the Publish/Subscribe API. In JMS1.1, a public API can be used to post messages to or receive messages from a queue or a topic. The point-to-point API is dedicated to message delivery using queues, while the Publish/Subscribe API is dedicated to messaging using topics.

Within the JMS feature API, there are 7 main JMS API interfaces for publishing and accepting JMS messages:

• ConnectionFactory
• Destination
• Connection
• Session
• Message
• MessageProducer
• Messageconsumer

In these common interfaces, connectionfactory and destination must be obtained from the provider using Jndi. Other interfaces can be created in different API interfaces through factory methods. The relationships between the 7 main JMS public API interfaces are as follows:

3.1, point-to-point API

The point-to-point Messaging model API refers specifically to the queue -based interface within the JMS API. The following is an interface for sending and receiving messages from a queue to a queue:

*queueconnectionfactory
* Queue
* queueconnection
* queuesession
* Message
* Queuesender
* QueueReceiver

As in the JMS public API, Queueconnectionfactory and queue objects must be obtained from the JMS provider through Jndi. Most interface names simply add the word queue before the public API interface name. Shows the processes and relationships between the queue-based JMS API interfaces.

3.2. Publish/Subscribe API

The interface used internally by the Publish/Subscribe messaging model is as follows:

*topicconnectionfactory
* Topic
* topicconnection
* topicsession
* Message
* Topicpublisher
* TopicSubscriber

is the relationship and process of the topic-based JMS API interface:

4. Enterprise Message Delivery Model

One of the basic ideas of messaging mechanism is to stipulate that peers between applications should be asynchronous . The code that connects the parts to each other assumes that this is a one-way message, and that it does not need to get a response from another application immediately. Once a message is emitted, the messaging client is able to turn to other tasks, and he does not have to wait for a response to the message. This is the main difference between RPC and asynchronous messaging, and it is critical to understanding the benefits of messaging systems.

In an asynchronous messaging system, there is no coupling between each subsystem and other systems. is a typical architecture:

JMS Messaging Server (i)--basic knowledge