Web and Enterprise Architecture Design Patterns for J2EE, Part 1by Ganesh Prasad, Rajat Taneja and Vikrant Todankar
Editors Note: In this article, the authors propose patterns in the following five categories: Partitioning, Scope, Security, Navigation, and Data Volume Control. Because of space limitations, we have split this article into two pieces (clearly a partitioning problem with impact on navigation). This week, you will read about Partitioning and Scope. Next week, you will find descriptions of the remaining three categories.
Ever since the publication and wildfire popularity of Design Patterns by the "Gang of Four" (Gamma, Helms, Johnson, and Vlissides), software industry professionals have gained a powerful new approach to design. A design pattern, by their definition, "describes the core of a problem that occurs over and over again, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice." In general, a design pattern has four essential elements: a name, the problem it aims to solve, the elements of the solution, and the consequences (results and trade-offs) of using the pattern.
Design patterns described in GoF, such as Factory Method, Observer, Facade, etc., have become familiar motifs of the modern application design landscape. As presciently stated by the authors, design patterns perform as important a function by merely naming as by describing and analyzing. Who can estimate the number of person-hours saved in design meetings by the use of pattern names rather than their tedious descriptions?
Seven years after the book was published, we find that design patterns are as relevant as ever. However, later design patterns introduced by other authors seem to add less and less to the value of the collection initially offered by GoF. By way of proof, none has achieved the popularity or name recognition of the initial 23 patterns. To borrow a term from Economics, then, we might say that the marginal utility of newer patterns seems to be approaching zero. So is the "science" of design patterns nothing more than a static collection of one-off insights?
On the contrary; from our own experience as web-era application designers, we see a repetition of history (a pattern, if you will) in the fact that there is an unfulfilled need for a set of named ways of doing things at the level of an application or subsystem, in the same manner that the original design patterns fulfilled a need for standardization of lower-level functionality.
Nothing of what we will talk about in the following sections is really new. They are simple, standard, common-sense ways of doing things that most experienced developers know about and have themselves used. But in the style of the original set of design patterns, we will classify and name these obvious banalities (in addition to describing them), in the hope that the names themselves will prove to have evocative value by vividly capturing the essence of their functionality. We call these "Web and Enterprise Architecture Design Patterns," a grandiose name for design patterns at the next level of application granularity.
Being committed J2EE practitioners, we will restrict ourselves to covering Java-related problems
and solutions, though many of the concepts may be applicable to other technologies
as well. (Shouldn't design patterns be language-independent? That's an attractive idea,
but one could argue that GoF patterns such as Abstract Factory and Prototype,
while useful in C++ and SmallTalk, are redundant in Java, because the
class and Java's reflection mechanism solve such problems very elegantly.)
The Care and Taxonomy of WEA Design Patterns
Recall that the GoF design patterns fell into three neat categories that made them easier to understand and remember -- Creational, Structural, and Behavioral.
Following in this hallowed tradition, we propose to divide our patterns into Partitioning, Scope, Security, Navigation, and Data Volume Control categories. This is by no means an exhaustive list, but merely a set of pattern types we felt would be appropriate as a starting point.
Description of Patterns
We roughly follow the structure established by GoF to describe our patterns, but in the interests of brevity, we have collapsed the treatment into three broad headings. Under "Intent," we state the intended use of the pattern in a single line. We describe both the problem and the outline solution under a single heading "Problem and Solution." Then we briefly discuss the positive and negative consequences of the pattern under "Consequences."
We have omitted UML class diagrams, again in the interests of brevity. The patterns are generally simple enough not to require such detailed illustration. We have also omitted Java code examples. We are sure most J2EE developers can understand the patterns and "roll their own."
1. Dumb Client
To implement application logic with no support from the client (browser).
Problem and Solution
The positive consequence of choosing a Dumb Client design pattern is an application that can work with almost any browser, including very old ones. It can support extremely security-conscious users who do not allow client-side scripting.
The negative consequences of this pattern are an increased level of network traffic and increased load on the server. This can have an adverse impact on performance, though the exact impact will need to be assessed on a case-by-case basis. Besides, several actions now become clumsier and less natural when they are not performed locally, making the application less interactive and friendly.
2. Independent Client
To implement the most interactive interface, leveraging client- and server-side processing capability.
Problem and Solution
The positive consequence of the Independent Client pattern is an application with a more natural and intuitive feel. Most processing that can be done without server intervention is performed locally with consequent good response times. Network traffic is kept to the minimum and the load on the server is minimized.
3. Server-Modified Client
To provide high levels of client-side interactivity through smart server-side processing.
Problem and Solution
The positive consequence of the Server-Modified Client pattern is the achievement of interactivity without redundancy. It is now possible to control both client- and server-side logic from a single location. Anomalous behavior of the two tiers can be reduced or eliminated.
Pages: 1, 2