JBoss and JMS

1. Introduction
This chapter describes the use of Java messageing Service (JMS) in JBoss. Not a JMS guide, but how JBoss and JMS work together, and if you want to see a JMS introduction, refer to the JMS specification or JMS turorial.
Recent updates to the JBoss version have led to a growing sophistication of JMS support, as well as the differences between the various versions of JBoss. Here I mainly introduce the jboss3.0.x version.
The examples given in this chapter are simple and point out the principle of how to use JMS. All of the examples can be built using ant build file.
In order to be able to build and run this example. We do this in two ways: using the ant command and the second using the JAR and Java basic commands. The following environment variables must be available:
W Java_home installs the JDK1.4 directory.
W jboss_dist installs the JBOSS directory.
You must install the JDK and ant must be installed if you use Ant. You can refer to my previous document for an introduction.
2. Overview
1 What is JMS
JMS is a Java API that allows applications to create, receive, and read messages. Programs rely on these APIs and need a JMS implementation interface at run time to provide management and control, known as the JMS provider, which now has several different JMS provider; In JBoss is called JBOSSMQ.
2 JMS and Java EE
JMS was developed prior to the EJB and Java EE Framework development, so no EJB or Java EE is involved in the JMS specification.
Neither JMS is involved in the first generation of EJB and Java EE, until EJB1.1, and JMS is not a necessary API to generate a container provider that can be beand. The JMS interface is required in j2ee1.2, but it does not have to include a JMS Provider, which is changed in EJB2.0 and j2ee1.3, and the application server contains a JMS Provider since j2ee1. 3 requires EJB2.0, adding the following two JMS features:
W A new bean type definition, the message-driven beam (MDB), is a JMS message listener that can process JMS messages asynchronously.
W JMS processing as a resource, the JMD publication (send) from one bean must be shared with the global transactional environment of other beans. This requires that JMS be considered a container-managed resource, like a JDBC connection.
3 JMS and JBoss
JBoss supports JMS since version 2.0. An MDB was added in 2.1, starting with JMS as a transaction resource from version 2.4.
The architecture of JMS in JBoss is as follows:
W JMS Provider, called JBOSSMQ. is part of JBoss's implementation of the JMS 1.0.2 specification, including optional parts, like ASF (Application Service facvility). JBOSSMQ processing is the same as Universal JMS: establishing Queues (Queues) or topic (title), persistence, etc.
W MDB (Message driven Beans),
W Resource Adapter.

