Create a JMS messaging service under WebLogic

http://hello-kitty-o.iteye.com/blog/805594

With the JMS messaging service, the steps and considerations for configuring the WebLogic JMS Messaging service are summarized after looking at some configuration on the web.

The WebLogic version is 9.2, and there are about three steps to creating a JMS messaging service, the first is to create a JMS messaging server, the second is to create a JMS module, and the third is to create connection factories and themes. The following specific steps:

1. Create a JMS Messaging server

The JMS Servers under the messaging under the Services tree. Lock the changes and click the New button.

The name of the JMS server is jmsservertest, the message media is stored as NULL, click Next.

The target server is set to Examplesserver. The item must be set.

Click Active changes to save the new JMS message server.

A new JMS module name is called Systemmoduletest.

Select Servers as Examplesserver.

Save the changes, you can see the new systemmoduletest.

The next step is to start creating connection factories and topic. Click the new module you just created. Click New.

Enter the Jndi name for the topic.

Create a child deployment item.

The name of the child deployment item is topictest.

Select the JMS server for the newly created jmsservertest. Click to complete the modification. The next step is to create a new connection factory.

Enter the Jndi name of the connection factory.

Select the target bit exampleserver.

If the application starts, the javax.naming.NameNotFoundException exception can view the Jndi tree information from the WebLogic console.

The steps to view are: wl_server----"Environment----" Servers

Click on exampleserver (Admin) in the postcode list and click the View JNDI tree link on the open page.
The image below is all the Jdni information. In addition, the WebLogic configuration information is saved by the path

Weblogic92\samples\domains\workshop\config

The configuration path for JMS is WEBLOGIC92\SAMPLES\DOMAINS\WORKSHOP\CONFIG\JMS

Sometimes, creating a JMS message prompts you that the Jndi name already exists, but is not visible on the console and can be viewed from these XML.

=========using the Java messaging service in Bea WebLogic
In the last two years, Sun has introduced many APIs for enterprise application development. The most exciting of these is the Java Messaging Service or JMS. The JMS API is designed for messaging in the enterprise, where the task of Jndi is to name and provide directory services for directory services, and JNBC's task is to provide database access. JMS is an API designed to provide a common tool for enterprise messaging that does not consider sending messages to the underlying implementation of any one application server, nor does it take into account other enterprise messaging software technologies that you want to use. This is a great step forward for developers who create or use message-oriented middleware (MOM), especially those Java developers who need to use these tools in their own products. With JMS, you should be able to write a set of code for messaging to the JMS API, and then use that code in any messaging system that provides JMS support.
In this article, I'll show you how to create a series of messaging producers and consumers who take advantage of most of the JMS API's functions to use persistent stored themes and queues, create temporary destinations, filter messages through message selectors, and so on. I will implement these examples in the implementation of the first vendor in JMS, which is provided with Bea's WebLogic application server (for more information about the server and configuring JMS, available from www.) Javadevelopersjournal.com's "install.txt" online file). In this process, I will take you through the steps necessary to implement these applications, including modifying the application server to support the sample code that you will create.
Before you continue to create the following sample code, it is recommended that you obtain and install the latest version of the Bea/weblogic application server first. Free use of the trial version can be downloaded from the BEA website http://ecommerce.bea.com/index.jsp.

Code
A total of 4 source files, including online source files, show how to use two different messaging types in JMS: Publish/Subscribe and point-to-point. Sender.java and Receiver.java show how to use queue for point-to-point messaging in JMS, while Publisher.java and Subscriber.java show how to use topic for publish/subscribe messaging. The "Readme.txt" file (also on the Web) contains the commands to run various applications and the latest information about the code. Before attempting to run these applications, be sure to read the "install.txt" file and make the necessary modifications to the WebLogic server as instructed. Because the sample code also contains some more details about annotations and JMS, this article does not fully cover these details, so we encourage readers to examine the source code and run the applications.

Java Messaging Service
The Java Messaging Service is designed as a set of interfaces that will be implemented by MOM vendors and other vendors who want to support messaging (application server vendors, database server vendors, and so on). These interfaces provide a common API for client applications that want to implement code to deliver messages for a possible, given number of underlying messaging systems.
At the same time, JMS is designed to be flexible, providing extensive support for existing messaging systems while maintaining portability. Therefore, it does not support each of the possible message delivery options in each messaging system. Although you may be familiar with any given MOM product, JMS does not automatically support every aspect of the product.
The main concept in JMS is destination. Destination is only an association between the message producer and the message consumer. Destination are divided into two categories: topic and queue. The individual interfaces defined for each destination type allow the vendor to support either type or both types, depending on the vendor's messaging tool. Topic is designed for publish/subscribe messaging, and the queue is designed for customer (point-to-point) message delivery. Both types of destination support persistence. JMS also provides support for transactions. Transactions enable you to support the submission and rollback of message delivery operations. Therefore, if the operation in the transaction fails, you can perform a rollback of the message delivery operation that occurred in the transaction. Similarly, if everything goes well, you can commit these message-passing operations to make them permanent. Because JMS transactions are beyond the scope of this article, I'll let you study these aspects of JMS yourself.

initializing JMS
Connect Factory
To initialize JMS, you need to use ConnectionFactory, which is a markup interface with no methods and can be extended through topicconnectionfactory or queueconnectionfactory. The vendor implements one or two interfaces in these factory interfaces to provide access to their specific messaging service implementations. WebLogic provides a general implementation of each factory type. Factory, as well as topic and queue, are considered "managed" objects, so they are all created when the WebLogic server is powered on (in our case, we will use the WebLogic JMS implementation). These managed objects can then be retrieved through Jndi. You can also use the Jndi naming context to retrieve these managed objects.
If this looks a bit confusing to you, don't worry, the sample code makes it easy to understand them. You can also create your own factory object in WebLogic instead of using the default factory, which is done in weblogic.properties files. The user-defined factory is discussed later in this section, which focuses on topic, and the details of defining your own factory are contained in the Install.txt file, which can be found on the web as well as the source code for this article.
The following code comes from the Sender.java sample, which shows you how to initialize JMS and how to obtain the ConnectionFactory of the queue from Jndi:

Public final String jms_factory = "Javax.jms.QueueConnectionFactory";
...
Queuefx = (queueconnectionfactory) initctx.lookup (jms_factory);

