Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

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:



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:

  • The ComponentManager loads the component module information at runtime through an XML interface. It helps decouple the framework from domain-specific programming. The ModelManager manager uses the supplied information.
  • The JSP Layout manager selects application presentations; it comprises JSP Template, JSP Page, and JSP Tag.
  • The Event Processor, a help object, changes application models at all tiers according user requests.
  • The Locale Manager handles language localization.
  • The Security Manager operates the application's security realm.
  • The ModelManager handles model synchronization of different tiers and serves as a gateway of the model retrieval from the Web tier.


Each of these manager objects works with general human or nonhuman clients (XML inputs). Each is cached in ServletContext as soon as it instantiates at startup time, with the exception of ModelManager. Since ModelManager keeps a specific session's EJB registry for fast access, it is cached in HttpSession.

In a simple example, let's examine the characteristics of an Application Mediator pattern:

  • It's designed as a HttpServlet.
  • All client inputs (HttpRequests) go through the servlet's doGet() or doPost() methods.
  • It creates or retrieves a ComponentManager JavaBean that loads and caches customized module information.
  • It creates or retrieves a JSP Layout Manager JavaBean that gets the next screen, if required
  • It creates or retrieves an Event Processor JavaBean that passes the requests. The processor will process all user requests to change application EJBs and other related functionality
  • It creates or retrieves a ModelManager JavaBean that handles synchronization of different tiers and serves as a gateway of model retrieval from the Web tier.
  • It creates or retrieves a LocaleManager JavaBean that determines the specific language locale for the request. Remember, 2-byte Java character encoding just provides internationalization and localization potential.
  • It creates or retrieves a SecurityManager JavaBean that handles the security realm.


Figure 2 shows the Application Mediator pattern's UML diagram. A general reminder: all the managers should implement a serializable interface that can be replicated in a failover or cluster environment.

Figure 2. The Application Mediator



Pattern name: Component Manager

Context

You need to design the Component Manager.

The problem

The Component Manager should not hardcode application-specific Java objects and EJBs; if it does, the E++ framework will not be directly reusable for any other applications. With this in mind, how do you decouple the Component Manager from the customized module information, and, at the same time, be able to use them?

The forces

The Component Manager must load application-specific information, such as an EJB URL, at runtime; it should not compromise application performance.

The solution

Use an XML file to describe your module information. The Component Manager has an XML parser to load the file at startup time; as it will be cached in ServletContext for general use, you will not experience any performance degradation. This design allows E++ to work with any import module -- but not depend on them. Figure 3 shows the Component Manager pattern's UML diagram.

1 | 2 | 3 | 4 | 5 | 6 | 7 |  Next >
Resources