Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Messaging makes its move, Part 2

Put the finishing touches on your own Java-based messaging service by adding the required JMS veneer

By Todd Sundsted, JavaWorld.com, 03/01/99

As we learned last month, the Java Message Service Specification (JMS spec) defines an interface for message services but does not define an implementation. Unlike the JDK, if you download the JMS source code from Sun's Web site (see Resources) and examine it, you'll find only interfaces; there are no classes at all (well, actually there are two -- but they are helper classes and not really part of the specification). After a moment's reflection it should be clear why this would be true.

There exists a large body of legacy enterprise applications built around existing messaging products. Given this fact, the JMS architects decided it was more important to allow enterprise Java developers to develop applications that worked within the context of an existing messaging infrastructure than to try to get them to adopt an entirely new product. Of course, developers should be able to create applications without creating additional dependencies on any particular vendor -- thus the JMS spec would be vendor neutral but compatible with existing products.

I've decided to create an implementation of the JMS API in Java for two reasons:

1. For those inclined to technical challenges, creating a Java-based implementation provides an excellent introduction to the practice of writing message-oriented middleware.
   
   
2. For those interested in learning to use the JMS API, creating a Java-based implementation provides a reference to play with. Without it, you'd have to purchase an existing messaging product and the Java interface as well.

I'll begin by presenting the JMS API as it would appear to someone creating an implementation -- that is, as it would appear from the inside.

But I need to share with you one caveat before I begin.

While the JMS API isn't the most complicated of the Java Enterprise APIs, it isn't the least complicated, either. Due to time and space constraints, I haven't made a heroic effort to implement the entire JMS API Specification. I have, however, taken the time to implement a workable subset. Just to be on the safe side, I'll let you know where my implementation comes up short.

You might find it useful to begin with a refresher. Last month I built the classes that implemented the basic underlying functionality of a message service and I presented the basic philosophy behind the JMS API. If you already feel comfortable with that material, then please continue.

A tale of two domains

Recall that the elements of the JMS API are divided into two domains, each representing one of the two leading models of messaging provided by existing messaging products. The two models are the point-to-point model and the publish/subscribe model.

While the behavior of the classes within each domain differ, their APIs are nearly identical. It's the APIs and their use that we're interested in this month.

If you glance at the relationship between the point-to-point and publish/subscribe interfaces, you'll see what I mean.

Point-to-point	Publish/subscribe	Parent interface
Queue	Topic	Destination
QueueConnectionFactory	TopicConnectionFactory	ConnectionFactory
QueueConnection	TopicConnection	Connection
QueueSession	TopicSession	Session
QueueSender	TopicPublisher	MessageProducer
QueueReceiver	TopicSubscriber	MessageConsumer

The first column lists the principle interfaces that define the point-to-point half of the API. The second column lists the principle interfaces that define the publish/subscribe half of the API. The third column lists the parent interfaces from which both the point-to-point and the publish/subscribe interfaces inherit. Note how similar the two domains are from the standpoint of these interfaces.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.