The use of JMS in JBOSS4

There are more and more distributed programs in the current project, under the architecture of SOA, various services call each other as messages, so JMS as a Java message mechanism should be well mastered, of course, like Web Services is not a direct call to JMS API.

This article is mainly about the specific use of JMS in the JBOSS4, JBoss in the implementation of JMS called JBOSSMQ, about its theoretical aspects of a lot of articles are said, Google will have, so here will not repeat. As for the use of weblogic,websphere in the same way.

The use of JMS in accordance with its destination divided into two, one is the queue, that is, point-to-point mode, a topic, that is, publish/subscribe mode, the two in some use or have a relatively large difference.

First, let's look at the destination mode of queue, which is a point-to-point mode, that is, when the sender sends a message to the JMS server, it is saved in a queue, and the receiver obtains it from the JMS server. The message in the queue is gone, and there is no other user to take it. That is, the message has only one user, which is different from the topic most essential place. The specific code is as follows: first through the Jnid to find a queueconnectionfactory (JBoss provided several kinds of connectionfactory) and a queue, The definition of a specific queue is in the Jbossmq-destinations-service.xml configuration file in JBoss. Speaking of which, this is a brief introduction to some of JBOSS4 's configuration files about JMS, which, under DEPLOY/JMS, are commonly used in our regular use.

Jbossmq-destinations-service: Setting destination

Hsqldb-jdbc-state-service.xml: Connect the JMS username and password setting, which creates a table of user names and their corresponding passwords to a memory database at JBoss startup, and if we use a topic durable connection, set the username and password in the middle of it.

Hsqldb-jdbc2-service.xml: The message is persisted to the database configuration file, which contains the SQL statements, and you can find a sample of the specific database configuration files under DOCS/EXAMPLES/JMS. Our default message is also persisted, should be kept in a file, but I have not found this place.

The top three may be the changes we want to use, and some of the more important matching documents

Jbossmq-service.xml: Some of the default configurations about JBOSSMQ

Jms-ds.xml; wait.

Say stadia turn we still talk about the programming of the queue. When we get to queue and queueconnectionfactory, we get a queueconncetion and then we get queuesession through Queueconnection, Through queuesession and queue can get about this queue of queuesender or queuereceiver, corresponding to generate messages and send nothing to say, for the message consumption there are two kinds, one is synchronization, That is, the QueueReceiver receive () method pulls messages from the JMS queue, only one message at a time, and the other asynchronous, that is, by QueueReceiver set a messagelistener to the JMS server, When a message is available, it is pushed to the queuereceiver to call back the OnMessage () method in MessageListener, so that the connection can be maintained continuously and the user can get multiple messages. Using queue to send messages, there is no durable, because it is essentially durable to the consumer of the message, and when we messagesend into the queue, the server is persisted We're fine even if we shut down the server. When we start the server, if there is a consumer connected to the queue can get the message, we do not have to mention the registration of the user, and the message when the consumer does not have to be fired, for the pull method is certainly not activated, for the push method is not forced, This is a little different from topic.

Let's take a look at the topic model, which is a subscription/release model, a message that can be consumed by multiple users, but one thing to remember is that you can only consume the messages you subscribe to after the topic, that is, the topic posted before you get the message, This requires you to register in use (equivalent to subscription), which is not durable consumption, because the consumption of durable, only in your consumer is activated to get the message, that is, the consumer program is running, so that the beginning part of the program is equivalent to register While for durable consumption, there are some different, durable connection refers to when the consumer's program is not running, topic release of the message in its activation can also receive, which requires to register some, durable connection to have a user name, We can first establish and the topic connection, set the specified username, the next durable connection to the past is the same user name, then the previous message also sent over to meet our requirements, Of course this is the first time we run the durable connected client program is to receive the previous message to register, if there is no prior to registration, I am the first run is equivalent to registration. This registration is only once and will not be used in the future, it is estimated that the registration information is also persisted. The same topic also has two ways to get the message back and pull. Why topic mode needs to subscribe in advance, because a topic message has more than one consumption, so you do not register first, then the JMS server does not know who to send the messages, and queue no matter how many users, it is only guaranteed to send the word to a user on the line, So the two are still a little different in this place.

The first article on this, we have now been able to write a program to ensure that the message can be requested by a user of the program to consume, regardless of what happens in the middle of the process, which guarantees the reliability of the message sent. In the next installment, I'll explain some of the content of message persistence and some of the transactions in JMS in the future.