Research and Implementation of JMS-based Data Collection System

Nowadays, more and more enterprises and units are facing a variety of data integration and system integration. RPC middleware technologies such as CORBA, DCOM, and RMI have also emerged. However, due to the use of RPC synchronous processing technology, there are many shortcomings in performance, robustness, and scalability. The message-based Asynchronous processing model adopts the non-blocking calling feature. The sender sends the message to the Message Server and the Message Server forwards the message to the receiver when appropriate; sending and receiving are asynchronous, and the sender does not have to wait. The lifecycles of the two can also be different. In addition, the sender can indirectly send messages to multiple receivers, greatly improvingProgramThe performance, scalability, and robustness of the asynchronous processing model make the asynchronous processing model more attractive in distributed applications than the synchronous processing model.

This article introduces in detail the asynchronous Processing Mechanism in Java-the Asynchronous Message Processing Technology Based on JMS, and discusses the design and implementation of the JMS-based meteorological system data collection system based on examples.

Java Message Service-JMS

JMS is a message-oriented middleware (MOM) API jointly designed by several companies including Sun Microsystems and IBM. JMS defines the interface for accessing message-oriented middleware in Java, but JMS is only an interface and is not implemented. The message-oriented middleware that implements the JMS interface is called the JMS provider ). The purpose of JMS is that an application can transmit and receive messages reliably in asynchronous mode. From a programming perspective, JMS can be used as a container-managed resource, similar to JDBC connection. Just as you can access many different relational databases through JDBC, you can access a message service system independent of the vendor through JMS.

JMS consists of the JMS provider, message producer, and message consumer ). Simply put, the JMS provider refers to the message system that implements the jms api and the message transfer station. The message sender refers to the creation and sender of the message, and is the source of the message; A message recipient is an application that receives a message and is the final destination of the message.

JMS messages are processed asynchronously. A message sender can send a message without waiting for a response. The message sender sends a message to a virtual channel (topic or Queue), and the message receiver subscribes to or listens to the channel. A message may eventually be forwarded to one or more message recipients without responding to the message sender.

1. Composition of JMS messages

After j2ee1.4, the jms api does not distinguish messages created in the point-to-point domain from those created in the publish/subscribe domain. A jms Message consists of three parts (1.1 ):

Header-the JMS header contains many fields, which are generated by the JMS provider or message sender after a message is sent to indicate the message, set priority and expiration time, determine the route for the message.

Property-this property is generated by the message sender and used to add and delete additional information other than the message header.

Body: is generated by the message sender. Five message bodies are defined in JMS: bytemessage, mapmessage, objectmessage, streammessage, and textmessage.

2. JMS message transmission mode

JMS supports two message transmission modes: peer-to-peer (P2P) and publish/subscribe ). Both of them are well-known push modes. The message sender is the initiator of the activity, while the receiver is the passive receiver of the message. In JMS, these message transmission modes are called message domains ).

2.1 JMS point-to-point message domain

In point-to-point mode, the sender and receiver reach an agreement on the destination address for message transmission, that is, the so-called queue ). The message queue is located in the JMS provider. The message sender sends messages to a message queue. The message receiver can receive messages from the queue (passively) at any time after the message is sent, the message remains in the message queue until it expires. The structure 1.2 of the point-to-point mode is shown in:

The JMS point-to-point message domain has the following features:

· Each message can and can only be received by one receiver.

· Each message or message is removed from the queue by the receiver or deleted by the JMS provider upon timeout.

· The receiver does not have to exist when a message is generated. The receiver can remove the message at any time after the message is generated.

· The recipient cannot request a message.

· The recipient must send a confirmation message after receiving the message.

2.2 publish/subscribe a message domain using JMS

In publish/subscribe mode, a sender is called a publisher. A message can have many recipients, who are called subscriber ). The Publish/subscribe modes are different from the point-to-point mode. In the publishing/subscription mode, a publisher sends messages to a topic. Multiple subscribers can subscribe to topics they are interested in when subscribing. One topic can be subscribed by multiple subscribers, and one subscriber can also subscribe to multiple topics. Messages of a topic are sent only to all subscribers of the topic. A subscriber can only receive messages from the topic it subscribes to. By default, a subscriber must be active when a message is sent and is ready to receive messages at any time, otherwise, it will miss the message. To avoid this time dependency, the jms api allows the subscriber to create a persistent subscription. The structure 1.3 of the publishing/subscription mode is shown in:

The JMS publishing/subscribing message domain has the following features:

· Each message is created by a publisher and received by 0 or more subscribers.

· Messages are immediately distributed to existing subscribers.

· The subscriber must exist when the message is sent to receive the message.

· Persistent subscription allows the subscriber to receive messages sent to the topic by the publisher when the subscriber is inactive.

· The subscriber must send a confirmation message after receiving the message.