J2EE Patterns

Being a software designer, developer, or architect is not an easy job. To be truly effective, you must combine an understanding of the features required—the so-called problem domain—with a knowledge of the technologies and products from which the solution will be built. It is difficult for most practitioners to keep abreast of changing technologies in parallel with actually delivering applications to aggressive timescales. What is needed is help to understand the best way to apply technologies and solve common design problems, rather than having to learn from trial and error. Patterns, and specifically in the context of this book, J2EE patterns, can help you do this.

What Are Patterns?

To understand the intent of patterns, it is useful to understand a little bit of their background.

The original inspiration of the software patterns movement came from outside the software industry. It was the work of the architect Christopher Alexander; his considerations of how we design buildings led him to identify and document common features of successful buildings. These common design features were christened patterns, and the documentation of a related set of them is termed a pattern language. Alexander's work can be explored in his writings, such as his book, The Timeless Way of Building.

An architect who designs buildings is constrained only by the qualities of the materials with which the building can be constructed, together with cost constraints and certain physical laws (such as gravity, for example!). This leads architects to experiment with different forms of building, based on new materials and fashions in design. Some of these experiments are successful and turn up whole new ways of living and working. Many more experiments create buildings that are uninhabitable and are torn down in a relatively short time. Most architects need to build useful buildings that form a pleasant environment for those who live and work in them. The intention of Alexander's patterns is to provide a set of proven building blocks on which such architects can base their designs.

Now, consider the preceding paragraph in software terms.

An architect who designs software systems is constrained only by the technologies with which the system can be constructed together with cost constraints and certain physical laws (such as available bandwidth!). This leads architects to experiment with different forms of system, based on new technologies and fashions in design. Some of these experiments are successful and turn up whole new styles of application. Many more experiments create applications that are unusable and are discarded in a relatively short time. Most architects need to build useful applications that create a pleasant experience for those who live and work with them. The intention of software patterns is to provide a set of proven building blocks on which such architects can base their designs.

As you can see from this comparison, the motivations and intentions of architectural and software patterns have much in common.