3. JMS Provider
JBoss has its own JMS Provider called JBOSSMQ. It is suitable for JMS Provider with JMS 1.0.2 and can be used in all common JMS programs. To understand how JMS works in JBoss, the first thing to understand is the concepts and terminology involved in JMS, the best way is to read the JMS specification, and here's a simple JMS introduction.
1) A brief introduction to JMS
When you send a message, you cannot send directly to the recipient who is interested in this message. Instead you send it to a destination. Recipients who are interested in this message must connect to the destination, get this message, or set up a subscription at the destination.
There are two types of domains in JMS: Topics and queues.
W a message sent to a topics can have multiple clients. Use the topic release to allow One-to-many, or many-to-many, communication channels. The message's creator is called publisher, and the message recipient is called Subscriber.
W queue is another way to allow only one message to be sent to a customer. A sender places a message in a message queue, the recipient extracts from the queue and gets the message, and the message disappears in the queue. After the first recipient extracts and gets the message, the other person cannot get it.
In order to be able to send and receive messages, a JMS connection must be obtained. The connection is connected using JMS provider, and a session is established after the connection is received. Then create Publisher/sender to send messages or subscriber/receiver to receive messages.
At run time, if you use topic then Publisher or Subscriber is associated through a topic, and if you use queue, sender or receiver are associated with the queue.
Typically, the methods used in the JMS framework are as follows:
(1) To obtain a Jndi initialization context (contexts);
(2) According to the context to find a connection factory topicconnectfactory/queueconnectionfactory (there are two connection factories, according to the topic/queue to use the corresponding type);
(3) Get a connection from the connection factory (Connect has two kinds [topicconnection/queueconnection]);
(4) A session is established by means of a connection;
(5) Find the destination (topic/queue);
(6) Establish the message maker (Topicpublisher/queuesender) and consumer (topicsubscriber/queuereceiver) according to the conversation and destination.
In order to get a connection and get a destination (used to correlate Publisher/sender or subscriber/receiver), you must use the Provider-specific parameter.
Jndi is used to find the appropriate connection factory or destination, and Jndi is suitable for any JMS Provider. But the name used for the lookup is provider. Therefore, in your use of the JMS Provider (which includes jbossmq), you must learn how to specify. Any settings in the JMS provider, such as connection characteristics, destination, etc., are clearly described in the provider used.
2) configuration
When using a JMS provider, there are three provider-specific factors:
W Gets a Jndi initialization context
The name of the connection factory used by W.
W management and naming agreements for destinations.
JBoss executes with its jndi. For a simple JMS client, configure and find initialization contexts just like other Java EE clients.
Jms-specific to constrain JBoss's JMS provider (JBOSSMQ). The JBOSSMQ is configured through an XML file Jbossmq-service.xml, which is placed under Server\default\deploy.
The most basic three things in an XML file:
W Add a new destination
W Configure users
W Gets the name of the available connection factory.
(1) To add new destinations
W in the destination XML file in JBoss 3.x is Jbossmq-destinations-service.xml (server/. /deploy). There are already a few default destinations in the file, so it's easier to see how you can add to the file. In the example you need a topic destination spool, so add the following statement to the Jbossmq-destinations-service.xml. This approach is permanent and does not disappear as the JBoss server shuts down.
<mbean code= "Org.jboss.mq.server.jmx.Topic"
Name= "Jboss.mq.destination:service=topic,name=spool" >
<depends optional-attribute-name= "Destinationmanager" >jboss.mq:service=DestinationManager</depends>
</mbean>
Another way to do this is through the JMX HTML admin interface. Accessed through Http://localhost:8080/jmx-console. Look for Service=destinationmanager connections under JBOSS.MQ. Then set up in Createtopic () or Createqueue (), the destination for this method is temporary, and as the server begins to exist, the dynamically established destination will not exist when the JBoss server is restarted. All destinations in jbossmq have a prefix of the destination type. For the topic prefix is topic, for the queues prefix is a queue. For example, to find a testtopic destination, you need to find the name "Topic/testtopic".
There are two methods of createtopic () or Createqueue () in this method: one has two parameters, and the other has one parameter. The two parameters are: the established destination name and Jndi name. A parameter is just the destination name, and for the Jndi name the default is: [Destination type (topic/queue)]/destination name.
Here we are using the first method. Directly modify the Jbossmq-destinations-service.xml file.
(2) Manage users
In JMS, a connection and a user may be associated, unfortunately there is no clear way to restrict access to JBOSSMQ or access a particular destination to a given user. In order to give most of the roles, there is no need to create a user in jbossmq unless you want to have a persistent topic subscriber. In this case, the user is required.
Users can directly jbossmq-state.xml the file (server/. /conf) added. You can also use the JMX HTML admin interface to add (Jboss.mq->service=statemanager->adduser ()).
<User>
<Name>jacky</Name>
<Password>jacky</Password>
<Id>DurableSubscriberExample</Id>
</User>>

(3) Connecting factory
The JBOSSMQ includes several different connection factories for topic and queue, each of which has its own characteristics. When you look up a connection factory through Jndi, you need to know the name of this connection factory. All of the available connection factories and their properties will be in the file jbossmq-service.xml.
There are three types of connection factories, depending on the communication protocol as follows:
Oil
Fast two-way scoket communication protocol. It is the default.
UIL
More than one socket protocol can be used when accessing through a firewall, or when the client does not properly find the IP address of the server.
Rmi
The earliest agreement was stable, but slow.
Jvm
A new connection factory type added after JBoss 2.4. You do not need to use sockets, when the client and JBOSSMQ use the same virtual machine, you can use.
In later versions of JBoss2.4.1, the connection factory uses the same name for topic-and queue-destinations. The following table lists the JMS connection factories in JBoss:
Destination type Jndi name Connection factory type
Topic/queue java:/connectionfactory JVM
Topic/queue java:/xaconnectionfactory JVM supports XA transactions
Topic/queue rmiconnectionfactory RMI
Topic/queue rmixaconnectionfactory RMI supports XA transactions
Topic/queue ConnectionFactory Oil
Topic/queue xaconnectionfactory Oil supports XA transactions
Topic/queue uilconnectionfactory UIL
Topic/queue uilxaconnectionfactory UIL supports XA transactions

