Your company decides to build or migrate from existing two-tier applications to an n-tier J2EE solution. The targeted application needs to have characteristics of modularity, reusability, extensibility, portability, inversion of control, consistence, and scalability (MREPICS) (see the sidebar for more on MREPICS principles). Your task: efficiently build a high-quality application leveraging standard J2EE components.
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
Rather than design all the pieces from scratch, you wisely desire to leverage the well-established Gang of Four (GOF) design patterns. The challenge: you must select among two dozen GOF design patterns under a functional taxonomy (creational, structural, and so on) and apply them to J2EE components. Sound tough? In this article, you'll learn how to make the process easier with the E++ language.
E++ makes design patterns friendlier to designers by effectively coordinating patterns in real projects. Different from the GOF's taxonomic approach, the E++ pattern language contains not only design patterns, but also architectural patterns that provide frameworks of the whole application for design patterns. Moreover, it describes the rules for design patterns working together to construct a high-quality J2EE framework. In short, E++ shows how to architect a real-world J2EE project using closely related design patterns.
In the sections below, we will first establish the foundation of the language, then, beginning with the Layered Architecture pattern, describe the whys and how-tos of decomposing the system and partitioning functionalities in different subsystems. Next, the MVC architecture pattern provides a set of patterns for laying out the architecture of an interactive B2C scenario. Further, the REAI (Rule Engine-Based Enterprise Integration) architecture pattern depicts how the application integrates with backend remote systems. A few deployment patterns are also addressed to help deploy applications in production.
Pattern language: A better approach
The first systematic attempt to describe patterns was made by the ancient Greeks, resulting in Aristotelian prepositional logic. Indeed, the heart of today's Pentium processor comprises a complex of prepositional logic patterns, etched into silicon.
The current design pattern movement draws on the work of the architect Christopher Alexander. In A Pattern Language, he suggested that each design pattern, "... is a rule, which establishes a relationship between a context, a system of forces which arises in that context, and a configuration which allows these forces to resolve themselves in that context" (Christopher Alexander, 1977). In an object-oriented programming environment, a pattern indicates a cluster of cooperating objects linked by certain relationships found repeated in a design. Application design is tremendously hard work, and with design patterns existing in isolation and without correlation, it is always a struggle to integrate the patterns into an actual design project.
In order that the knowledge represented by design patterns can be effectively utilized and become part of the collective design knowledge, the patterns have to be structured. The whole set of patterns for a specific application domain, together with their structuring principles, becomes a high-level language and a design method for the domain that accompanies the software life cycle.
For its part, the GOF taxonomy includes categories such as creational and structural, with the patterns presented under these categories. This structure has been followed by most current pattern presentations.
In contrast to the GOF taxonomical approach, we'll look at patterns with a pattern language for creating a J2EE framework with the hope that a pattern approach would be more useful for designers and more understandable for developers.
Again, just as a framework is not a collection of classes, a pattern language is not just a loose collection of patterns. The pattern language provides an organization of the decision sequences that generated the framework design, and these must be understood in their proper context by the developer when making new decisions regarding which classes and collaboration structures to add to the framework.
With that in mind, the E++ pattern language extends previous design pattern work and presents, within the J2EE application context, ideas closer to Alexander's idea of a pattern language as a whole design method.
The electronic commerce problem
In this series, we'll target an application domain that is a Web-based, large-scale B2C and B2B integration framework implemented in J2EE. We'll employ the following business case to illustrate the E++ pattern language.
Telecommunication Service Provider, Inc. (TSP) distributes telecom services to subscribers and resellers. This fictitious company requires a Web-enabled business application to support order creation, provisioning, fulfillment, deletion of orders, and billing information, as seen in Figure 1.
Along with providing interactive applications to handle its orders and billing information, TSP wants to integrate the Web application with backend services to automate processes of order provisioning, fulfillment, and banking services to enhance the application's efficiency. The application needs to access remote services through HTTP/HTTPS, CORBA, and RMI protocols. XML should be supported in the process. As business rules change frequently, the company should be able to modify or update the application at runtime.
An application provider, Telecom Soft Co. (TS), will develop the application for TSP. The application will also be used as the basis for a product sold by TS to other businesses within the telecom distribution industry. TS's goal: create an application that is highly flexible, portable, and easily customizable for other clients. Under such conditions, the application framework must comply with object-oriented design principles and patterns to generate a MREPICS solution.
We'll learn how to solve this problem using the E++ pattern language in the following sections.
The pattern language in detail and practice
The E++ pattern language, as depicted in Figure 2, follows a treelike topology. Each circle denotes a pattern, with arrows representing the relationships among patterns. Architectural patterns are green-colored to indicate the beginning of the language. With E++, building a J2EE framework becomes as easy as following the tree network from the root to the leaves.
The Layered Architecture discusses the whys and how-tos of partitioning application functionality into tiers; it is a general guideline for arranging large-scale applications. In light of the Layered Architecture, the MVC architecture shows that classes and objects of the B2C portion can be effectively organized into three major functionality subsystems: model, view, and control. On the B2B side, the REAI architectural and related design patterns deal with distributed integrations. Before delving into the language details, let us work through the language to show how the patterns work together.
In our scenario, a customer accesses the TSP Website using a Web browser, hits the items of interest, and generates HTTP requests to the Web server, which directs all the requests to the Application Mediator, with the mediator working as a single entry point to the application. To respond to the requests, the mediator dispatches the customer's requests to the JSP Template pattern, which serves as a layout manager and produces all the required JSP/HTML files for the customer's browsing. As the name suggests, the Template Method combines with JSP Tags and JSP Pages to handle the presentation scenario. Following that, it independently forwards the customer's requests to the Event Processor pattern.
If the requests require changing application models, such as ordering, accounting, and billing HTTP requests, the processor interprets the requests to Java events using the Event pattern and then delegates the corresponding tasks to the EJB tier through the EJB Facade by sending these events. The EJB Facade pattern acts as single entry point to the EJBs, as well as controls and synchronizes concurrent access to the EJB layer. Note that the Event pattern is essentially the Java delegation event model, which allows indirect method invocations. The Event pattern has been widely used as a better application control alternative in Java 1.1 and later versions.
The EJB Facade forwards all the events to the EJB Controller, a stateful session EJB representing the customer at the EJB tier. The EJB Controller simplifies the processing and leverages the State Machine pattern to change application state. The machine then uses the Command pattern to fulfill the event processing and create or change the Model EJB or Session EJB Facade. The Model EJB encapsulates business logic, while the Session EJB Facade offers an effective way, in terms of network traffic, to update database tables. The Value Object pattern improves response time to access coarse-grained data, while the Flyweight Object pattern reduces the number of objects in memory. The Data Access Strategy and Connection Factory patterns access relational databases in a flexible and extensible way. Finally, the Data Iterator pattern provides a practical way to fetch large chucks of read-only data. Through these patterns, the application model at the EJB tier is changed or updated.
The Web tier needs to know these model changes and be updated. To accomplish this, Web Model JavaBeans, which serve as mirrors of these Model EJBs, are registered as event listeners so that they are notified as soon as the Model EJB changes. The Event Processor employs the Command pattern to update the JavaBeans, which feeds updated data to JSP pages for customer browsing. JSP pages, one of the standard J2EE Web components for application presentation, retrieves data either directly from the mirror JavaBeans or indirectly through JSP tags in case data looping is necessary.
Note that for read-only access, such as catalog browsing, JSP should access the database through Web JavaBeans and bypass EJBs.
Because some of the customer's events require access to backend remote services, we also must focus on the B2B scenario. The REAI (Rule Engine-based Enterprise Application Integration) architecture pattern acts as the framework for conducting B2B integration services.
The Scheduler pattern initiates B2B requests and executes each specific task as a single thread. The thread uses the Integration Rule Engine to figure out the correct XML schema and backend connectivity. The engine, a stateless EJB, leverages the XML DTD design pattern to design its XML schema. Meanwhile, the XML Transformer pattern transfers one XML schema to another so that the sent XML can be understood by receivers. The engine uses the Security pattern to secure the data transportation if required. Integration business rules are scripts residing outside the rule engine, so they can be changed at runtime by nonprogrammers. The engine then takes action using the Dispatcher pattern to get remote services. The Dispatcher pattern uses the Proxy Adapter, Remote Facade Wrapper, and JMS patterns to establish the actual connectivity. Lastly, the Prototype Reality Bridge pattern describes a seamless development evolution from simulation to reality.
Moving on, the Migration pattern demonstrates how Web-centric applications can be moved to an E++-recommended architecture. The Security pattern addresses security related to Internet-based enterprise solutions including confidentiality, integrity, authentication, and nonrepudiation. The Cluster pattern provides rules about how to deploy the framework in production.
Now let's drill down to the detailed patterns starting with the three architectural patterns: Layered Architecture, MVC, and REAI.
In order to describe the patterns, I'll detail each component within a group with:
- 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
The Architecture pattern
The Architecture pattern expresses a fundamental structure-organization schema for software systems. It provides a set of predefined subsystems, specifies their relationships, and includes rules and guidelines for organizing the relationships among them.
Pattern name: Layered Architecture
You are designing the TSP J2EE application.
How do you arrange application functionality or responsibility among distributed processing contexts to maximize MREPLICS features?