OJ11625.

qxd 3/11/04 6:48 AM Page 1

W H I T E P A P E R Implementing Sun Microsystems

Core J2EE Patterns

Introduction

John Crupi
Distinguished Engineer
Chief Java Architect
Sun Microsystems
Sun Microsystems core J2EE design patterns are drawn from proven,
prior experience. They are full of wisdom and best practices that work to
make developers lives easier. OptimalJ is Compuwares model-driven,
pattern-based J2EE development environment and it implements Suns
core J2EE design patterns. Sun has validated this implementation:
The way how OptimalJ works and makes use of patterns is impressive
All patterns in the reviewed version of OptimalJ are implemented correctly
in compliance with the Sun J2EE Pattern Catalog.

Frank Baerveldt In the real world, you need more than reliable designs; OptimalJ will
Director of Software Architecture
Compuware Corporation take you from a reliable design to a reliable implementation.

CompuwareCorporation
OJ11625.qxd 3/11/04 6:48 AM Page 2

An introduction to Compuware OptimalJ

J2EE technology provides a rich set of functionality and features for

developing enterprise applications. However, J2EE requires significant
knowledge and is not for the faint-hearted. Enterprise platforms are inherently
complex, slowing down advanced Java developers and creating a barrier to
entry for many mainstream developers. There is a critical shortage of
advanced Java developers, and especially Java developers with experience
in Enterprise Java Beans (EJBs), which slows time-to-market for business
applications and challenges application reliability and performance.

The ideal solution would be to simplify Java development, making it possible

for developers of all skill levels to build reliable, high-performance
components. Compuware OptimalJ is such a solution because it provides
developers with a framework for delivering J2EE-compliant business
applications.

OptimalJ is a new breed of advanced development environment that

enables the rapid design, development, modification and deployment of J2EE
business applications. OptimalJ is an MDA-based1 development environment
that uniquely blends models, patterns and application frameworks. It is
based on open industry standards, recognized best practices for software
development and sound technical architecture based on Sun Microsystems
core J2EE patterns.

The core best practices embraced by OptimalJ are:

Separation of Concerns: The Business Model (a domain layer) is key to
capturing the crucial aspects of what the application is to deliver to the
end user.
Dual Architecture: The ability to model the application architecture
(user features) separate from the technical architecture (plumbing) and
have the tool perform the tedious weaving of the two together to form
a working application.

1 Model Driven Architecture (MDA) is an Object Management Group standard for model-
based application architectures.

2
OJ11625.qxd 3/11/04 6:48 AM Page 3

Agile Development: The ability to support iterative development by making

it easy to quickly do some modeling and then run the JSP-based
application to test the model.
The benefits of this approach include:
reduced total cost of ownership
reduced development time
emphasis on the business and achieving business agility
improved application quality
increased return on IT investments
rapid inclusion of emerging technologies.
OptimalJ generates complete, working applications directly from a visual
model, using active synchronization to keep both model and code in sync
during application development iterations. It includes a built-in web server
and servlet engine, J2EE application server and DBMS for making the out of
the box experience complete. This stand-alone capability allows developers
to fully test their portion of the application before checking in the code. For
production purposes, OptimalJ generates archive packages and server
deployment descriptors automatically, allowing application administrators
to rapidly deploy in the target environment.

This document describes the use of patterns in an MDA setting in general

and, specifically, the use of Suns Core J2EE patterns in OptimalJ.

3
OJ11625.qxd 3/11/04 6:48 AM Page 4

A pattern is a common solution
to a common recurring problem
in a given context.3
Patterns in general
Traditional application development, using 3GL languages, consists of writing
a number of source code files. This is a long and tedious process, requiring
hard coding of every single line of code. With the introduction of the object-
oriented programming paradigm, a major productivity improvement has been
achieved because of the ability to reuse and refine recurring components
throughout applications. Integrated Development Environment (IDE) vendors
address this development behavior by providing a set of templates, as the basis
for development of new components.

The next step in this pragmatic approach to programming is the use

of patterns; a literary form of software engineering2 based on a proven
architecture and generally accepted solutions for programming problems.
In using the term pattern the reference is to Design Patterns. Unlike Code
Patterns, which are reusable pieces of code, Design Patterns capture specific
knowledge about architectures, platforms and technologies to help create
reusable code.

Patterns make it possible to capture and describe problems and their

related solutions so that they can be reused. Patterns describe, at some level
of abstraction, an expert solution to a problem. Patterns capture knowledge
and expertise. In a knowledge-intensive society, patterns are a key asset.
Knowledge is the thing that makes or breaks a project. It is the cornerstone
of building successful systems. The use of patterns in software development
offers significant benefits:

Successive usage of the same pattern for different components in different

