ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

J2EE Design Patterns

by Sue Spielman
01/16/2002

The term J2EE is tossed around a lot because it is a generic term that covers many areas of enterprise and distributed development. The J2EE modules and environment continue to grow as a rapid pace, and as many of you have come to learn, in recent years J2EE development has had its trials and tribulations.

For exactly this reason, it is important to take advantage of the most efficient and effective strategies for new development or the refactoring of existing projects. To keep up with the new developments, it is imperative that you aren't wasting time maintaining designs that have poor architecture or code that was poorly written.

This article covers how to use and identify design patterns, specifically for the presentation tier, in J2EE applications. The interest in design patterns has been around for a number of years in the software industry. However, interest among mainstream software developers is a fairly recent development -- and one that's long overdue, in my opinion. There are a number of reasons for this: it takes a highly experienced engineer to recognize a pattern; it requires collaboration; and it requires ongoing refinements. It also requires a sense of fluidity. Design patterns are not absolutes -- they are more expressions of proven solutions. It is up to you, the engineer or architect, to apply a pattern appropriately to your given scenario. This, of course, is easier said than done.

Patterns are not a magic pill. Just because a problem is observed and a pattern applied does not mean that you will have a perfect application -- or solution, for that matter. Patterns are a way of bringing clarity to a system architecture and they allow for the possibility of better systems being built. Building a system that meets the intended business requirements, performs well, is maintainable, and is delivered on time, is what keeps us engineers in business. Patterns have the distinct advantage of helping us do it all quicker.

So, What is a Design Pattern Anyway?

First of all, let's define what a design pattern is. There are a number of formal definitions, but I prefer a simple approach: a design pattern is simply a description of a recurring solution to a problem, given a context.

Simple enough. The context is the environment, surroundings, situation, or interrelated conditions within which the problem exists. Design patterns have a number of advantages, among which are:

  • They capture engineering experience.
  • Once described, any level engineer can use the pattern.
  • They allow for reuse without having to reinvent the wheel on a project-by-project basis.
  • They allow for us, as engineers, to better define system structure.
  • They provide a design vocabulary.
  • They also provide reusable artifacts.

It is a rare instance (although not an impossible one), that a design pattern is used in an isolated fashion. Typically, patterns have relationships and work together to form a weave, in that a pattern can be composed of, or rely on, other patterns. That is why you will see that the more familiar you are with different patterns, the better equipped you are to determine their interactions. Patterns can also form frameworks that can then be used for implementations.

Enterprise systems are built crossing many tiers; this should not be news to anyone reading this article. This discussion is focused on the presentation tier, and primarily covers patterns that can be used with JSP and Servlet technology.

Show Me Your Pattern

There are a number of patterns that have been identified by the Sun Java Center for the presentation tier. These are certainly not the only patterns that can be applied, but they are a good starting point. The presentation patterns take into consideration the logic required to service clients that access the system. This includes client requests, single sign-on, session management, access to business services, as well as the creation, formatting, and delivery of responses to the client. These patterns include:

  • Intercepting Filter: facilitates preprocessing and post-processing of a request.
  • Front Controller: provides a centralized controller for managing the handling of requests.
  • View Helper: encapsulates logic that is not related to presentation formatting into Helper components.
  • Composite View: creates an aggregate View from atomic subcomponents.
  • Service To Worker: combines a Dispatcher component with the Front Controller and View Helper patterns.
  • Dispatch View: combines a Dispatcher component with the Front Controller and View Helper patterns, deferring many activities to View processing.

While the patterns listed above might not mean anything to you now, by the time you finish this article, you will understand how using patterns to describe solutions will give you a clear understanding of the problem being discussed, just by the use of the pattern name. Think of the time that will be saved in meetings by just saying, "I think the View Helper can be applied here," instead of droning on about a complete problem description that we've all faced many times.

Helpful Hints

A couple of words of advice if you are just starting on your pattern odyssey.

If you haven't boned up on UML yet, the time is now. UML is quite commonly used to describe patterns in pattern catalogs, including class diagrams, sequence or interaction diagrams, and stereotypes. I'm not going to go into UML in this article, but I highly recommend getting up to speed on it.

When using patterns, it is important to define a naming convention. It will be much easier to manage a project as it grows and identify exactly what role an object plays by using such naming conventions. For example, if you are using the View Helper or Composite View patterns, you might want to define the naming convention to be [action]Helper.java or [action].jsp, respectively; for instance, CreatePageHelper.java or CreatePage.jsp.

Make a list of requirement statements that you will be addressing and then try to identify relevant patterns (once you are familiar with them) that might be applicable. By doing this, you will be amazed at how quickly you will start to recognize appropriate solutions to problems. For example:

  • Requirement: I need one place of control for handling all requests.
    Possible pattern: Front Controller Intercepting Filter.

  • Requirement: I need a generic command interface for delegating processing from a controller to various helper components.
    Possible pattern: Front Controller.

  • Requirement: I want to make sure data related to my presentation formatting logic is encapsulated correctly.
    Possible pattern: View Helper.

  • Requirement: I need to be able to create one View from a number of sub-Views.
    Possible pattern: Composite view.

Pages: 1, 2

Next Pagearrow