 |
IBM
14 Dec 2001
This paper shows how MQSeries message queue can aid back-end communication in a WebSphere application. In this solution, data is collected from an HTML form, converted to an MQSeries message by a servlet, processed by a back-end application and returned to the browser as a JSP. This paper describes the integration of a thin client with
MQSeries® using servlets and JavaServer Pages™ (JSPs™). The requirement specified
for the integration was that a user fills out an HTML form. The user data is
collected from the form and sent via a message queue to a back end application.
The back end application will then process the form data and send a reply back
via the message queue. The reply needs to be displayed in the browser. This paper discusses the interaction of the thin client, servlet,
and message queue, and demonstrates how different products offered by IBM can
be used in the solution. The reader should have knowledge of the Java™ language, and
be familiar with WebSphere® and MQSeries. Architecture overview
The proposed solution architecture is shown below. It involves
a three tier approach. Figure 1.
 Process flow
- The user fills out an HTML form.
- The form is sent to the servlet.
- The servlet converts the HTTP request into a MQSeries message and puts it
in a queue.
- The back end application processes the message and sends a reply back through
a message queue.
- The servlet retrieves the message from the queue and stores it in a Java
Bean.
- The servlet then invokes a JavaServer Page which is compiled and dynamically
generates a result HTML page.
- The JSP retrieves the message content for the page from the Java Bean, incorporates
it into the HTML, and displays the result page back on the browser.
The solution leverages the following technologies:
- HTML / HTTP
- Java - servlets, Java Beans, JavaServer Page
- Web servers
- Message Queue
The solution integrates the following products:
- Netscape 4.0 / Internet Explorer 3.0 or later
- IBM HTTP Server 3.0
- WebSphere 2.02
- JDK version 1.1.7
- MQSeries version 5.0
Connecting to MQSeries
We selected the servlet model because it has many advantages
over CGI. A servlet is a standard server-side Java application that extends
the capabilities of a Web server. A servlet runs completely on the Web Server
and nothing is ever downloaded to the browser. Servlets are loaded into the
server's address space at load time or at the time of the initial request. After
the initial request, they respond very quickly. The servlet's init method prepares
the servlet for work. The init method is called only once per servlet load.
The connection to the MQSeries queue manager in the init method is done as follows:
<font face="courier new" size="1">public void
init(ServletConfig config) throws ServletException {
super.init(config);
try {
//Create a connection to the queue manager
qMgr = new MQQueueManager("NC.QManager");
}
catch (MQException ex)
{
System.out.println
("An MQ error occurred in init(): Completion code " +
ex.completionCode +
" Reason code" + ex.reasonCode);
try
{
if (qMgr != null)
//Disconnect from the queue manager
qMgr.disconnect();
}
catch (MQException e)
{
System.out.println("An MQ error occurred in init()
while disconnecting:
Completion code " +
e.completionCode + " Reason code" + e.reasonCode);
}
}
}
|
Since the connection to MQSeries' queue manager needs to be
established only once, and it takes a long time to establish it, the init method
is an ideal place to execute this procedure. The subsequent calls to the servlet
are then executed faster. WebSphere also allows the user to preload the servlet
using the administration GUI, thus the servlet is ready with an established
connection to the queue manager, and waiting to transfer any messages. If an MQException is caught during the init method, the above
code disconnects from the queue manager. Consequently, the user will have to
reload the servlet in order to establish a connection with the queue manager. In order for the servlet to talk to MQSeries, MQSeries Bindings
for Java must be used. The MQSeries Bindings for Java enable you to write MQSeries
applications using the Java language. These applications communicate directly
with MQSeries queue managers to provide a high productivity, high performance
development option. They use Java native methods to call directly into the existing
queue manager API rather than communicating through an MQSeries server connection
channel; this provides better performance for Java MQSeries applications. In
the code we have to import the package "com.ibm.mqbind.*". MQSeries' java classes
should also be in the WebSphere's class path; this will allow the WebSphere
application server to locate the MQSeries Bindings for Java package. Creating an MQ message
Since the BillingAddressServlet is primarily used for processing
HTTP requests that come from the AddressInputForm, we have subclassed HttpServlet.
This abstract subclass of GenericServlet implements the default service()
method for processing requests. The most common methods for overriding include
doGet() and doPost().
The following example will override the doPost()
method. The AddressInputForm calls this doPost()
method via the following call: <FORM METHOD=POST ACTION="/servlet/BillingAddressServlet">
POST requests send an HTTP body that contains all of the data
being sent to the servlet. The doPost() method
then creates the following message string from the input: <font face="courier new" size="1">String tempAddress = "Input information is";
res.setContentType("text/plain");
..............
if ("application/x-www-form-urlencoded".equals(req.getContentType()))
{
System.out.println("In doPost()");
Enumeration enum = req.getParameterNames();
while (enum.hasMoreElements())
{
String name = (String) enum.nextElement();
String values = req.getParameter(name);
if(values != null) {
tempAddress = tempAddress + "; " + name + ": " + values;
}
}
|
Sending a message
The doPost() method then puts
the message string on the message queue by calling the putOrder()
method with the following code: <font face="courier new" size="1">public void
putOrder(String tempAddress) {
try {
int openOptions = MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_OUTPUT;
//Specify the queue that we wish to open, and the open options.
MQQueue ncOrderDataQ = qMgr.accessQueue("NC.OrderCreateQ",
openOptions,
qManager,
null, // no dynamic q name
null); // no alternate user id
//Define a MQ message
MQMessage customerAddress = new MQMessage();
customerAddress.writeUTF(tempAddress);
//specify the message options
MQPutMessageOptions pmo = new MQPutMessageOptions();
//put the message on the queue
ncOrderDataQ.put(customerAddress, pmo);
//Close the queue
ncOrderDataQ.close();
}
catch .........
|
Retrieving a message
To retrieve the message returned by the backend application,
the doPost() method calls the orderUpdateStatus()
method. The orderUpdateStatus() method retrieves
the message from the queue using the following code:
public String orderUpdateStatus() {
String msgText = null;
try {
int openOptions = MQC.MQOO_INPUT_AS_Q_DEF | MQC.MQOO_OUTPUT;
//Specify the queue that we wish to open, and the open options.
MQQueue ncOrderUpdateQ = qMgr.accessQueue("NC.UpdateQ",
openOptions,
qManager,
null, // no dynamic q name
null); // no alternate user id
//create a new get the message
MQMessage retrievedMessage = new MQMessage();
retrievedMessage.messageId = MQC.MQMI_NONE;
//set the get message options
MQGetMessageOptions gmo = new MQGetMessageOptions();
//get the message off the queue
ncOrderUpdateQ.get(retrievedMessage, gmo);
//Display the message
msgText =
retrievedMessage.readString(retrievedMessage.getMessageLength());
//for NC.UpdateQ
//Close the queue
ncOrderUpdateQ.close();
}
catch .........
|
Invoking the JSP
Finally, the putOrder() method
calls the performTask() method to store the
message in a BillingAddress Bean. The servlet then invokes an AddressOutputPage
JSP and passes it the handle of the BillingAddressBean. The JSP extracts the
dynamic content (that is, the message from the Java Bean) and incorporates it
into the HTML page displayed on the browser.
public void performTask(javax.servlet.http.
HttpServletRequest request,
javax.servlet.http.HttpServletResponse response,
java.lang.String returnMessage) {
try
{
// instantiate the bean
BillingAddressBean myBillingAddressBean = new BillingAddressBean();
// set the return message in the bean
myBillingAddressBean.setMQReturnMessage(returnMessage);
// store the bean in the request so it can be accessed by pages
which are accessed with callPage()
((com.sun.server.http.HttpServiceRequest)request).setAttribute
("BillingAddressBean", myBillingAddressBean);
// Call the output page
((com.sun.server.http.HttpServiceResponse)response).callPage
("/AddressOutputPage.jsp", request);
}
catch .........
|
Conclusion
In this solution, incorporating a servlet and a JSP allows
for the separation of functional logic from the presentation. The servlet acts
as a controller and the JSP as a result view. Also, using the JSP and a Java
Bean provides a clean separation between the display of content and the content
itself. Using the servlets init method to prepare the servlet for work, such
as creating a connection to the queue manager, improves performance. WebSphere
allows the user to preload servlets so time consuming tasks like establishing
connections can be completed during initialization, before the user uses the
servlet. MQSeries enables different applications to be integrated with each
other using messages and queues.
Resources Download
| Name | | | | Size | | | | Download method | | | | WSMQSample.zip | | | | 14 KB | | | | FTP|HTTP | | | | | | | | | | | | | | |
| |
