Simplify JMS with the Facade Design Pattern

JMS provides a multitude of classes, but you need to extend or instantiate them before they're of any use. Although the complexity of this process can be daunting, applying the Facade design pattern makes JMS much simpler to use.

by Eric Bruno

Jan 24, 2003

Page 1 of 4

WEBINAR:

On-Demand

Application Security Testing: An Integral Part of DevOps

~~Watch~~→

he Java Messaging Service (JMS) API, a Sun Microsystems interface for connecting Java programs to enterprise messaging middleware, is composed of multiple object interfaces with a hierarchy of relationships. The JMS class hierarchy in particular is extensive and can seem confusing at first glance. (Figure 1 illustrates the relationships among the classes within JMS.) However, this complexity is necessary for JMS to:

Abstract the implementation details of the underlying messaging software

Interface with existing messaging systems such as IBM's MQSeries, using familiar JavaBean paradigms

Provide and enforce thread-safe code practices


Figure 1: The JMS Class Hierarchy (UML)

Although the reasons for its complexity are sound, the relationships among JMS classes make writing code to the JMS API tedious and confusing at times. Applying the Facade pattern offers a solution to this problem.

A Facade is a design pattern that hides the details and complexities of the lower-level software service for which it is written, making the service easier to use. In fact, the lower-level classes need not be classes at all. They can be an API in the form of a code library or a Web service.

A Facade also provides a unified entry point into the layers of the software. This reduces your application's dependency on the software service details and allows the Facade to hide future changes in the software service itself.