So, what is a pattern? A short definition of a pattern is “A recurring solution to a problem in a context.” (For a general discussion of the definition of patterns, see http://hillside.net/patterns/definition.html) Essentially, a pattern is a reusable idea on how to solve a particular problem found in the domain of architecture or design, whether that be physical buildings or software systems. The key aspect of patterns is that they are proven solutions—you discover patterns, you don't invent them!

The concrete form of a pattern is a document describing certain aspects, including the following:

  • A statement of the problem that the pattern addresses. This can include a list of conflicting requirements and issues that need to be balanced—known as forces.

  • Contexts in which the pattern is known to work.

  • A description of the solution, possibly including the detailed workings of the solution as it is applied in one context. For example, a software pattern may include code samples.

A pattern description may also set out different strategies within the pattern. These describe different approaches to solving the problem, possibly using different technologies or techniques, while still applying the same underlying principle.

Although patterns have common central aspects, there is no fixed way of documenting a pattern. Certain groups of patterns and pattern languages will adopt their own style of documentation that suits their needs. The main thing is that it is understandable and accessible.

If you want to investigate the general concept of patterns, the philosophy behind them, and the work of Christopher Alexander, try the following locations:

Why Use Patterns?

The intent of patterns, then, is to provide a certain level of what might be termed “distilled wisdom.” If people are lucky enough to work alongside a skilled architect or designer when they are learning their trade, they will gain such “wisdom” by osmosis. Patterns help the propagation of such wisdom so that the written pattern becomes a way of gaining some of the wisdom, even if you do not work alongside such a luminary.

The patterns become a tool chest for the designer or architect from which they can select. These tools can help them create an efficient, robust, and flexible solution. As such, the designer or architect must familiarize themselves with the patterns to the extent that they become adept at identifying the type of problem each pattern addresses and the pattern's context. In doing so, they can ensure that they select the right pattern or combination of patterns for the task at hand.

It is important to note that patterns are a guideline for a solution—not a solution themselves. Although some design tools now provide templates for the implementation of common patterns, you cannot just drag-and-drop patterns into an application to form a solution. As a chef will adapt a recipe to suit the ingredients available and the taste of the guests, so a designer may adjust the implementation of a pattern to suit the specific context.

Types of Patterns

Patterns occur in all aspects of life, from spiders' webs to the way a school works. Some patterns are small and specific while others are general and wide-ranging. The same is true of the patterns found in the realm of software. The following are some common types of patterns:

  • Architectural patterns define the overall style of the system and frequently include physical partitioning and infrastructure considerations as well as the software itself.

  • Design patterns work at the level of software artifacts, such as classes and components, and describe ways in which such artifacts can be built and combined to solve common problems.

  • Idioms are ways of solving a particular problem in a given environment, such as a language or platform. Some idioms are the embodiment of a pattern for a particular environment. For example, the Java mechanisms around the Cloneable interface and the reflection API are idioms that embody more general creational patterns.

  • Process patterns have been identified relating to the actual mechanics of designing and creating the software and systems.

  • Analysis patterns list common problems found in a particular business domain and ways in which these problems can be modeled.

The concept of patterns applied in the field of software was popularized mainly by the book Design Patterns—Elements of Reusable Object-Oriented Software written by Gamma, Helm, Johnson, and Vlissides. This is commonly referred to as the ”Gang of Four” book, or GoF for short. As its name suggests, this book contains a set of design patterns that are independent of platform and language. Many software patterns, including the J2EE patterns examined later, reference GoF patterns to help the reader understand aspects of the pattern being described.

Because patterns are found at different levels, the design of a system can involve the application of patterns inside patterns. An architectural pattern may define tiers or services from which the system is built. The contents of these tiers and services may be specified in terms of groups of components that conform to design patterns. These components, in turn, may be implemented using language- or platform-level idioms.

Sets of interlocking patterns have been discovered for a particular context or at a particular level. These pattern languages help to promote consistent and coherent use of patterns. One such context is the J2EE platform, and it is a pattern language for this environment that will be explored today.

J2EE Patterns

The term J2EE patterns is used to refer to a set of patterns that have been identified within J2EE-based solutions. These patterns describe how to apply J2EE technologies to address common problems found when creating modern, distributed systems. As such, they fit the criterion stated earlier that they are “a solution to a problem in a context.” In the case of J2EE patterns, that context is the J2EE platform and the typical application architectures used when building J2EE applications.

Some patterns come with the territory in that they are found within the J2EE platform itself. However, the term J2EE patterns tends to refer to patterns that can be applied when creating systems on top of the J2EE platform.

Some J2EE patterns are simply direct implementations of previously identified patterns using J2EE technologies. An example of this would be the use of publish/subscribe when applying JMS (see Day 9, “Java Message Service”). Other patterns are specific adaptations of known patterns for J2EE-oriented issues. An example of this is the Session Façade pattern, discussed later in the section on “Session Façades and Entity EJBs,” that encourages correct use of Entity EJBs.

Given that all J2EE patterns share a common context (namely, J2EE), they form a pattern language within that context. Some J2EE patterns are built on concepts from J2EE patterns or include them as part of a suggested implementation.

NOTE

The set of J2EE patterns laid out here (and in other places) does not form a closed set from which J2EE applications can be built. An architect or designer can apply generic patterns or architectural patterns as they see fit when creating a J2EE-based solution. The J2EE-specific patterns simply provide a known set of J2EE-oriented solutions.


Pattern Catalogs

Patterns tend to evolve. There is no central body for the approval of patterns. A pattern tends to become accepted over time (or not, as the case may be) by the general audience or designers and architects at which it is targeted. Given this, how do you find patterns that you can apply?

There are various places where you can find information on patterns:

In all cases, the patterns are embodied in documentation and examples.

You should note that there is a certain amount of duplication in the world of J2EE patterns. All true patterns are derived from experience and individual designers and architects reflect on their experiences in parallel. As noted, there is no single definitive list of J2EE patterns and there is not even one central forum in which all J2EE designers exchange their thoughts and ideas. Because of this, different people have documented the same patterns in separate pattern catalogs. Sometimes, these patterns have the same name and it is just a matter of there being different descriptions. Don't worry about such overlap and differences in perspective—it can be very useful to have several perspectives on the same concept. However, to keep things simple, we have always referenced a single source in our lists of J2EE patterns.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.139.97.202