The name of the default connectionfactory for the queue is passed to the lookup () method in the initial Jndi naming context. The reference to the Queueconnectionfactory implementation is then returned to us from the WebLogic Application server (Sender.java in the example code Getinitialcontext () Method shows the details of initializing Jndi and getting the initial naming context from WebLogic. You can get more information about the API from Sun's website. The URL is: http://java.sun.com/products/jndi/1.2/javadoc/index.html).
Because Connectionfactories is a managed object, the WebLogic application server is responsible for creating default connectionfactories for queue, topic, and all user-defined factory and to WebLogic The names in the Jndi implementation are bound together so that they can be found through client code. Therefore, in Jndi, the default connectionfactory name for the queue is "Javax.jms.QueueConnectionFactory", and a reference to the default implementation of this interface is returned when the name is found through Jndi. The reference is provided by WebLogic. Topic also has a default connectionfactory, which follows the same format, that is, "javax.jms.TopicConnectionFactory". Lookups through Jndi will return a reference to the Topicconnectionfactory default implementation, which is also provided by WebLogic.

Connection
After successfully creating the correct connectionfactory, the next step is to create a "connection", which is a JMS-defined interface that represents a client connection to the underlying messaging vendor. ConnectionFactory is responsible for returning connection implementations that can communicate with the underlying messaging system. Typically, the client uses only a single connection. According to the JMS documentation, the purpose of connection is to "encapsulate open connections with JMS providers" and to represent "open TCP/IP sockets between client and provider service routines." The document also states that connection should be a place for client authentication, and that, among other things, the client can specify a unique identifier. Like Connectionfactories, connections also has two types, depending on the type of destination you will use. Queueconnection and Topicconnection both extend the basic connection interface, and usually you can only use one of them, depending on the message delivery method that the customer will be using. The creation of connection is done through ConnectionFactory. Connection contains two important methods: Start and stop, starting and stopping the sending and receiving of messages during the connection process. See the complete code block in Listing 1.

Session
Once you get a connection from the ConnectionFactory, you must create one or more sessions from the connection. The session is also the basic interface, and there are two destination-specific interfaces that extend the basic interface: Queuesession and Topicsession, which can provide a session method that is specific to the queue or topic. A session is a type of factory that produces a message for a destination type (if the destination type is queuesession, it will create a queue-oriented producer and consumer If the destination type is topicsession, then it will create producers and consumers for topic.
Sessions can be transacted or not transacted, and typically you can set this by passing a Boolean parameter to the appropriate creation method on the connection. Similarly, you can pass a parameter to the connection session creation method, which sets the message acknowledgement mode for the session that will be created, which specifies whether the client or the consumer will confirm any information it retrieves (if the transaction mechanism is used, this argument is ignored). Other methods provided by session are various message creation methods that allow you to create a specific type of JMS message that contains text, bytes, attributes, and even a serialized Java object (for more information on the following message interface). Figure 1 is a diagram of the inheritance and creation relationships of the actual JMS interface, see the code in Listing 1.

(Vacant chart)

Destination (destination)
Before creating a producer or consumer of any message, you must have a specific destination, through which you can associate any producer with the consumer. Remember, destination is a managed object, similar to Connectionfactories. This means that the destination is maintained by WebLogic and must be retrieved through a jndi lookup. This also means that, in this case, the destination must be well defined beforehand. But that doesn't mean you always have to create destination in advance. The JMS API provides the ability to create temporary destination, but this destination can only be used during the lifetime of the session in which it was created, and the JMS API can also create permanent destination at run time. However, in the current WebLogic implementation of JMS, it should be noted that if you create destination through session, the destination will exist as long as the WebLogic server is running. If the server fails or freezes, then destination will not exist. The way to create a truly permanent destination is to create it in a weblogic.properties file (see the "install.txt" file for more information on how to do this).
For the purposes of this article, our destination is created in advance by weblogic.properties files. The destination defined in this file is created by the WebLogic application server on power-on and can be used for client code through JNDI. Listing 1 shows the code in the Send.java file, showing how to create queueconnection and queuesession, and how to retrieve destination like the package hierarchy of the sender application, we weblogic.properties the file The name of the queue defined in is "Jdj.article.queue.sender".

The consumer of the message and the producer of the message
The final phase of the JMS initialization process is the creation of Messageconsumers and messageproducers. Like ConnectionFactory, they also have connection and session two basic interfaces, and in order to use topic or queue, there are some destination-specific basic interfaces that extend these two basic interfaces. (I use the term producer when using messageproducer and use the term consumer when using Messageconsumer). Messageconsumers is used to retrieve messages sent to destination, Messageproducers is used to send messages to destination. Both are created by the session instance. MessageProducer are extended by destination-specific interfaces Queuesender and Topicpublisher. Messageconsumer is extended by the QueueReceiver and TopicSubscriber interfaces.
Once you have created your own messageconsumer and/or MessageProducer, you're ready to receive and/or send messages. Because the creation of producers and consumers is specific to queue or topic, I will discuss these two types of processing specific to destination types in the relevant section below.

message
Before we go into the next step and begin to delve deeper into the message sending and receiving in topic and queue, we need to discuss another interface, the message, which represents the JMS messages themselves. This object contains information that will be sent to the destination, as well as information received by the consumer listening on the destination. The message is created by a session instance, which consists of three parts: a header, a property, and a message body. Message headers are used to identify and route messages, and client developers typically do not see or process message header information. Property supports application-specific values passed through a message. These property fields are predefined and the full description of them can be found in the JMS documentation. I'll use some of the properties in the sample code. The body part of the message is the actual "payload" of the message, which has 5 types and can be represented by 5 specific interfaces: Streammessage, Mapmessage, ObjectMessage, TextMessage and Bytesmessage (see Figure 1).

Persistence of
One important aspect of JMS is also worth discussing: it supports the persistent delivery of messages. Quite simply, this means that when a message is sent to destination, if the consumer is not running or unavailable, the message is saved until the next consumer connection to destination. For example, if you have 5 applications listening on one topic, one of them crashes, the next time the application starts and connects to this particular topic, even though the application crashes, But all messages sent to this topic will be sent to the application when the application starts listening again. If this seems hard to understand, it makes more sense when you run the sample code.

Queues
The queue is designed for "point-to-point" or "one-to-one" message delivery. This means that only one client should send a message to the queue, and only one application can handle the messages in this queue.
In fact, you can have multiple clients that send messages to one queue, but only one application handles the messages in that queue. If there are multiple consumer on the queue, then which consumer receive the message is not guaranteed, but only one consumer receive the message. If multiple consumer are required on the destination and you want them to receive the same message, you should use topic (see later in this article).
The Sender.java and Receiver.java files contain code that shows how to use the queue. This code demonstrates the JMS initialization process and shows how to retrieve predefined queue and how to create MessageProducer and Messageconsumer to send and receive messages on the queue.
To consume and generate messages in the queue, there are two specific interfaces in the system. One of the interfaces is Queuesender, which is returned from Queuesession by calling a Createqueuesender () method of the Queuesession, which is used to send messages to the queue. The other interface is QueueReceiver, which is returned from Queuesession by calling a Createqueuereceiver () method of Queuesession to receive messages from the queue.
Listing 2 is the code from the Sender.java sendmsg method, which shows how to create a messageproducer from the session, and then construct a textmessage and send it. In this code, we'll create a queuesender and then create a textmessage that contains the text retrieved from the TextField of the application's user interface. We then use the Queuesender method to "send" the message.
On Messageconsumer, there are two ways to handle incoming message reception: synchronous and asynchronous. The first step is to create the Messageconsumer, and the next step is to determine whether you want to send messages synchronously or asynchronously on consumer.
After you create a messageconsumer from the session, you can invoke the retrieval method on Messageconsumer If you want to synchronize to receive the next message generated for destination. The method does not take any arguments, and it is blocked until the next message is received, and it is returned to the caller. To receive asynchronous messages, you can register an implementation of a MessageListener interface to the Messageconsumer. This method applies to both topic and queue. MessageListener only one method that you must implement is--onmessage, which receives only one parameter, the message. This method is invoked when the OnMessage is implemented for each message sent to destination. This process is demonstrated in the OnMessage implementation in Sender.java and Receiver.java. In Receiver.java, we put the following code into the Initializejms method, which creates the Messageconsumer (a queuereceiver) and sets the implementation of the MessageListener:

Create a Receiver for the Queue ...
Receiver = Session.createreceiver (queue);
Set The Listener (this class)
Receiver.setmessagelistener (this);

Once the connection Start method is invoked, the message begins to enter the consumer when it arrives at destination.

replyto--using temporary queues
You will also notice that both Sender.java and Receiver.java are Messageconsumers and messageproducers. Both have achieved messagelistener. This illustrates an interesting feature of JMS, that is, it uses a temporary destination. An application that wants to receive a response to the information it generates can create a temporary queue or topic and pass the destination in the message it sends.
One of the properties of the message is the Jmsreplyto property. This attribute is used for this purpose. You can create a temporary queue or topic and put it into the Jmsreplyto property of the message. The consumer who receives the message has a private temporary destination that can be used to respond to the sender. This can be explained in two ways, which are in two files. The Sender.java contains the following code snippet, which creates a temporary queue and places it in the TextMessage Jmsreplyto property:

Create a temporary queue for replies ...
Tempqueue = (Queue) session.createtemporaryqueue ();

The above line of code can be found in the Sender.java Initializejms method. This code will create a temporary queue when the application is started, and the queue will exist throughout the application lifecycle. The following line of code can be found in the Sender.java sendmsg method, which shows how to set the Jmsreplyto property to include a temporary queue.

Set ReplyTo to temporary queue ...
Msg.setjmsreplyto (Tempqueue);

When this message is received by Receiver.java's QueueReceiver, a temporary queue is extracted from the Jmsreplyto field, and a queuesender is constructed through the application to send the response message back to Sender.java. This shows how to use the properties of the JMS message and shows the usefulness of a private temporary destination. It also shows how the client can be both a producer of the message and a consumer of the message. The following code is from Receiver.java, which shows how to extract the temporary queue from the JMS message, which can be found in the OnMessage method:

Get the temporary queue from the Jmsreplyto
The message ...
Tempqueue = (Queue) msg.getjmsreplyto ();

The following code block comes from the Sendreplytomsg method, which shows how to create Queuesender and how to send a reply:

Create a Sender for the temporary queue
if (sender = null)
Sender = Session.createsender (tempqueue);
TextMessage msg = Session.createtextmessage ();
Msg.settext (Replyto_text);
...
Send the message to the temporary queue ...
Sender.send (msg);

subject
Topic is designed to implement the Publish/Subscribe message delivery mechanism. While the queue is designed to have a producer and a consumer, the topic design goal is to allow multiple producer to send messages to it, as well as multiple topic to receive the same message from consumer.
Topic's messageproducers and Messageconsumers are created in a similar process to the queue. You can use the session to create Topicpublishers and topicsubscribers. Queuesender and queuereceiver mirrors exist because they both provide topic-specific functionality and implement basic messageproducer and Messageconsumer interfaces.
The Topicpublisher creation process is almost identical to the Queuesender creation process. The following code comes from the Publisher.java sendmsg method, which shows the Topicpublisher creation process and how to post a message to topic:

Create a Publisher if there isn ' t one ...
if (publisher = null)
Publisher = Session.createpublisher (topic);
TextMessage msg = Session.createtextmessage ();
Msg.settext (text);
...
Publish it to the topic ...
Publisher.publish (msg);

Persistent subscriber
One interesting aspect of Topicsubscribers is its persistent subscriber, the unique name provided by the user, that can be identified in the session. The session has a client ID associated with it, which is either defined at run time by a method call on connection or as part of a managed connectionfactory (in our case, It is defined in this way in the Weblogic.properties file. Therefore, a connection can provide a session with a client ID, and the name of the persistent subscriber is the unique identifier in the session, which is associated with a specific client ID. The purpose of a durable subscriber is to create a unique, persistent consumer for a given topic.
An application that creates topicsubscriber by calling the Topicsession Createdurablesubscriber method must pass the name of a persistent subscriber (a string) as one of its arguments; You can set the name of the persistent subscriber to the name of the user who is currently logged on, and so on. This name uniquely identifies a particular subscriber to a topic (along with Connection/session's unique client ID). Once the persistent subscriber has been registered with the topic, the topic will persist in ensuring that the message is sent to this Subscriber. This means that if a particular durable subscriber is unavailable, the message will be saved until the next time this persistent subscriber (with the same, unique persistent subscriber name and client ID) is registered as a consumer. The Subscriber.java file shows the creation of a persistent subscriber and allows you to use the default subscriber name, or set this identifier from the command line (for more details about running this application and demonstrating permanent access to the message by having a durable subscriber), see Readme.txt "). The following code fragment comes from the Subscriber.java initializejms method, which shows how to create a persistent subscriber from Topicsession:

Subscriber = Session.createdurablesubscriber (
Topic
SubscriberId,
SELECTOR,
FALSE);
Set The Listener (this class)
Subscriber.setmessagelistener (this);

Topicsubscribers is not created as a persistent subscriber, so it does not receive messages persistently, but only receives messages during run time.
For further information on persistent subscribers and topic, refer to the Sun's JMS documentation. Another point about the above code is: Note that the third parameter passed to the method is selector. This is where the message selector is associated with consumer (see below for more information about the message selector).

filtering--Using message selector
The last aspect of JMS that we'll discuss is the message selector, which is a filter for messageconsumers that filters the properties and headers of incoming messages (but does not filter the message body) and determines whether the message will actually be consumed. According to the JMS documentation, the message selector is a string of strings that are based on a syntax that is a subset of SQL-92. You can use the message selector as part of the Messageconsumer creation. Depending on whether Messageconsumer is QueueReceiver or TopicSubscriber, this method of applying message selectors to incoming information is slightly different. I recommend that you check the syntax of the message collector and see how to apply them by examining the Subscriber.java files and running Publisher and subscriber applications. The following snippet defines a message selector in Subscriber.java, and the application itself allows you to change the selector from a text field:

Public final String SELECTOR = "Jmstype = ' topic_publisher '";

The selector examines the Jmstype attribute of the incoming message from topic and determines whether the value of this property is equal to Topic_publisher. If equal, the message is passed to the MessageListener implementation, and if not equal, the message is ignored. See the "Readme.txt" file for more details on running these applications and demonstrating their behavior. It is also recommended that you refer to the Sun's JMS documentation.

Concluding remarks
JMS is an attractive, powerful technique for creating portable messaging code in an application. It allows for "point-to-point" and "Publish/subscribe" messaging, and also supports transaction and persistence. BEA's WebLogic Application server provides a robust and complete JMS implementation that works with other technologies provided by application servers, such as EJBS and servlet. This creates a great possibility for permanent, asynchronous messaging between different enterprise objects and services through transactional support. I hope this article encourages you to develop the online sample code and encourages you to examine the possibilities offered by WebLogic (especially JMS).

Original source
Http://www.sys-con.com/story/?storyid=42639&de=1