Use of JMS in jboss4

In today's projects, there are more and more distributed programs. In the SOA architecture, various services are transmitted through messages for mutual calls. Therefore, JMS, as a Java Message mechanism, should be well grasped, of course, Web services do not directly call JMS APIs.

This article focuses on the specific use of JMS in jboss4. The implementation of JMS in JBoss is called jbossmq. Many articles on its theoretical aspects have mentioned it. Google will have it, so we won't repeat it here. As for WebLogic, the use of Websphere is similar.

The use of JMS is divided into two types according to its destination: queue, point-to-point mode, topic, and publish/subscribe mode, there is a big difference between the two in terms of use.

First, let's take a look at the queue as destination mode, which is a point-to-point mode. That is to say, after the sender sends a message to the JMS server, the message is saved in a queue, after the receiver obtains the message from the JMS server, the message in the queue is gone, and other users cannot get the message. That is to say, the message has only one user, which is the most essential difference from the topic. The specific code is as follows: first through jnid to find a queueconnectionfactory (JBoss provides several connectionfactory) and a queue, the definition of a specific queue in the JBoss jbossmq-destinations-service.xml configuration file. Speaking of this, I would like to briefly introduce some configuration files of jbosson JMS. They are under deploy/JMS. Generally, we may need to use the following configuration files for General Usage:

Jbossmq-destinations-service: Set destination

Hsqldb-jdbc-state-service.xml: Connection JMS user name and password settings, it will create a table of user names and their corresponding password to a memory database at JBoss startup, if we use the topic's durable connection, we need to set the user name and password in the middle.

Hsqldb-jdbc2-service.xml: persists the message to the database configuration file, which contains SQL statements, you can find some specific database configuration file samples under docs/examples/JMS. Our default message is also persistent and should be saved in a file, but I haven't found this place yet.

The above three files may be modified during use, and some files are also important.

Jbossmq-service.xml: some default configurations for jbossmq

Jms-ds.xml, etc.

Let's talk about queue programming. After obtaining the queue and queueconnectionfactory, we get a queueconncetion, and then get the queuesession through queueconnection. Through queuesession and queue, we can get the queuesender or queuereceiver about this queue, there is nothing to say about generating and sending messages. There are two types of message consumption: one is synchronization, that is, pull messages from the queue of JMS through the receive () method of queuereceiver, only one message can be obtained at a time. The other is asynchronous, that is, a messagelistener is set to the JMS server through queuereceiver. If a message arrives, the message is pushed to queuereceiver and the onmessage () method in messagelistener is, in this way, the connection can be continuously maintained and the user can get multiple messages. Queue is used to send messages. There is no durable statement, because it is durable for message consumers in essence. When messagesend is sent to queue, the server will persist the message, even if we shut down the server, it is okay. After we start the server, if a consumer connects to the queue, we can get the message. We don't need to mention registering this user, in addition, the consumer does not have to be motivated when sending messages. The PULL mode is definitely not activated, and the push mode is not forced. This is somewhat different from the topic.

Next, let's take a look at the topic mode. It is a subscription/publish mode. One of its messages can be consumed by multiple users, but remember one thing, that is, you can only consume the messages published by the topic after subscription. That is to say, you cannot obtain the messages published before the topic. This requires that you register the messages (equivalent to subscription) before use ), this is useless for non-durable consumption. Because non-durable consumption can only get messages when your consumer is active, that is, the consumer program is running, in this way, the initial part of the program is equivalent to registration. For durable consumption, the durable connection means that when the consumer's program is not running, A message published by a topic can also be received after it is activated. Therefore, you must register a message first. For a durable connection, you must have a user name. You can establish a connection to the topic first, set the specified user name. The next durable connection is the same user name, and the previous message is sent to meet our requirements, of course, this is the first time we run the durable connection. The customer program needs to receive the previous message before registering. If it does not exist before, it does not need to be registered. At the first running, it is equivalent to registering. This type of registration takes only one time and will not be used in the future. It is estimated that the registration information is also persistent. In the same way, the topic can return or pull messages. The topic mode needs to be subscribed in advance. Because the message of a topic has multiple consumption items, You do not register the message first, so the JMS server does not know who to send the message, however, no matter how many users there are, queue only guarantees that the message is sent to one user, so the two are different in this place.

This is the first article. Now we can use a program to write a program that ensures that the message can be consumed by the user we want. No matter what exceptions occur in the process, this ensures the reliability of message sending. In the next article, I will explain some content about message persistence and some transaction aspects in JMS.