I am writing a portion of a J2EE application and would like to perform asynchronous processing. Following are some questions i have:
How does JMS process message, queue and Message-Driven-Beans? I mean when a message is send to a queue, how does it know which MDB should be receiving the message?
I am using JBoss and WebLogic App servers which has JMS Under normal circumtances, is it all right to use the default queue that comes with the JMSProvider (i.e. the application server in this case)? Or should we write some other codes for create queue?
In terms of design, should one MDB only performs a single function? The reason for this is that a MDB seems to only have a single 'onMessage' method?
The following is what my application tries to achieve: Servlet will call a method in a StatelessSessionBean. SessionBean perform first some processing. And since part of the process does not require to be done at the same time, i would like it to happen asynchronously. I actually intend to have that part of the processing happens in an MDB. Is that the correct way to use JMS & MDB? How else could i perform asynchronous processing?
Laurel, Maryland, USA.
.................................................................................................. Naidu Sanapala - JAVA ARCHITECT , Laurel , Maryland , USA 1.SUN Certified Enterprise Architect for J2EE Technology 2.Sun Certified [EJB] Business Component Developer for the J2EE Platform 3.Sun Certified Web Component Developer for the J2EE Platform 4.Sun Certified Java Programmer for the Java 2 Platform - 1.4 5.IBM Certified Solution Developer for XML and Related Technologies ....................................................................................................
Hai Naidu Sanapala, You are right. This is the situation where u use MDBs You can do ur asynchronous works with MDBs.
I ll answer your questions now.
For using a MDB you must configure an QueueConnectionFactory in your Application Server. There are two types of communication models 1. Point-Point Model 2. Publish/Subscribe Model In the first one you can have only one listener(MDBs) to your Queue but there may be more message senders. If you register more than one listener to a queue, the server will send the message to only one (it does not guarantee who the beneficiary is). In the second Model You can have multiple listeners and multiple senders. The server will send to all the registered listeners(MDBs). First select which type you want. Depending upon the model you must either select javax.jms.Queue(for Point-Point) or javax.jms.Topic(for Publish/Subscribe).
when a message is send to a queue, how does it know which MDB should be receiving the message? First you need a "queue connection factory and queue" for yourself (i.e specific for your application). This is for security reason so that no other person must register himself as a listener and tap all the messages.(See your server documentation for creating a queue connection factory and queue). Then state those settings in your deployment descriptor either manually or using a server tool for that bean. That's all its all set. Now when ever a client gets an instance of that queueConnectionFactory through JNDI lookup and posts a message to it, the respective MDB who hold that particular queueConnectionFactory in its deployment descriptor will receive it.(See your server documentation to get more details of how to relate a MDB with a QueueConnectionFactory and Queue using a server tool).
In terms of design, should one MDB only performs a single function? The reason for this is that a MDB seems to only have a single 'onMessage' method? Its not so. MDB can be designed as a normal java class. As how a normal java class has to be designed with one particular resposibility MDBs must also has to have one particular resposibility. You can declare many other methods in that bean and call it from that onMessage() method. Comparing to a normal java class this method acts as a "main" method as in normal java class.
Veshnu<br />SCBCD<br />SCWCD<br />SCJP
look! it's a bird! it's a plane! It's .... a teeny tiny ad
Two software engineers solve most of the world's problems in one K&R sized book