http://www.devx.com | Printed from http://www.devx.com/Java/Article/20184/1954 |
JMS Enables Concurrent Processing in EJB
JMS provides an elegant solution for overcoming the restrictions you face when developing concurrent applications with EJB. Learn how its asynchronous model and its support for the MessageDrivenBean can enable a client to use EJB asynchronously.
by
Mani Malarvannan
|
wo major limitations in the Enterprise JavaBeans (EJB) specification make it difficult to develop multi-threaded EJB applications:
These restrictions make it difficult to develop concurrent applications with EJB. Luckily, by utilizing JMS along with EJB within your applications, you can achieve concurrency. JMS's asynchronous model and its support for the MessageDrivenBean (MDB) can be applied as a mechanism for a client to use EJB asynchronously.
The Need for Concurrency in EJB Now consider a client that has a set of commodities and wants to find a minimum price for each. The client can call the SessionBean by passing one commodity at a time to find its minimum price; in which case it has to call the SessionBean serially for each commodity. Due to the restrictions in EJB, you cannot create threads within the SessionBean that will allow it to accept the commodity in a new thread and return the control back to the client, enabling it to send the next commodity. The only alternative for the client is to create multiple threads outside the SessionBean, so that each thread can call the SessionBean concurrently to find the minimum price for the Commodities. This approach forces the client to manage the threads, which is extra work. To avoid creating multiple threads in the client, you can use JMS to send each commodity asynchronously for processing in the SessionBean. The JMS approach is also useful when communication between the client and the SessionBean is unreliable, or when the client and the SessionBean are distributed on a heterogeneous platform.
|
JMS Design for Concurrency To call EJB concurrently, you can design a set of classes that a client uses to divide a task into subtasks. Then the client can send each subtask asynchronously as a message to JMS Queue for processing by the MDB. The MDB can call the SessionBean to process the subtask and then to send an acknowledgement back to the client. The following section discusses both the client-side and server-side designs for using EJBs concurrently.
Client-side Design
TaskManager You use three methods collectively to perform subtask management for the clients:
JMSTaskManager
The
The
The
The You can create two types of QueueReceivers, one using MessageSelector and one without using it. If the subclass of JMSTaskManager provides a MessageSelector, you use it to construct the QueueReceiver. The JMSTaskManager uses the date as the MessageSelector to filter the acknowledgement messages from the MDB. This feature allows more than one client to use the JMSMessageManager to send subtasks concurrently to MDB (see Figure 17). In this scenario, each client uses its own date as the message Selector so that JMSTaskManager receives acknowledgement messages for its date.
The
Server-side Design
SubtaskMessageBean
The JMS Server calls the
The
QueueConstants
|
JMS Design Implementation Now it's time to see how you can use the client- and server-side designs and develop a simple implementation for sending subtasks to the SubtaskMessageBean. You need to implement only the client side. For the server side, you do not need to implement any new classes.
SimpleTaskManager
The
The
DemoClient
Running the Implementation in WSAD 5.1
Set Up Client-side Classes
The above steps create a DemoClient and DemoClientEAR projects in WSAD, which you can see in Project Navigator. Open the DemoClient project and select appClientModule. Right mouse click to open the pop-up and choose Import. From the Import pop-up, select Zip file (see Figure 5) and press Next. In the file location specify the location of DemoClient.zip (included in the code download for this article) and press Finish. This will import the all the client-side Java classes and place them in a com.cybelink.client package. You can see all the classes in the package com.cybelink.client in the Project Navigator window in a J2EE perspective. You will also see a red x mark on the SimpleTaskManager class. Open SimpleTaskManager and you'll notice the compiler complaining about missing com.cybelink.mdb.QueueConstants. You'll resolve this when you finish importing server-side classes.
Now you need to add the class name in the client Deployment Descriptor so that you can call the
After importing all the client-side classes, the next step is creating an application client configuration that will start the DemoClient application. From the J2EE perspective, choose Run in the Main Menu and from the sub menus choose Run again to open a pop-up. In the pop-up's configurations options on the left panel (see Figure 7), choose WebSphere v5 Application client and press New. In the name field, change the configuration from New_configuration to DemoClient and press Apply. Make sure that DemoClientEAR is selected for the Enterprise Application and DemoClient for Application client. Select Classpath and press Add External JARs.
In the Jar Selection pop-up, choose the com.ibm.mq.jar and com.ibm.mqjms.jar files (see Figure 8) and press Open. These two Jar files are located in your
You have created a Java client project, imported the necessary Java classes, and added the necessary Jar files so that DemoClient can start within WSAD 5.1 and communicate with the WebSphere MQ. Your next step is to create a project for server-side SubtaskMessageBean so that WSAD 5.1 can start it.
Set Up Server-side Classes
Create a Project for MDB
Open the SimpletaskMDB project, choose ejbModule, and right mouse click to open a pop-up window. From that window (see Figure 5), select Import and choose Zip File. Enter the SimpletaskMDB.zip (included in the code download for this article) location to import the SimpletaskMDB and QueueConstants Java classes into WSAD 5.1.
Now you can fix the DemoClient Project's missing QueueConstants reference in SimpleTaskManager. Select DemoClient project and right mouse click. From the opened pop-up window, select Properties option. In the window (see Figure 10), choose the Java Build Path option on the left panel. On the right, choose the Projects tab, select the SimpletaskMDB project, and press OK. This enables the classes in the DemoClient project to access the classes in the SimpletaskMDB project. Youll see the compiler errors cleared from SimpleTaskManager.
Now you are ready to configure the SimpleTaskMessageBean in ejb-jar.xml so that it can listen for incoming messages in WebSphere MQ.
Open the ejb-jar.xml file, which is under META-INF in the project SimpletaskMDB, and then go to the Beans tab. In the Beans page, press the Add button to open the pop-up (see Figure 11), select Message-driven bean, and enter SubtaskMessage for the Bean name. Press Next to select Queue for Destination Type (see Figure 12) and enter subtaskListenerQ for ListenerPort Name. Press Finish to close the pop-up.
You have modified the ejb-jar.xml file to include the SubtaskMessageBean configuration parameters.
Server and Server Configuration Creation
For the Server Name type EJBConcurrency and for the Server type select Test Environment. Press Finish to close the pop-up. These steps create a new Server EJBConcurrency, which you can see in the Server Configuration window. Right mouse click the EJBConcurrency and select Add and remove Projects. From the pop-up (see Figure 14) choose DemoClientEAR from the Available Projects and press Add. Then press Finish to add DemoClientEAR to EJBConcurrency Server.
Your next task is to configure the EJBConcurrency server so that WebSphere MQ can start the JMS queues. In the Server Configuration open EJBConcurrency in the editor and press the JMS tab to open the WebSphere MQ configuration screen. In JMS Server Properties under Server Settings (see Figure 16), click the Add button to enter Queue Name SubtaskSendQueue. Similarly enter Queue Name SubtaskReceiveQueue. In the JMS Provider options, select Embedded Messaging. In the WASQueueConnectionFactory entries, press the Add button to open the pop-up window (see Figure 15). In the Name field, enter QConnectionFactory. For JNDI Name, enter jms/QConnectionFactory and press OK to close the pop-up.
In the WASQueue entries, press Add to open the pop-up window. Enter SubtaskSendQueue for Name and jms/SubtaskSendQueue for the JNDI name. Similarly, add SubtaskReceiveQueue and jms/SubtaskReceiveQueue. After all these changes your server setting will look like Figure 16.
Now press the EJB tab to enter Listener Port information for the SubtaskMessageBean. Press the Add button to open the pop-up window (see Figure 17) and enter subtaskListenerQ for Name, select jms/QConnectionFactory for Connection Factory JNDI Name, and select jms/SubtaskSendQueue for Destination for JNDI Name. Leave the rest of the fields as is. Press OK to close the window and save all your configuration changes.
After all the preceding setup steps, you are now ready to run your client and server programs in WSAD 5.1.
Run the Client and Server Programs
From the Server perspective, select EJBConcurrency, right mouse click to open the pop-up, and select Start to start the EJBConcurrency Server. These steps start the SubtaskMessageBean, which listens for JMS Messages in the subtaskListenerQ port to process the subtasks the DemoClient sends.
Switch to the J2EE perspective. Open the Run menu (see Figure 7), choose DemoClient, and press Run to have the DemoClient send subtasks to SubtaskMessageBean.
The DemoClient (see Figure 18) communicates with the SimpleTaskManager, which sends the JMS messages to the SubtaskSendQueue. The SubtaskMessageBean listens in the port subtaskListenerQ for JMS messages that come into the SubtaskSendQueue. Then it retrieves the Subtask, processes it, and sends a JMS acknowledgement to SubtaskReceiveQueue. The SimpleTaskManager that sends the JMS subtask will get the acknowledgement from the SubtaskReceiveQueue and notify the DemoClient. Figure 13 shows two DemoClients started concurrently, each with its own SimpleTaskManager sending subtasks to SubtaskSendQueue and receiving acknowledgements from the SubtskReceiveQueue.
Figure 19 and Figure 20 show the WSAD 5.1 Console window for DemoClient and Server, respectively.
|
Concurrent Applications with EJBs JMS provides an elegant solution for overcoming the restrictions you face when developing concurrent applications with EJBs. The basic techniques described in client-side and server-side classes can be extended to develop various types of concurrent applications using EJB and JMS. Although this article explains how to use these classes in the context of concurrent applications, you can also use them to develop various other JMS applications. This is due to the fact that they abstract the generic behavior of connecting to JMS Queues, sending messages, and waiting for acknowledgements. Similarly, you have used WSAD 5.1 to configure and run the program, but you can also use any J2EE-based app server to run it.
Mani Malarvannan is a consultant at Cybelink Systems. He has been developing Web-based applications using object-oriented methodologies and software patterns for several years. He has WSAD 5.0 and eBusiness Solutions designer certifications from IBM and holds a MS in Computer Science. .
|
DevX is a division of Jupitermedia Corporation © Copyright 2007 Jupitermedia Corporation. All Rights Reserved. Legal Notices |