applications reduces the learning curve considerably, because patterns
capture knowledge and expertise.
The reusable, application-independent components shield developers
from most of the low-level coding details. These low-level details are
often tedious to implement from scratch. Patterns eliminate a considerable
amount of development time when creating components.
Patterns use consistent and high-quality code, which has been pre-tested
and is therefore more reliable.
When compared to programming, patterns can best be described as design
templates coupled to programming logic. This logic determines which
templates are used and the way they are used to implement components,
2 Literary software engineering is a methodology that combines a programming language with
a documentation language, thereby making programs more robust, more portable, more easily
maintained, and arguably more fun to write than programs that are written only in a high-
level language. The main idea is to treat a program as a piece of literature, addressed to
human beings rather than to a computer. Knuth, Donald E., CSLI Lecture notes, no. 27
(Stanford, California: Center for the Study of Language and Information, 1992), xvi+368pp.
3 Booch, Grady, James Rumbaugh and Ivar Jacobson, Unified Modeling Language User Guide,
The: The Addison-Wesley Object Technology Series, (New York: Addison-Wesley), 1998.
4
OJ11625.qxd 3/11/04 6:48 AM Page 5

depending on the model definitions. Referring to OptimalJ, EJBs are good

examples of this concept. For example, an Entity Bean consists of several
separate Java classes. Patterns are used to determine which classes are
necessary and, based on that information, to actually implement these
classes through the use of templates.

Pattern usage in MDA and OptimalJ

OptimalJ is an implementation of Model Driven Architecture (MDA) and
adds a pattern-driven development paradigm on top of the MDA concepts.
In contrast to other tools, OptimalJ does not provide isolated pattern
implementations, but blends and embeds the patterns into a complete and
consistent application framework. This enables OptimalJ to automatically
generate working applications, ready for deployment.

OptimalJ categorizes patterns according to their usage in the MDA concepts.

It is important to note that all OptimalJ patterns adhere to recognized best
practices, such as Suns core J2EE patterns.

OMGs Model Driven Architecture and OptimalJ patterns

