Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

E++: A pattern language for J2EE applications, Part 2

Weave the design patterns together

By Bin Yang, JavaWorld.com, 08/10/01

A good framework represents at least half of a project as it decomposes an application into manageable components with consistent and well-established methodology. After kicking off a J2EE development effort, you need a framework to make it succeed. E++ is a pattern language for developing a MREPICS framework on the J2EE platform. In Part 1 of this series, I explained E++'s applicability, design principles, and architecture patterns.

Read the whole "E++: A pattern language for J2EE applications" series:

• Part 1: Build better J2EE applications with a high-level pattern language
• Part 2: Weave the design patterns together

In this article, the second of two, I continue the progress made in Part 1 by detailing the patterns most important for a successful E++ implementation. As outlined in Part 1, to design the application as a whole, you should follow the E++ tree (Figure 1), from root to branches to leaves. As such, you'll find it useful to refer to the E++ tree as you work through the design patterns detailed below.

Figure 1. The E++ tree

Due to space considerations, it is impossible to detail all of the E++ implementation patterns here; I'll stick to the major patterns and their uses. For more complete information and the related patterns, see the Resources section below. Continuing the practice from Part 1, for each major pattern I will detail:

• The pattern name
• The context in which the pattern applies
• The design problem raised by the context
• The conflicting forces that must be resolved
• The solution offered by the pattern

So, let's get to the patterns!

Pattern name: Application Mediator

Context

The E++ tree starts with Application Mediator, an object that sits between the client and the application to handle all human or nonhuman inputs. As such, it is the single entry point to the application. Such an arrangement is suggested by the Layered Architecture pattern described in Part 1 of this series. On real-world application servers, you achieve this with the configuring<servlet-name>webTierEntryPoint</servlet-name> attribute of a web.xml file.

The problem

What functionality should the Application Mediator possess so that it mediates reusable pieces together?

The forces

You should construct the E++ generic J2EE application framework such that it does not depend on any specific user requirements or actions. As a framework for large-scale enterprise applications, the Application Mediator should address every aspect of the application, such as JSP presentation layout, application models, security, and internationalization.

The solution

The Application Mediator should function like an organization's front desk: it should comprehensively refer to a specific manager to handle a specific set of tasks. As such, the mediator object encapsulates all interconnections, acts as the communications hub, and controls and coordinates its clients' interactions. Further, it delegates suitable user requirements to specific manager objects.

The E++ Application Mediator interacts with the following manager objects:

 

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

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