3 The senior JMS configuration of JBoss
The above paragraph mainly describes the basic configuration work that is carried out with JBOSSMQ. Describe other JMS configurations in this section.
(1) JMS persistence management
JMS Persistence Management (PM) is responsible for storing messages and marking them as persistent, and if the server fails, it guarantees that the message will not be lost and that persistent messages are restored. Persistent JMS messages can be accomplished using different methods. Each method has its own advantages and disadvantages:
PM Name Advantages and disadvantages
File is relatively stable and slow
Rollinglogged faster This method is relatively new, some areas need to be improved
JDBC is better for stability and scalability must have JDBC
Logged fast Log files grow without bound memory management problems during
The default persistence message management in JBoss is file persistence management. Can change it, but must be for a JMS
Server has and has only one persistence management configuration. So your jboss.mq–> in the JBoss admin interface
Service=persistencemanager just see one.
The persistence-managed configuration file is jbossmq-service.xml. In Server\. \deploy under.
To help you understand the various ways of persistence management, I'll show you how to configure them one by one.
W File Persistence Management
The concept of file persistence management is to create a file for each persistent message. The message persistence method is not all available, but it is relatively stable.
File Persistence Management is a default persistence management when JBoss is released. If you open the Jbossmq-service.xml file, you will see the following XML:
<mbean code= "Org.jboss.mq.pm.file.PersistenceManager"
Name= "Jboss.mq:service=persistencemanager" >
<attribute >db/jbossmq/file</attribute>
<depends optional-attribute-name= "Messagecache" >jboss.mq:service=MessageCache</depends>
</mbean>
When you set up an Mbean configuration, file Persistence management allows you to specify the following attributes:
Datadircetory is the path that holds persistent messages, and the resulting data files are placed in this directory.

W Set rollinglogged persistence management
Rollinglogged Persistence Management is a relatively new persistent message management method because it uses log files to persist multiple messages, so there is no need for a lot of I/O when creating a file.
Define Rollinglogged Persistence Management:
<mbean code= "Org.jboss.mq.pm.rollinglogged.PersistenceManager"
Name= "Jboss.mq:service=persistencemanager" >
<attribute >db/jbossmq/file</attribute>
<depends optional-attribute-name= "Messagecache" >jboss.mq:service=MessageCache</depends>
</mbean>
In rollinglogged persistence Management, Datadirctory stores the path of persistent messages, placing the resulting data files in this directory.

W Set JDBC Persistence management
JDBC Persistence management uses database tables to store messages. An JBoss-configured data source is required to access the database. Refer to the contents of the Jbossmq-service.xml file for specific content.
W Set logged persistence management
Logged persistence Management is an early one, and is not recommended for use in JBoss2.4.1 later versions. There are other better ways to do it now.
4, the example explains
When we understand the content later, let's use JBoss to implement an example to deepen our understanding of JBoss and JMS.
In the above description, we know that there are three basic things you can do to explicitly use the JMS provider: Configure the Jndi initialization context, connect the factory name and use the name of the destination.
The best thing to do when writing a product is not to be affected by provider-specific, so that the code can be easily ported between different JMS provider. This example does not focus on developing products, but explains how to work with JBOSSMQ.
1 Initialization context
One way to configure Jndi with a W is through the property file Jndi.properties. Use the correct value in this file and include the path it contains in the classpath, which compares the tolerance to the correct initialization context.
The contents of the Jndi.properties file are as follows:
Java.naming.factory.initial=org.jnp.interfaces.namingcontextfactory
java.naming.provider.url=localhost:1099
Java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
Place the path of the file as part of your classpath. If you use this method, the code is simpler when you initialize the context: contextual contexts = new Intialcontext (); 1
W In some scenarios, you may need to manually configure Jndi, for example, when the environment in the running class file has been configured with an initialization context, but not the context you want to use, you need to manually configure a context. Sets several property values in the hash table, and uses this hashtable to instantiate a context. Define syntax:
Hashtable props = new Hashtable ();
Props.put (Context.initial_context_factory,
"Org.jnp.interfaces.NamingContextFactory");
Props.put (Context.provider_url, "localhost:1099");
Props.put ("Java.naming.rmi.security.manager", "yes");
Props.put (context.url_pkg_prefixes, "org.jboss.naming");

2) Find Connection Factory
After you have the context, you need to find a connection factory. To find it, use a name that is available. The code to find the connection factory is as follows:
For a topic destination
Topicconnectionfactory topicfactory = (topicconnectionfactory) context.lookup ("ConnectionFactory")
Queue