OptimalJ was one of the first products to be based on the Model
Driven Architecture as defined by the Object Management Group
(http://www.omg.org/mda). MDA relates to the Unified Modeling Language
(UML) like J2EE relates to Java, or .NET to C#. In these cases, a language
is used to implement application architectures.

Platform
I ndepen d e n t
Model

Platform
Specific Model

Code Model

Figure 1: Model Driven Architecture

5
OJ11625.qxd 3/11/04 6:49 AM Page 6

MDA is a software architecture based on modeling at different levels.

MDA specifications are based on a Platform Independent Model (PIM)
of an applications business functions. The PIM expresses an applications
fundamental business functionality and behavior in a platform-independent
way. MDA-enabled tools allow the definition of a Platform Specific Model
(PSM) for a certain target platform (i.e., J2EE) from the same base-PIM and
then, in a subsequent step, generate an implementation in a specific language
(i.e., Java) on that platform from the PSM. This approach allows a software
environment to evolve and change, but the PIM remains stable. A company
needs such a stable base to cope with its constantly changing environment.

OptimalJ implements the MDA concepts by adding patterns to the models in

order to do model-to-model transformations (PIM->PSM) and model-to-code
transformations (PSM->Code). This pattern-based development paradigm
enables OptimalJ to automatically generate working applications, ready
for deployment.

All higher-level models are Meta Object Facility (MOF)-based (OMG

standard), while the Implementation Model is based on standard Java classes.
MOF is a meta language for describing, representing and manipulating meta
information (data describing data). UML, for example, is defined in MOF.
It defines a meta model of an object-oriented application.

OptimalJ model architecture

As with MDA, OptimalJ provides a clear distinction between the models
and the implementation of application components. The models in
OptimalJ have different abstraction levels:

Figure 2

6
OJ11625.qxd 3/11/04 6:49 AM Page 7

The Domain Model defines the business domains without any specific
application detail.
The Application Model defines the application, based on a certain
technology, but without any coding detail (there is no implementation
yet). The Application Model describes what is to be generated to
implement the application, by providing a logical overview of the
components contained within each layer that makes up the application.
For example, the DBMS layer contains a relational data framework that
consists of tables, columns, keys and other database-related elements. The
EJB layer consists of Entity Components, Data schemas, Key classes and
other EJB-related components. The web layer contains Data schemas,
which are used by web components to exchange data with the EJB layer
on one end and the user at the other end.
The Code Model defines the application actually implemented in code.

Figure 3

7
OJ11625.qxd 3/11/04 6:49 AM Page 8

Figure 4

Once the Application Model is in place for the DBMS, EJB and web layer,
the code implementations of defined components can be generated (i.e.,
the Java classes, SQL scripts and other technical items that are needed
for the components in the models).
A designer/business analyst will create the Domain Model in OptimalJ. Based
on this Domain Model, OptimalJ will automatically generate the Application
Model and the Code Model, using so-called Transformation Patterns, which
are explained in the following paragraphs.

OptimalJ pattern types

OptimalJ uses many types of patterns and frameworks to create fully
implemented components resulting in a working application. After defining
the Domain Model4 and the declarative section of the Business Rules
definitions5, OptimalJ uses the pattern-driven generator to rapidly create
an application according to Suns core J2EE patterns. Patterns are also used
to create the implementation classes in the presentation, business logic and
persistency layers. Patterns are used throughout the product for various
purposes, which are determined by the logic embedded in the patterns.

OptimalJ makes a distinction between Transformation Patterns and

Functional Patterns. Transformation Patterns are used to map elements
from one model to elements in a lower-level model. Transformation patterns
can be divided into:

Technology Patterns
Implementation Patterns.

4 see Compuware white paper, Compuware OptimalJ Model Driven Development

5 see Compuware white paper, Compuware OptimalJ Business Rules

8
OJ11625.qxd 3/11/04 6:49 AM Page 9

Functional Patterns are used to map elements at one model level.

Functional Patterns are divided into:

Domain Patterns
Application Patterns
Code Patterns.

Figure 5

Transformation Patterns
Transformation Patterns are used to transform the elements of one model into
elements in a lower-level model. A good example of a Transformation Pattern
is the transformation of component definitions into the actual source code
that implements that component.

OptimalJ uses two Transformation Pattern categories:

Technology Patterns map business specifications to application level for

a specific technology and application architecture. In OptimalJ, J2EE is
the specific technology used and therefore J2EE patterns are primarily used.
Technology Patterns are used for bridging abstraction levels (Domain Model
to Application Model) and they do not generate Java code.
Implementation Patterns map application specifications to code. In
OptimalJ, Java, JSPs, XML and SQL are used as specific implementation
languages. OptimalJ uses patterns to determine the Java classes needed to
implement the components. Several interdependent classes are necessary,
so the pattern-driven generator uses advanced logic to derive the necessary
classes from the models. For example, for each individual Enterprise Java
Bean, numerous Java classes are automatically generated, such as a Primary
Key Class, a Home Interface, a Remote Interface and a Browse Class. The
hierarchy of patterns is determined by the logic built into the patterns.
Another example of Implementation Patterns is the generation of DBMS
layer components. OptimalJ generates SQL scripts for creating, emptying

9
OJ11625.qxd 3/11/04 6:49 AM Page 10

and deleting database tables. Next to that, the automatic generation of

deployment descriptors for the J2EE application servers is an important
element of database functionality. OptimalJ uses patterns to generate
deployment descriptors, which include the SQL statements needed to
query the database.
Implementation Patterns are used to translate formats. A specific pattern-
template language (XTPL6) is used for this translation, which is geared for
translating MOF-based models to syntax-based languages.
One very important characteristic of Transformation Patterns is their
incremental support. Transformation Patterns map a source model to a target
model. OptimalJ allows the developer to manually enhance/refine the
target. When re-applying the Transformation Patterns, manual changes in
the target are preserved.

In addition, OptimalJ generates code based on Suns Core J2EE Patterns,

adhering to the de facto design standard and not a proprietary
implementation.

Pattern-driven generation, in combination with incremental support, makes

OptimalJ a very productive environment to develop fully functional and
working J2EE applications in an iterative way.

Functional Patterns
Functional Patterns are used to increase productivity by reusing parts of
models at a single model level. This way, people can build a library of sub-
models that can be reused in other projects. The unique feature of OptimalJ
is that multiple sub-models (source) can be woven into a new model (target).
The concept of model weaving is based on Roles and Inheritance. This gives
the user maximum flexibility in merging Classes and maintaining/controlling
changes in the model hierarchy. There are three types of Functional Patterns,
which are targeted to solution reuses:

Domain Patterns are used on the Domain Model level. A Domain Pattern
is a Domain (UML-class) Model that can be reused. A new target Domain
Model can be constructed by merging Domain Patterns from Domain
Pattern libraries. In this way a new Domain Model can be rapidly
constructed based on existing knowledge, like a set of building blocks.
Domain Patterns are always application- and implementation-independent.
An example of the application of a Domain Pattern is the merging of
two existing Domain Models (for example: The Contract Model and the
6 XTPL (eXtended Template Pattern Language) is geared to translate MOF-based models to
syntax-based languages. This language is currently used for generating Java, JSP, XML and
SQL from the MOF-based application model. The XTPL compiler compiles a TPL (Template
Pattern Language) script into plain Java classes. These Java classes take an MOF model as
input and generate, for example, XML documents (deployment descriptors) as output.

10
OJ11625.qxd 3/11/04 6:49 AM Page 11

Customer Model) into one new Domain Model. By default, all elements of
the Domain Pattern are copied to new elements in the target model. But it
is also possible to assign an element from the existing model to an element
in the pattern. When the pattern is copied, the element from the pattern
is merged with the element in the target model. This technique is called
pattern weaving, extended with some new attributes. Note that the link
to the original sources is maintained, allowing later changes to the sources
to be propagated to the merged target.
Application Patterns are used on the Application Model level. Application
Patterns follow the same principle as Domain Patterns, however, now
applied to Application Models.
Code Patterns are used on the Code Model level and they describe
implementation strategies. Code Patterns are used to create code that is
not directly related to the component definitions in the Application Model.
OptimalJ provides a wizard-driven 3GL template mechanism to reuse Java
implementation strategies. An example of such an implementation strategy
is the set of patterns described by the Gang of Four (GoF patterns, such as
ChainOfResponsibility, Decorator, FactoryMethod, etc).7
Code Patterns are closest to the traditional use of templates, as they
directly result in the creation of one or a few class files with pre-defined
programming structures. The developer has to extend these programming
structures to implement the desired functionality. Code Patterns are applied
using Wizards that request the required parameters from the user.

OptimalJ code application architecture framework

The architecture of an OptimalJ application on code level consists of
three parts:

a set of generic application frameworks (pre-installed)

a dynamic, specific application framework that is generated from the
Application Models via Implementation Patterns (generated code)
code that is manually added by a Java developer.
The set of static, generic application frameworks can be used for any
application. It contains well-known frameworks, such as Struts for the
web layer.

OptimalJs primary framework is called Altura and contains generic

helper classes, abstract classes and interfaces. Pattern implementations that
are generic (such as Suns Core J2EE Service Locator pattern) are part of
this framework.

7 Gamma, Erich, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements
of Reusable Object-Oriented Software, (New York: Addison-Wesley) 1994. The authors are
collectively known as the Gang of Four (GoF).

11
OJ11625.qxd 3/11/04 6:49 AM Page 12

The sources of static frameworks are available and ready-to-use because they
are preinstalled as Jar files. In short, the Altura framework provides utility
and ease-of-use classes. It doesnt affect the way custom code is added.

The dynamic application framework is application-specific. In other words,

classes in the dynamic framework refer directly to domain-specific concepts,
such as Customer and Order.

The dynamic framework is generated from Application Models, using

Implementation Patterns. The dynamic framework inherits from and uses the
static frameworks and typically is exposed as guarded blocks (non-editable)
code to the developer.

Finally, custom business logic needs to be written. This code can be inserted
into the application framework via free blocks (editable). In the free blocks,
classes from the generic and specific framework can be used.

Application Models Language

editor

Pattern-driven generator Manual editing

Pre-installed Manual
code

Dynamic framework

Generic framework

Figure 6

12
OJ11625.qxd 3/11/04 6:49 AM Page 13

Core J2EE Patterns OptimalJ Application Implemented in

Framework OptimalJ using

Presentation Layer

Intercepting Filter Dynamic AF Struts

Front Controller Dynamic AF Struts

View Helper Dynamic AF Struts

Composite View Dynamic AF JSP templates and Includes

Service To Worker Dynamic AF Struts

Business Layer

Business Delegate Dynamic AF Business Faade

Service Locator Generic AF Helper class

Session Faade Dynamic AF Business Faade

Transfer Object Dynamic AF DataClass

Object Assembler Dynamic AF Compound DataClass

Value List Handler Dynamic AF Page Iterator

Composite Entity Dynamic AF Composite Entity Bean

Integration Layer

Data Access Object Dynamic AF DAO

Service Activator Dynamic AF Message-driven Bean

OptimalJ pluggable patterns

OptimalJ is shipped with best-of-breed Application Models, Patterns and
application frameworks (including Suns core J2EE patterns). OptimalJ
is also fully customizable. The OptimalJ Architecture Edition provides
the functionality to plug in new models and patterns (Technology and
Implementation Patterns). Models and patterns can be customized and
new models and patterns can be added.

This enables a company to be fully in control of the application framework

it uses and it can define its preferred application framework (static and
dynamic). Companies can set up their own software factory by designing
and tailoring models and patterns to their specific needs.

13
OJ11625.qxd 3/11/04 6:49 AM Page 14

OptimalJ pattern concepts

OptimalJ application architecture

Presentation layer in a nutshell

The web components are using a Model-View-Control (MVC) concept.
This splits out page layout, navigation logic and actual data access.

The MVC web component scenario works as follows:

The Controller (Front Controller Servlet) receives HTTP Requests and

dispatches these Requests to Actions. In addition, the Request parameters
are stored in a Form Bean (Context Object) for easy access (get/set methods).
These Actions handle the Request by, for example, calling the Business
Faade (Session Faade) or accessing an Update Object (Transfer Object).
Actions may add extra request attributes to the Request. The Action returns
with failure or success to the Controller. Based on the result, the Controller
passes the request to a JSP. The JSP builds a page by accessing
the Update Object for data.

Thus the navigation between pages is fully handled by the Controller. The
navigation, however, is not hard-coded in the Controller, but is stored in a
separate XML configuration file.

This concept is based on the Struts framework from Apache.

Request Servlet

Controller Ref

Action
JavaBean
XML
JavaServer conf
Page

Ref
Data

Update Business Servlet

Figure 7: Model View
Object Faade
Controller Concept

Data

14
OJ11625.qxd 3/11/04 6:49 AM Page 15

Business Logic layer in a nutshell

Business layer components use coarse-grain communication to limit
communication overhead.

Session Beans (Session Faade) are used as Task components. A Session Bean
can handle a business transaction or a query that spans multiple Entity Beans
(Composite Entity). Session Beans are also used to guard task integrity. The
majority of the task integrity rules are owned by the Session Beans.

Entity Beans are used as persistency components (an alternative is the use
of DAOs). Entity Beans are also used to guard data integrity. The majority
of the data integrity rules are owned by Entity Beans. The clients of the EJB
components, most notably the web layer, communicate coarse grain with these
components. Since these layers may very well be connected via a network,
network traffic is optimized this way. However, the clients need an easy way
to manipulate these coarse grain components.

: controller : retrieve : maintain : maintain : update : store : business

: EJB
Servlet Action Action JSP Action Action Faade
: User

request
perform( )
retrieve( )

forward getObject( )

object

perform( )

setObject( )
forward
perform( )
getObject( )
Html

request

perform( )

update( )

forward

perform( )

store( )

setObject( )

Figure 8

15
OJ11625.qxd 3/11/04 6:49 AM Page 16

Therefore, OptimalJ offers a fine-grain interface to these coarse-grain

components by means of the Business Faade/Update Object (Transfer
Object) concept. Although the Business Faade runs on the web layer, the
Business Faade interface is considered part of the Business Logic layer. The
Create, Retrieve, Update, Delete (CRUD) pattern uses the Update Object
scenario as follows:

the Client (e.g., web components) asks a Business Faade to retrieve a

Data Object (e.g., Customer)
the Business Faade gets a (read-only) Data Object from an EJB component
and converts the Data Object to an Update Object (an Update Object can
be regarded as an Updateable Data Object)
after the Update Object is changed, the Client asks the Business Faade
to store the Update Object
before setting the Update Object to the EJB component, an extra
optimization (Prune) is performed by the Business Faade, removing all
the non-changed data from the Update Object
the Update Object is then sent to the EJB component.
The Business Logic layer uses the concept of modules to partition an
application. Modules are shipped as Jars and are reusable. Communication
within a module is considered local (uses local interfaces). Outside the
module, remote interfaces are used.

OptimalJ pattern concepts

Coarse grain communication

The OptimalJ Component Based Development (CBD) approach uses
coarse-grain communication between components.

Fine-grain communication would introduce too much overhead in a

distributed, transaction-oriented environment.

An OptimalJ component has two features: Methods and Attributes.

The component offers these features as a service to its client; in other
words, the features are served by the component.

Instead of getting and setting attributes of a primitive type, such an attribute

(that is exchanged between components) has a class-type. The attribute is
called a serving attribute; such a class is called a DataClass, which is defined
by a package called a DataSchema.

a.k.a: Transfer Object, producer/consumer.

16
OJ11625.qxd 3/11/04 6:49 AM Page 17

Compound Dataclasses
An Attribute that is being served by the component can be derived
(read/write). A pre-defined business rule Assembly exists that assembles this
compound Dataclass from primitive Dataclasses, served by other components
and vice versa.

a.k.a: Transfer Object assembler.

Entity Beans as persistency and data integrity components

In OptimalJ, Entity Beans are used as persistency components. By default,
each business class that is not a part will be represented by an Entity Bean.
If a business class is a composition (aggregation=composite), the Entity Bean
will also hold its parts. For regular Entity Beans, CMP is used. In a compound
Entity Bean, the parts are managed via BMP.

In OptimalJ, Entity Beans are also used to guard data integrity. The majority
of the data integrity rules are owned by the Entity Beans.

a.k.a: Composite Entity.

Session Beans as Task and Task Integrity components

In OptimalJ, Session Beans are used as Business Task components. A Session
Bean represents each Business Task. A Session Bean can handle a business
transaction or a query that spans multiple Entity Beans. By default, stateless
Session Beans are used.

In OptimalJ, Session Beans are also used to guard task integrity. The majority
of the activity integrity rules are owned by the Session Beans.

a.k.a: Session Faade.

Attributes versus get/set operations

Although attributes are used in the Application Model, at code level the
attributes are always accessed via get/set methods.

Since the components use a coarse grain communication pattern, the get/set
methods in components handle compound objects.

Update objects and Business Faade

Typically, components in the web tier communicate with the coarse-grained
EJB components. Since the communication to the EJB components may be
over the network, OptimalJ optimizes the network calls. However, the clients
need an easy way to manipulate these coarse-grain components. Therefore,
OptimalJ offers a fine-grain interface to these coarse-grain components by
means of the Business Faade/Update Object concept.

17
OJ11625.qxd 3/11/04 6:49 AM Page 18

For each EJB, a Business Faade is created that provides easy access to the
corresponding Bean. The Business Faade resides on the web-layer and
provides access to the EJB layer (explaining the term remote). The
Business Faade serves the following purposes:

provides fine-grain access to the coarse-grain Data Objects in the

EJB interface
handles transaction state for stateless Session Beans
implements an advanced Transfer Object pattern
supports Application Patterns like CRUD and Invoker patterns
handles collections of Entity Beans in absence of a Session Bean
handles transactions in absence of a Session Bean.
In short, the Business Faade controls all communication with the EJB layer
and manages all Update Objects. The Update Objects offer an easy fine-grain
interface for Object manipulation. The Business Faade runs on the client tier
and can be used by, for example, any presentation tier.

a.k.a: Business delegate, Transfer Object.

Page Iterator
The OptimalJ Page Iterator accesses a Data Access Object (DAO) to execute
a query and stores the result-set. The client of the Page Iterator can request
chunks of data as needed.

a.k.a: Value List Handler.

Data Access Objects

The OptimalJ DAO pattern serves three goals:

enables the construction of two layer applications (web and DBMS)

that support CRUD functionality directly on the DBMS
enables fast-lane access for large amounts of data
encapsulates physical data access to a particular data source.
The DAO pattern produces DAO components, which support CRUD
functionality on the DBMS. Client components can access DAO components
using the same Business Faade interface as for EJB components.

Maintenance Pattern
The Maintenance (a.k.a CRUD) Pattern is the OptimalJ default pattern. It is
by far the most used pattern in administrative business applications, since the
CRUD represents the most common actions on data. For an average business

18
OJ11625.qxd 3/11/04 6:49 AM Page 19

application, 60 percent of the code deals with data maintenance, 20 percent

of the code deals with other patterns (e.g., processes) and 20 percent of the
code implements business rules.

In essence, the common protocol for CRUD is 1) retrieval, 2) update and

3) storage. The CRUD pattern is really a family of data-maintenance patterns
that can maintain complex, nested data structures; 1-n, n-1 and n-m
structures, which are supported by both value and by reference. For the
CRUD pattern, optimistic locking is supported. CRC-checks are used to
implement this.

a.k.a: CRC.

Invoker Patterns
While the CRUD pattern deals with data maintenance, the Invoker Pattern
handles transactions.

The Invoker Pattern is used to create components that invoke the serving
methods of transaction components. OptimalJ provides connectors to external
systems such as CORBA, CICS and similar integration technologies. These
connectors are based on the Java Connector Architecture (JCA). OptimalJ
uses the Invoker Pattern to generate integration components, based on the
imported interface definitions of these services.

Sun J2EE pattern implementation in OptimalJ

This section outlines the findings of Sun Microsystems J2EE pattern
validation of OptimalJ V3.0s implementation of Suns core J2EE patterns.
The findings confirm that the usage/implementation of all used patterns is
compliant with Suns J2EE Pattern Catalog, and therefore is not mentioned
with each pattern.

Intercepting Filter
In the generated web application, the Intercepting Filter pattern is used to
set the correct character set encoding in the HTTP response. This is done
via filters as defined in section SRV.6 of the Servlet 2.3 specification.

Front Controller
In the generated web application, Jakarta-Apaches Struts (v1.0.1) is used,
which implements the Front Controller.

View Helper
This pattern is also supplied by Struts, in the form of taglibs and Form Beans.

19
OJ11625.qxd 3/11/04 6:49 AM Page 20

Composite View
This pattern is used for the JSP generation. There are multiple options for
JSP generation. Two of them are JSP Template, which generates JSPs using
Struts taglibs, and JSP Include, which generates JSPs using JSP Includes.

Service to Worker
This pattern is used for the web application. Basically, it is implemented using
Struts (Front Controller + Actions) and the Business Faade (or Business
Delegate in J2EE terminology).

Dispatcher View
This pattern is not implemented because Service to Worker is being used
and these two patterns are mutually exclusive. Given this situation, it is a
valid choice to use Service to Worker in favor of Dispatcher View.

Business Delegate
This pattern is used to generate a Business Delegate for each EJB and DAO
in the Application Model. The interface of the Business Delegate is the same
for both the EJB and DAO implementation. This Business Delegate can keep
track of the state (stateful) when the backend (i.e., Session Bean) does not
support state (stateless).

Session Faade
This pattern is used in the mapping from the Domain Model to a
Session Bean.

Service Locator
For this pattern, a generic (static) implementation is supplied in the altura-
lib. The service locator is being used to get access to EJBs, queues and topics.

Transfer Object
For every data structure that can be generated from domain classes and
domain views in domain services, a transfer object is generated.

Transfer Object Assembler

This pattern is used when a Session component has a serving attribute.

Value List Handler

The implementation of this pattern can be found in the DAOs (a paged DB
query is available) and EJBs (where there is a postponed findAll()).

Composite Entity
This pattern can be found in the EJB 2.0 generation (local interfaces and
Container Managed Relations). It can also be found in the EJB with Bean
Managed Persistence generation, when aggregation is being used.

20
OJ11625.qxd 3/11/04 6:49 AM Page 21
Compuware products
and professional services
delivering quality
applications
Compuware is a leading global
provider of software products
and professional services which
IT organizations use to develop,
integrate, test and manage the
performance of the applications
that drive their businesses. Our
software products help optimize
every step in the application life
cyclefrom defining requirements
to supporting production service
levelsfor web, distributed and
mainframe platforms. Our services
professionals work at customer
sites around the world, sharing
their real-world perspective and
experience to deliver an
integrated, reliable solution.
Please contact us to learn more
about how our comprehensive
solutions can help your organization
improve productivity, create higher
quality applications and ensure
performance in production.
All Compuware products and services listed within are
trademarks or registered trademarks of Compuware
Corporation. Java and all Java-based marks are trademarks
or registered trademarks of Sun Microsystems, Inc. in the
United States and other countries. All other company or
product names are trademarks of their respective owners.
2004 Compuware Corporation
3/04
DAO
The DAO pattern is used as an alternative to Entity Beans. The end user
has the choice to select per component how it should be modeled in the
Application Model.
Service Activator
This pattern is used when EJB 2.0 Message-driven Beans are generated. These
Message-driven Beans implement the Service Activator pattern.
Mediator View
Although this is not a specific J2EE pattern, it is available in Struts as the
Controller/Action.
Other J2EE patterns
The Synchronizer Token, which protects against double submits, is being
used. Struts provides the framework for this pattern.
Conclusion
The way in which OptimalJ makes use of patterns is impressive. Although
the patterns are not directly visible to the end user, they make the generated
code easy to understand. All patterns in the reviewed version of OptimalJ
are implemented correctly in compliance with Suns Core J2EE
Pattern Catalog.
John Crupi
Sun Mircosystems
Crupi is a Sun Distinguished Engineer. He is the Chief Architect of Sun
Software Services and manages the Pattern and Design Capture Expertise
Center. He has over 17 years of experience in distributed object computing and
remains focused on creating reusable, scalable J2EE architectures and bringing
patterns to the next level.
Frank Baerveldt
Compuware
Baerveldt is Director of Software Architecture at Compuwares Application
Development and Integration Centre in Amsterdam, the Netherlands. He is
responsible for driving the core architecture of Compuwares Java development
and integration solution, Compuware OptimalJ, to ensure that new
development concepts are continuously applied, such as models, patterns and
supported application architectures. He has worked for the company for over
10 years, primarily focusing on delivering productive, adaptable technology
solutions. Baerveldt is Compuwares J2EE application architecture expert,
specializing in meta-modeling and pattern-based development. He holds a
Computer Sciences degree from the University of Delft.
21
OJ11625.qxd 3/11/04 6:49 AM Page 22

Appendix A: OptimalJ application pattern catalog summary

MVC front-end
Intent
Separate presentation aspects, navigation aspects, request dispatch, and
handling and application data aspects.

Motivation
If the aspects above are separated, each can be changed independently of
each other. Also, reuse of these aspects is greatly simplified.

Structure/participants
Request
Request from the user with request info
Dispatcher
Dispatches the request to the action-handlers
Dispatching is done via a dispatch table that is changeable at runtime
Dispatch table
Holds the mapping/routing info from the request to the action-handler
and the responder
The destination (action-handler/responder) depends on the source
(action-handler) and the result code
Action-handler
Handles the request fully or partially and may forward the request via the
dispatcher to another action-handler or responder
The action-handler handles the logic
Responder
Handles the request from the action-handler and creates a response
The responder handles the presentation layout
Response
Responds with response info to the user
Consequences
The dispatch table isolates the navigation between presentations (responses)
The presentation is isolated from the logic
A central dispatcher handles all user requests
Related patterns
The well-known Model-View-Control pattern is closely related to this pattern.

Known usage
This pattern is defined and implemented in the Struts framework in the
Apache project and is freely available under the Apache license.

22
OJ11625.qxd 3/11/04 6:49 AM Page 23

Coarse-grain communication

Intent
Enable component assembly for enterprise-level components.

Motivation
Reuse of components is very important. To be able to reuse components,
one needs to know which services are offered/served by the component
and which services are required/used by the component.

A component will offer an action-service via its methods. A component

will offer data services via its public attributes. For enterprise-level
components, these attributes usually will be of a composite type,
because of performance issues.

Structure/participants
Component
Provides methods and public attributes to other components
Methods
Have a name, input/output/return parameters and exceptions
Offer an action service
Use methods of other components
Parameters
Types: Input/output/return
Data types can be primitive or composite
Mapped to parameters of used methods
Attributes
Offer a data service
Data types are composite
Use attributes of other components
Consequences
Enabling of component assembly
Overview of component dependency
Decoupling of component specification and component implementation
Related patterns
The well-known producer/consumer pattern is more or less related.

23
OJ11625.qxd 3/11/04 6:49 AM Page 24

Business data integrity

Intent
To separate data integrity definition from data integrity implementation.
This is a central place to define data integrity.

Motivation
Data integrity is critical to businesses. Sometimes data integrity is defined
in the database, introducing business-critical dependencies on an
implementation layer. It will be hardly possible to change databases.
Sometimes data integrity is defined on the user interface level, which is
a problem when other user interfaces are introduced.

By defining data integrity on a business data layer, the data integrity

is centrally defined in an implementation-independent way.

Structure/participants
Domain class
A data entity in the business domain
Holds domain attributes
Has domain associations with other domain classes
Domain association
Defines referential integrity (RI)
Defines behaviors rules to ensure RI (insert/delete rules)
Domain attribute
Defines the characteristics of a domain class
Domain attribute constraint
Defines constraints on the values of an attribute

Consequences
Provides a clear overview of defined data integrity
Provides a central place to maintain data integrity

24
OJ11625.qxd 3/11/04 6:49 AM Page 25

Business data access

Intent
To ensure data integrity via a common business data access layer.

Motivation
An application engineer needs to know whether he needs to take care of data
integrity issues or that other components have already dealt with the issues.
By checking the data integrity on a business data access layer, the application
engineer knows that as long as he accesses data via the business data access
layer, data integrity is guaranteed.

Structure/participants
Business data access layer
Provides access to business data
Guarantees data integrity
Handles both immediate and deferred checks
Business data access component
Provides access to certain data sources
Guarantees data integrity for these data sources

Consequences
Provides a common layer that guarantees data integrity

25
OJ11625.qxd 3/11/04 6:49 AM Page 26

Business activity constraint

Intent
To separate activity constraint definition and activity constraint
implementation. This provides a central place to define activity constraints.

Motivation
An activity defines the behavior aspect of the business. Activity integrity
defines what is allowed by an activity. For example, an activity may have
read/write access on certain data classes or may cause certain data transitions.
Activity integrity is business-critical. Sometimes activity integrity is defined
in the activity itself; sometimes it is defined in the user interface layer.

By defining the activity constraints on a business activity layer, the activity

integrity is centrally defined in an implementation-independent way.

Structure/participants
Activity
A behavior business entity in the business domain
Has Domain Class views with certain W/R permissions
Has Domain Class transition view
Domain Class View
Defines a set of Domain classes on which activity has certain privileges
Domain Class Transition View
Defines a set of Domain classes transition on which activity has
certain privileges

Consequences
Provides a clear overview of defined activity integrity
Provides a central place to maintain activity integrity

26
OJ11625.qxd 3/11/04 6:49 AM Page 27

Business activity access

Intent
To ensure activity access via a common business activity layer. Provides a
faade to the client.

Motivation
An application engineer needs to know whether he needs to take care of
activity integrity issues or that other components already have dealt with the
issues. By checking the activity constraints on a business activity layer, the
application engineer knows that as long as he accesses business behavior via
the business activity layer, activity integrity is guaranteed.

Structure/participants
Business activity layer
Provides access to business behavior
Guarantees activity integrity
Handles business transactions
Business activity component
Provides access to certain business behavior
Guarantees activity integrity

Consequences
Common layer that guarantees activity integrity

27
OJ11625.qxd 3/11/04 6:49 AM Page 28

Update Objects and Business Faade

Intent
To reduce the coupling between presentation tier clients and business services.
Enables easy access on client tier to enterprise components.

Motivation
Enterprise components usually use coarse-grain communication to reduce
communication overhead. On the client tier, developers need fine-grain
access to the data objects. The Business Faade provides fine-grain access
to the coarse-grain data object.

Another usability issue is the fact that some enterprise components handle
single objects, while other enterprise objects handle collections of objects.
The Business Faade provides facilities to handle collections if needed.

Structure/participants
Business Faade
Manages all Update Objects
Provides the high-level interface of the enterprise component to the clients
Handles object collections
Runs on the client/web tier
Update Object
An editable data object with fine-grain interface
Data Object
The coarse-grain object that acts like a transport object
To edit Data Objects, Data Objects are converted to Update Objects
Consequences
Fine-grain access for usability, while coarse-grain communication for
performance
Business Faade handles collections regardless whether this is supported
by enterprise components.

28
OJ11625.qxd 3/11/04 6:49 AM Page 29

CRUD (Create, Read, Update, Delete)

Intent
Provides easy use of one of the most popular application protocols. CRUD
is used to maintain persistent data (e.g, base tables). Disconnected
collections are supported as well.

Motivation
The normal protocol for data maintenance is:

1. Retrieve data, optionally via a profile

2. Change the data or insert new data or delete existing data
3. Store the data.

Step 2 may take place off-line.

This is a frequently used protocol that is very suitable for reuse.

Structure/participants
Business Faade
See Update Objects and Business Faade pattern (paragraph 5.7)

Update Object
An editable data object with fine-grain interface
Has all the modified objects, including inserted and deleted objects

Consequences
Optimized data transport
Disconnected collections supported

29
OJ11625.qxd 3/11/04 6:49 AM Page 30

Invoker

Intent
Provides easy use of one of the most popular application protocols.
Invoker is used to start transactions.

Motivation
The normal protocol for transactions is:
1. Collect (user) data, optionally via fill-in form
2. Pass the data as input parameters to transaction and invoke transaction
3. Return the result of transaction.
This is a frequently used protocol that is very suitable for reuse.

Structure/participants
Business Faade
Provides methods that map to transaction
Update Object
An editable data object that collects input data
Data Object
Acts as parameter to method

Consequences
Simplify transaction invocation

30
OJ11625.qxd 3/11/04 6:49 AM Page 31

31