Add the power of asynchronous processing to your JSPs

Create custom JSP tags to use with JMS

By Tarak Modi, JavaWorld.com, 02/09/01

So, is the answer as simple as making JSP developers master JMS? Unfortunately not. As I mentioned above, this answer will probably displease many JSP developers. Then, what is the solution?

JSP 1.1 introduced an extremely valuable new capability: the ability to define your own JSP tags, also called custom tags. You can group custom tags into tag libraries and reuse them in any number of JSP files. Custom tags allow complex programming logic to boil down to a set of simple tags, which JSP developers can easily use to develop content. Although custom tags require a bit more effort to set up than normal tags, the benefits definitely outweigh the costs. Tag libraries increase productivity by encouraging labor division between library developers and library users. Developers expert in accessing data and other services create JSP tags; Webpage authors who focus on the design of user interfaces use them.

In this article, I will design and implement two custom JSP tags that will allow JSP developers to work with JMS in the form that they are most comfortable with -- tags. Plus, since all the JMS programming logic is buried deep within the custom tags, JSP developers do not need to learn JMS. That's what I call killing two birds with one stone.

For example, using the write custom tag that you will create in this article, a JSP developer can send/publish a message as shown below:

   <jms:write destination="jms://Queue/ModiQueue" message="Hello World"/>

and can receive a message as follows:

   <jms:read destination="jms://Queue/ModiQueue"/>

Background on JMS

To understand JMS, you must understand message-oriented middleware (MOM), which has grown in popularity over the last few years. Let's take a look at two key characteristics of MOM that differentiate it from the more traditional middleware based on remote procedure call (RPC).

1. MOM allows asynchronous communication between applications: When you send a letter to your friend via snail mail, you obviously do not wait for his response before doing anything else. You go on with your life. At some point, you may receive a response to your letter but, in the meantime, your actions do not depend upon it. That example demonstrates the basics of asynchronous communication and, hence, the basics of how MOM works.
2. MOM allows the communicating applications to have completely separate lifetimes: Consider the following scenario: A salesperson fills in customer orders on his laptop while flying to the corporate office. As the laptop is not connected to the central computer, it cannot process the orders at that time. However, both the laptop and the central computer are equipped with MOM software. Though the laptop cannot communicate with the central computer at the time the salesperson enters the orders, the MOM on the laptop keeps track of those order messages. Once the salesperson is back in his office and hooked up to the corporate intranet, the laptop's MOM fires off those stored messages to the MOM software on the central computer, which receives and processes those messages. The MOM ensures that the messages are not lost, delivered out of sequence, or duplicated. That second aspect of MOM makes it even more critical to successful distributed applications.

Those characteristics make MOM a popular alternative to RPC, which fails to offer either of those capabilities.

So, what does JMS have to do with MOM? JMS provides a standard Java-based interface to MOM's message services. My simplified definition of JMS is as follows: JMS is an API used to access MOM facilities from a Java application.

Figure 1 shows the pictorial form of the above definition.

Figure 1. The JMS architecture

JMS supports two popular messaging styles: point-to-point messaging and publish-and-subscribe messaging.

Point-to-point messaging

In point-to-point messaging, two applications use MOM to communicate with each other, often as an asynchronous replacement for RPC. As shown in Figure 2, JMS allows multiple senders, but only one receiver in this model. A queue, which channels the messages, forms the central concept of point-to-point messaging. An application interested in sending a message begins with a queue connection factory that obtains a queue connection. That queue connection then creates a queue session, the application's personal window into the connection. A JMS client uses that session to create a message producer, which sends messages to the queue.

On the other end, the receiving application goes through a similar sequence of obtaining a queue connection factory, a queue connection, and a queue session. The receiving application's functions differ from the sending application in that it uses the session to create a message consumer to receive messages from the queue.

Figure 2. Point-to-point messaging in JMS

Publish-and-subscribe messaging

When multiple applications need to receive the same message(s), they use the publish-and-subscribe model. Figure 3 illustrates that model, where a many-to-many relationship exists between the message producers and the message consumers. Note, as Figure 3 illustrates, that a topic forms the central concept in that model. Instead of message senders and receivers, you have message publishers and subscribers.

Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq

Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq