J2EE Design Guidelines for Websphere (P7L)
Release Date: 07/03/05
J2EE Design Guidelines
for WebSphere
(P7L)
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 1 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
Table of contents
1
DOCUMENT INFORMATION ........................................................................................... 4
2
INTRODUCTION ............................................................................................................ 5
2.1
2.2
2.3
2.4
3
OVERVIEW AND SCOPE ................................................................................................. 6
3.1
3.2
4
WHO SHOULD USE THIS DOCUMENT? ................................................................................... 5
WHEN TO USE THIS DOCUMENT? ........................................................................................ 5
WHAT TO USE THIS DOCUMENT FOR? .................................................................................. 5
OTHER DOCUMENTS REFERENCED ........................................................................................ 5
DOCUMENT SUMMARY ...................................................................................................... 6
PRODUCTIONISATION CONSIDERATIONS ................................................................................ 6
APPLICATION "PATTERNS OF USAGE" UTILISING J2EE ................................................ 7
4.1 CLIENT/SERVER (USER-BASED) PATTERNS OF USAGE ................................................................ 8
4.1.1 Web Patterns ....................................................................................................... 8
4.1.1.1 Static Web Publishing ......................................................................................... 9
4.1.1.2 Dynamic Publishing ............................................................................................ 9
4.1.1.3 Form-based Data Maintenance........................................................................... 10
4.1.1.4 Componentised Development (Department) ........................................................ 10
4.1.1.5 Large Scale (Enterprise) ................................................................................... 10
4.1.2 Java Client Patterns ............................................................................................ 12
4.2 SERVICE BASED PATTERNS OF USAGE ................................................................................. 13
4.2.1 Interactive Service Patterns ................................................................................. 13
4.2.1.1 Interactive RMI/IIOP Java Service ...................................................................... 13
4.2.1.2 Interactive Messaging Interfaced Services ........................................................... 13
4.2.1.3 Mail Java Service ............................................................................................. 13
4.2.1.4 Web Services .................................................................................................. 14
4.2.2 Background Delivery Service Patterns ................................................................... 14
4.2.2.1 EJB Background Delivery .................................................................................. 15
4.2.2.2 Web Container Background Delivery ................................................................... 15
4.2.2.3 Custom Service Background Delivery ................................................................. 15
4.2.2.4 Generic Server Background Delivery................................................................... 15
5
J2EE ARCHITECTURE AND DESIGN PATTERNS OVERVIEW .......................................... 17
5.1 WEB CONTAINER PATTERNS ............................................................................................
5.1.1 J2EE Model 1 Pattern (Web Page Navigation) .........................................................
5.1.2 J2EE Model 2 Pattern (Controller Code Navigation) .................................................
5.2 PATTERNS FOR COMMUNICATING BETWEEN THE WEB AND EJB CONTAINER .....................................
5.2.1 Value Object Pattern ...........................................................................................
5.3 EJB CONTAINER PATTERNS .............................................................................................
5.3.1 Facade ..............................................................................................................
5.3.2 Implementation of Business Components and Domain Objects .................................
5.3.2.1 Characteristics of Reusable Business Components or Domain Objects .....................
5.3.2.2 Characteristics of EJBs ......................................................................................
5.3.2.3 Entity EJB Dependent Objects Pattern ................................................................
5.3.2.4 Composed Business Objects Pattern ...................................................................
18
18
19
21
21
22
22
22
23
25
25
27
6 ORGANISATION OF J2EE IMPLEMENTATION WORK IN APPLICATION DEVELOPMENT
PROJECTS ......................................................................................................................... 30
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 2 of 40
J2EE Design Guidelines for Websphere (P7L)
6.1
6.2
6.3
6.4
Release date: 07/03/05
WORKSTREAM DEPENDENCIES AND ISSUES ...........................................................................
SUGGESTED APPROACH ..................................................................................................
CRITICAL ELEMENTS OF THE SOLUTION DESIGN PHASE FOR J2EE APPLICATIONS ...............................
COMMUNICATION POINTS BETWEEN DEVELOPMENT AND INFRASTRUCTURE BUILD ..............................
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
30
31
32
33
Page 3 of 40
J2EE Design Guidelines for Websphere (P7L)
1
Release date: 07/03/05
Document Information
Document Name:
J2EE
Design
Websphere
P7L
Document
Identification:
Version
S
1.
1.0
Release
Date
30-Apr-2004
2.
1.1
07-Mar-05
Version No. 1.1
Author
Guielinesfor
Reviewer
Reason for Change
Ranjay Shah
Ajit Ganaptye
Initial Release
Alice Chettiar
Amita
Sawardekar
Change in logo and
company name.
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 4 of 40
J2EE Design Guidelines for Websphere (P7L)
2
2.1
Release date: 07/03/05
Introduction
Who Should Use This Document?

Applications Designers
When considering the use of a J2EE solution.

Application Implementers
When researching J2EE features and options.

J2EE Solution Architects
When designing solutions using J2EE.

Infrastructure
community
In
understanding the background
application design decisions.
management
behind
2.2
When To Use This Document?
This document should be used during functional application design.
2.3
What To Use This Document For?
This document provides the information necessary for an application designer to make highlevel design decisions about the structure of an application design that uses J2EE.
An application designer may also decide, after reading this document, that J2EE is not
suitable and another technology should be chosen.
Application Developers may reference
implementation standards and guidelines
2.4
the
design
level
guidance
as
well
as
the
Other Documents Referenced

Java Coding Standards
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 5 of 40
J2EE Design Guidelines for Websphere (P7L)
3
3.1
Release date: 07/03/05
Overview and Scope
Document Summary
This paper details the Standards and Guidelines for J2EE applications. This draws from a
large body of public information in the form of industry best practises.
These are considered necessary to allow applications to be correctly supported within
WebSphere environment.
The document is split into four major areas to guide Designers. In summary this includes:

Application "Patterns of usage" utilising J2EE - outlining the principal high-level
ways in which the WebSphere J2EE environment may be utilised by applications

J2EE Architecture and Design Patterns - indicating how J2EE applications may utilise
J2EE objects and services. This acts as a guide to focus on the appropriate underlying
standards and guidelines for a solution


3.2
Organisation of J2EE Implementation Work in Systems Integration Projects –
this section is included both to place J2EE design and implementation within its broader
context of systems integration, and to recognise specific elements of project and work
organisation where J2EE applications raise specific issues.
Quality of Service Design Considerations - including further guidance on design
choices to meet service levels required by an application.
Productionisation Considerations
Please note that not all J2SE and J2EE features and technologies within WebSphere have
been productionised.
These currently include:

Java Management Extension (JMX) and Management Beans (MBean) (supported in
Websphere 5.0)

Java Messaging Service (JMS), Listeners, Message Driven Beans and MQ Series
(supported in Websphere 5.0)

Various J2SE optional Java packages such as Card, Speech, Telephony, Advanced
Imaging and 3D

Java 2 Micro Edition (J2ME) Specification

WebServices (Well supported in Websphere 5.0 with integrated UDDI registry)
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 6 of 40
J2EE Design Guidelines for Websphere (P7L)
4
Release date: 07/03/05
Application "Patterns of usage" utilising J2EE
This section outlines the principal ways in which the J2EE environment may be utilised by
applications. The principal focus here is to provide initial guidance to the standards areas
appropriate to the type of usage
The J2EE platform has been designed as an evolutionary step up from client/server based
computing towards support for multi-channel user-based applications and hosting of
service-based enterprise layers.
Figure 1: J2EE User-based usage patterns
While generally J2EE containers are considered as platforms for Web solutions the features
of the J2EE platform allow for multiple patterns of usage, which are principally based on the
nature of the service requirements, communication protocols and mechanisms. Each of
these patterns utilises J2EE facilities in potentially different configurations and therefore has
differing focus in terms of Standard and Guidelines.
This document recognises the following patterns of usage for which a J2EE solution may be
implemented:
1. Client/Server (User-based) - generally a request/response mechanism where a user
is expecting an immediate response. Generally both the client and server components
comprise the application.
 Web - via a Browser-based HTTP Request/Response into a HTTP Listener and
Servlet/JSP interface
 Java client - a fat client application which makes use of "services" hosted in the
J2EE container.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 7 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
2. Service-based - where application server-based facilities are made available either for
wider use i.e. not constrained to a single application usage.
 Interactive Services - generic "functional" services providing ability to respond to
"user" or system based requests.
 Background Delivery - long-running service thread providing delivery of data
between systems. This may use a variety of communication mechanisms including
MQSeries, Web Services and CICS Transaction Gateway.
The following sections outline these patterns and provide a map into the standards and
guidelines to assist designers and developers in producing their J2EE solution.
4.1
Client/Server (User-based) Patterns of Usage
4.1.1 Web Patterns
Five general types of Web applications are identified and generally reflect increasing
complexity of requirements and J2EE container and feature usage:
1. Static Publishing - the original web model, basic HTML pages, including images and
hyperlinks. The basis of the majority of intranet and internet content.
2. Dynamic Publishing - inclusion of dynamic elements including lists read from a
database. Does not include update capability.
3. Form-based Data Maintenance: inclusion of capturing of user data using HTML forms
and database create, update and delete capability
4. Componentised Development: more functionally rich application including potentially
multiple levels of user access. Generally constrained to departmental use.
5. Large scale (Enterprise): Core, widely and heavily used, system with high
functionality, requiring strong application design and engineering - uses modular
components and EJBs.
These are shown in more detail in Figure 2
Reference:
(http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/web_tier/appl
ication_designs/index.htm)
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 8 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
Complexity
Publishing
Static Web Publishing
Ÿ
Ÿ
Ÿ
Ÿ
HTML pages
Images
Documents
Brochures
Application Development
Dynamic Publishing
Ÿ
Ÿ
Ÿ
Ÿ
HTML pages
JSP
Servlets
Database Access
(Simple)
Forms-based Data
Maintenance
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
HTML pages
JSP
Servlets
JavaBean
components
custom tags
Database Access
(Update - Non
Transactional)
Componentised
Development
(Departmental)
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
HTML pages
JSP
Servlets
JavaBean
components
custom tags
Database Access
(Update - Single
Database
Transactional)
Large Scale
(Enterprise)
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
HTML pages
JSP
Servlets
JavaBean
components
custom tags
entrprise beans
(EJB)
Database
Access (Multitarget
Transactional)
Robustness
Standards Coverage
Programming Standards
Architecture and Design Patterns
Security
Logging/Alerts/Audit
Database
Transactional
JDBC/JavaMail/JMS
Enterprise Connections
Deployment / Service Level Driven Design
Figure 2: Usage categories for Web-based delivery
4.1.1.1 Static Web Publishing
These are “applications” that comprise purely of static information and images, possibly
with some form of navigation structure and access control. The information is created
specifically for the “application”, and does not reside in any external systems. Uses
standard Web mechanisms - HTML, Images, Hyperlinks, some client side script (for
presentational effect)
Recommendation: Static web content should be managed by HTTP servers or, in future,
by a content management technology. These topics will not be further covered in this
document.
4.1.1.2 Dynamic Publishing
These are simple applications that provide very basic facilities to view information contained
in a database. Uses same web mechanisms as Static Web Publishing, but additionally uses
server-side code to access data from a database and build HTML pages dynamically. It is
assumed that any updates to this information are performed via an external mechanism –
i.e. a “Basic Dynamic Output” application is read-only.
Option:
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 9 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
Utilise the J2EE components that deploy within a Web Container, i.e. Servlets, Java Server
Pages and JavaBeans using JDBC to query the database.
4.1.1.3 Form-based Data Maintenance
Where simple data is to be captured from users (e.g. to start a user request for a business
service) HTML forms may be used with server-side validation and processing to perform
update of a single table. Uses the same web mechanisms as Dynamic Publishing, but in
addition more likely to use JavaBeans, Custom Tags and update interaction with database.
Generally failure notification requires no transactional control. Additionally some more
complicated updates may fit this scheme via use of a database stored procedures.
Recommendation: Utilise the J2EE components that deploy within a Web Container, i.e.
Servlets, Java Server Pages and JavaBeans using JDBC to query the database, including
database stored procedures.
4.1.1.4 Componentised Development (Department)
These are applications that generally have a small, usually internal, audience and might
perform reads and updates to a single back-end system, usually a database. They do not
involve access to multiple back-end systems, and do not have high throughput, concurrent
user, or “high 9’s” 24/7 availability requirements. Uses Web mechanisms as Form-based
Data Maintenance but requires more transactional control over database interactions and
may optionally use EJBs.
Any Multi-table or database row updates will generally require single-phase commit
transactional control to ensure integrity of data.
Recommendation:
Implement as a fully layered architecture using Web Container components for presentation
and application navigation, and optionally EJB Container components to manipulate
business information.
4.1.1.5 Large Scale (Enterprise)
These are applications that generally may have large or external audiences, or that interact
in a complex manner with multiple back-end systems (e.g. databases, CICS, asynchronous
messaging, ERP, CRM etc.), or with high 9’s or 24/7 availability requirements.
Uses same mechanisms as Componentised Development (Department), but in addition is
likely to require strong engineering of connectivity and interaction control.
Recommendation:
Implement as a fully layered architecture using Web Container components for presentation
and application navigation, and EJB Container components to manipulate business
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 10 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
information. Will probably include additional technologies such as JMS, the White Label
client, Java Connector Architecture etc.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 11 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
4.1.2 Java Client Patterns
The use of a Browser-based HTML solution does have some limits, particularly in terms of
the functional richness of the client interface. In situations where a more sophisticated client
is required there is the option to implement code onto the clients (as a fat client). In J2EE
terms this is generally a Java client application using EJB Client stubs to talk to a EJB Server
via RMI/IIOP.
A Java client application might be implemented either as a stand alone Java application, or
as a browser-delivered Java Applet.
Option:
Implement presentation and application control (including some degree of state
management) as a thick Java client, running in a J2EE client container. Implement serverside business logic, business objects and back-end persistence using EJBs, and possibly
other connectivity technologies such as JMS and the Java Connector Architecture (JCA).
Whilst EJBs may not be required to manage transactional complexity, they are the only J2EE
components that can be remotely invoked via RMI/IIOP.
Alternative:
The Java client might interact with a Web Container over HTTP, rather with an EJB
Container via RMI/IIOP. The advantages of this approach are simpler firewall configurations
between client and server, and very slightly simpler overall configuration for particularly
highly available applications. The disadvantages are increased marshalling and demarshalling complexity, and more software components in the end-to-end topology.
Alternative:
Implement the Java client as an Applet rather than a standalone application. The advantage
is reduced software distribution overhead, providing the compromise between applet
footprint and network speed is acceptable, and the user audience has a reasonable
consistency of browser levels consistent with JDK level requirements for the applet to
interact with the EJB Container. This last requirement can be mitigated to an extent by
adopting the HTTP communication approach rather than RMI/IIOP.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 12 of 40
J2EE Design Guidelines for Websphere (P7L)
4.2
Release date: 07/03/05
Service Based Patterns of Usage
Common business services may be "presented" via server-based functionality. Generally
these may be used by multiple "client" applications and no state information is maintained
on the server on behalf of clients. The services might be invoked “on request” via an
interactive protocol, or represent persistent or scheduled background activity. The service
implementation in each of the following patterns is generally similar in it's core details; the
prime difference is the communication mechanism by which the service is initiated. Note
that some services might require a common service implementation, but two or more
interaction / initiation patterns to support multiple client or invocation types.
4.2.1 Interactive Service Patterns
4.2.1.1 Interactive RMI/IIOP Java Service
These are services that are intended to be accessed directly via RMI/IIOP calls from another
Java application. Typically, this occurs when the client application is a standalone Java user
application or Java applet. In this case, the client and server-side components are normally
considered a part of the same application.
Recommendation:
Implement as EJB components where the client application uses EJB client stubs. This
provides additional facilities for workload management that are harder to configure for Java
applications that are started using the Java runtime alone. See also the section on “Java
Client Patterns” above.
4.2.1.2 Interactive Messaging Interfaced Services
These are services that are intended to be accessed via asynchronous messaging (e.g.
MQSeries or JMS) from a client or other applications. They generally operate as "postal"
services provided allowing "posting" of instructions or notifications.
A typical implementation would be to use a JMS request handling component (e.g. the
WebSphere v4 JMS Listener or WebSphere v5 / EJB2 Message Driven Bean) to delegate
handling of incoming messages to the EJB container. The alternative is to implement a
custom message-handling daemon (possibly as indicated in the background services
patterns below). In either case, the message handler would typically invoke activity by
calling further Enterprise JavaBean components in the EJB container.
Recommendation: Implement using the JMS Listener technology in WebSphere 4, calling
function in additional EJB components.
4.2.1.3 Mail Java Service
These are services that are intended to send and receive emails to/from internal or external
email accounts. This can occur when initiated from the client application or from another
service. The mail service may also include functionality such as adding the legal disclaimer
to messages and checking message delivery.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 13 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
Recommendation: Implement JavaMail based EJB Components using mail protocols SMTP
for outgoing messages and POP3 for retrieving incoming messages.
4.2.1.4 Web Services
Web Services is a set of evolving standards for application to application interaction using
language and platform independent protocols. Typically, current implementations are
effectively performing remote procedure calls using XML over HTTP via the SOAP
specification. However, other transports such as asynchronous messaging or e-mail are also
possible.
J2EE applications can either be web service requestors, web service providers, or both. A
variety of tooling and runtime facilities are provided to support this.
4.2.1.4.1 J2EE Applications As Web Service Requesters
This involves simply including Web Services client code in a J2EE application. Java IDE
tooling provides mechanisms to generate the Web Services client code, which can be
included in Web Container or EJB Container components.
Recommendation:
Acquire the WSDL interface definition for the service to which requests are to be made, and
use Java IDE to generate the client code for incorporation in the J2EE application.
4.2.1.4.2 J2EE Applications As Web Service Providers
This involves providing a Web Services interface to defined components of a J2EE
application. It may also require the generation of WSDL interface definitions, and UDDI
directory entries, depending on the scope of the Web Services architecture required.
Java IDE tooling can create the required WSDL and UDDI definitions, and generate client
code to call the Web Service. The WebSphere Application Server runtime can be configured
to handle incoming Web Services requests and direct them to the correct implementation
component.
Recommendation:
Construct the service implementation using EJB components, and use Java IDE tooling to
create a Web Services interface. Register the interface during J2EE application deployment
to WebSphere so the runtime will pass requests through for handling.
4.2.2 Background Delivery Service Patterns
These are persistent services that run without interaction, possibly on a scheduled basis. It
is assumed that the decision has been taken for whatever reason to implement these
services within a J2EE architecture, so this section will only consider the mechanism of that
implementation.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 14 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
Since Web Container components are intended specifically to handle HTTP requests, the
most natural implementation for background delivery services is with EJB Container
components, but it is also possible to use Web Container components for non-J2EE Java
applications.
4.2.2.1 EJB Background Delivery
This implementation is suitable for services that require transactional interaction with backend systems. The service daemon, however, must exist outside the EJB Container.
Mechanisms for starting the daemon are as described separately in the other background
service type definitions below. Once started, the daemon then makes calls as normal to
components within the EJB container.
Note that if the background service is also required to handle requests, then EJB delivery is
generally the most feasible mechanism. This solution allows flexibility in allowing requests
to be handled via multiple communication mechanisms and not constrained purely to HTTP
requests.
4.2.2.2 Web Container Background Delivery
Background services can be delivered in the Web Container by creating a Java Servlet that
is specified to the Web Container to be pre-loaded when the container starts. The Servlet
init() method can then be used to spawn the daemon thread, which can then provide
background service function within the Web Container.
Recommendation:
 This model is bending the scope of the Web Container. Do no use it unless
there is a good reason why the background service is required to support a
web application and is not suitable for implementing outside the Web
Container.
4.2.2.3 Custom Service Background Delivery
Every Application Server configured within WebSphere provides a number of services, such
as Session Management or indeed the Web Container itself (more specifically, the HTTP
request handling service). It is possible following guidelines in Section 4.10 of the
WebSphere InfoCentre to create custom services by implementing application code to a
specific API. These services can then be registered as provided by any application server,
and will be started and stopped with the application server, and otherwise monitored by the
WebSphere infrastructure.
Recommendation:
 This should be the standard model for providing persistent Java services.
 To enable flexibility, a service daemon started in this manner can then use EJB
components to perform function.
4.2.2.4 Generic Server Background Delivery
The WebSphere administrative domain can contain “generic servers” in addition to
“application servers”. A generic server is any executable process that it is desired be
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 15 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
managed by the WebSphere infrastructure. Section 6.6.47 of the WebSphere Infocenter
describes the purpose and configuration of generic servers.
Recommendation:
 Generic servers may provide a suitable implementation for non-Java
background services, but it should be carefully established that the WebSphere
environment is appropriate in this case.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 16 of 40
J2EE Design Guidelines for Websphere (P7L)
5
Release date: 07/03/05
J2EE Architecture and Design Patterns Overview
As J2EE has matured, a patterns-based approach to communicating successful design has
emerged in the marketplace. There are several public pattern repositories, both on the
internet and in book form, some of which are listed as references below. It should be noted
that whilst some of these patterns are well-proven and established (e.g. Model 1 and Model
2 patterns in the Web Container, Facade in the EJB container), others are less well agreed
on, and subject to change. This section attempts to give an overview of patterns that are
established and near-universal in their application, and of patterns which are less well
established but nevertheless illuminate important design issues.
A number of design patterns can be combined to form a single application architecture that
can be used as a base for the development of a particular type of application (e.g. a userbased web application). The design patterns and the application architecture can be partially
implemented as ‘frameworks’. A framework will provide a standard set of Java classes for
developers. For an entire application framework, these classes not only provide common
functions such as auditing and error logging but also the ability to quickly add new business
functions. Using an application framework will reduce the amount of development required
for a new application or to add new functionality to an existing application and also enable
re-use at the design and code level.
Recommendations:
Any J2EE project design should conduct a review of design patterns available and consider
inclusion of those that are applicable. This should include patterns that are:

Included with third party packages being used by the project

Available in public repositories (e.g. Apache Struts)
The preference should be for all J2EE applications to be developed using an
application framework a number of design pattern frameworks. The choice of
application and design pattern frameworks should be based on the following principles:

For projects that will utilise J2EE third party packages, use the application framework
that comes with the package if it is mandated

For projects that are ‘web enabling’ existing systems and do not require a full
application, use relevant design patterns frameworks such as Apache Struts.
References:

Sun J2EE Blueprints: http://java.sun.com/blueprints/

“The Server Side” Patterns Repository: http://www.theserverside.com/patterns/

“J2EE Core Patterns” by John Crupi et al, published by Addison-Wesley
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 17 of 40
J2EE Design Guidelines for Websphere (P7L)
5.1
Release date: 07/03/05
Web Container Patterns
The Web Container is principally concerned with the servicing of web requests (via HTTP)
and generation of web responses (as HTML pages). The J2EE model provides two principal
mechanisms by which this page may be generated:
1.
2.
HTML layout with ability to execute code as the page is rendered (Java Server Pages)
Code with direct writing to HTTPResponse object (Servlets)
Due to the integrated nature of the Java environment these mechanisms may additionally
be utilised together i.e. a Servlet initiating a JSP to handle the page generation. The two
principal patterns by which these mechanisms may be used commonly referred to as:

J2EE Model 1 and

J2EE Model 2
These are distinguished by the absence or presence (respectively) of a controller servlet
that dispatches requests from the client tier and selects the page output (or view). A more
recent variation of the J2EE Model 2 pattern is the “Front Controller Servlet” pattern, as
described on the Sun J2EE blueprints site, and implemented by the Apache Struts
framework (see references section for URLs).
5.1.1 J2EE Model 1 Pattern (Web Page Navigation)
The J2EE Model 1 pattern consists of a Web browser directly accessing JSP pages in the
Web tier. JSPs functionality is equivalent to that of Microsoft Active Server Pages (ASP)
within an IIS environment. However JSPs are not interpreted and allow full Java access to
mechanisms such as JDBC.
The JSP pages access Web-tier JavaBeans that perform business operations on the data
model, and the next view (JSP page, servlet, HTML page, etc.) to display is determined
either by hyperlinks selected in the source document, or by parameters passed to GET or
POST operations. Each JSP page or servlet processes its own inputs (parameters from GET
or POST), and the next page to display is determined by the current page being accessed.
Recommended use:

This pattern does not separate control logic from presentation logic and therefore
maintenance is generally more involved. Therefore the J2EE Model 1 pattern is
considered suitable only for simple web applications that primarily provide read only
access to information contained within databases (Basic Dynamic Publishing).

The Model 1 architecture can provide a cleaner design for small, static applications.
Model 1 architecture is suitable for applications which have very simple page flow, have
little need for centralised security control and/or logging, and change little over time.
Model 1 applications can often be refactored to Model 2 if application requirements
change.

The ideal architecture for Model 1 applications involves encapsulating programme logic
and JDBC database access within JavaBeans used by JSPs. Wherever possible, Java
code snippets required in JSPs should be implemented as JSP1.2 Custom Tag Libraries
rather than coding Java direct in the JSPs themselves.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 18 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
5.1.2 J2EE Model 2 Pattern (Controller Code Navigation)
The J2EE Model 2 pattern introduces a controller servlet between the browser and the JSP
pages or servlet content being delivered. The controller centralises the logic for dispatching
requests to the next view, based on the request URL, input parameters, and application
state.
The Model 2 architecture de-couples JSP pages and servlets from one another, and places
responsibility for page flow within controller servlets. While this can be done across multiple
servlets the Front Controller J2EE design pattern describes the benefits of centralising all
application request dispatching in a single servlet. The controller is also an application of the
Mediator pattern, since it de-couples view components from one another.
In order to accomplish a Single Servlet model the client is required to submit an action code
for each interaction, i.e. for each unique task, a unique command (action code) is required.
A variation on this approach is to deploy several “front controller” servlets, each configured
to control the actions for a grouping of related application function.
Recommended use:

The Model 2 pattern is recommended for use by most applications, since this makes
applications easier to maintain and extend. Views do not reference each other directly.
The Model 2 controller servlet provides a single point of control for security and logging,
and often encapsulates incoming data into a form usable by the back-end MVC model.

While the Model 2 architecture adds some complexity to an application, an MVC
application framework can greatly simplify implementing a Model 2 application. There
are various MVC frameworks available, but preference is to utilise the Apache Struts
framework. This is an Apache Open Source framework endorsed by all the major J2EE
vendors. This includes a configurable front controller servlet. Abstract classes are then
provided which can be subclassed to handle request dispatches.

One reason for building a bespoke navigation framework rather than using Struts is
where an application has complex screen flows, and specifically where there are
identifiable groupings of screens that form individual “dialog flows”, particularly where
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 19 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
the sequence of screens within a dialog flow is determined by business rules. Struts
does not provide a convenient mechanism to encapsulate related groups of screens in
recognition of this.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 20 of 40
J2EE Design Guidelines for Websphere (P7L)
5.2
Release date: 07/03/05
Patterns for Communicating Between the Web and EJB Container
In general, communication between the Web and EJB Containers is usually by way of
remote method calls. There are two implications of this:

Method Calls Between the Two Containers are Expensive: remote calls involve
marshalling and serialising then demarshalling and deserialising the method name,
target object, parameters and return types. Even when the call is not in fact remote,
there is still an overhead involved as the container must also pass certain transactional
and security context on any call involving these components.

Objects Are Passed By Copy: since objects passed as parameters or return types are
serialised and passed between two separate processes, the paradigm is “pass by copy”
rather than “pass by reference”. This means, for example, that if Process A passes
Object Z to Process B, and Process B changes Object Z, then Process A will not see the
changes unless Object Z is passed back as a return type. Most J2EE servers contain
performance optimisations to enable “pass by reference” for co-located Web and EJB
Containers, but usage of “side effects” in this scenario should be carefully understood
and controlled, otherwise it may become difficult to re-deploy applications in alternative
topologies.
An important pattern that partially addresses these issues is the “Value Object Pattern”
5.2.1 Value Object Pattern
Some entities have a set of attributes that are always used together. An address (city,
state, zip code, etc.) is an example of one such group. Suppose that in total, an address is
composed of 15 individual attributes, each accessible by a corresponding getXXX method on
an entity EJB. Then, every time an address is requested, 15 remote calls will be invoked on
the EJB (whether through a facade or direct to the entity), one for each attribute. This will
incur heavy costs in network traffic and EJB container resource usage.
These costs can be reduced by adopting a coarse-grained view of the fine-grained address
information. The attributes of the address are aggregated into an instance of an "Address
Value Object". This instance is then serialised and sent over the network to a requesting
client, where the object is deserialised. Subsequent read accesses go through the value
object rather than the remote entity object. Since these accesses are local, they require no
server communication and use fewer resources.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 21 of 40
J2EE Design Guidelines for Websphere (P7L)
5.3
Release date: 07/03/05
EJB Container Patterns
5.3.1 Facade
Different types of application users need different sets of functions to support their
workflows. These functions may use a variety of Entity EJBs or other representations of
business domain objects. Consider an implementation where the user interface control
objects (e.g. Java servlets) working on behalf of these clients work directly with the domain
objects, co-ordinating them to carry out a user request. This arrangement leads to the
following problems:



The servlets need to be aware of any associations or required interactions among the
domain objects. However, nothing prevents the servlets from using these domain
objects inappropriately.
If the domain objects' APIs are modified, the servlets must be modified accordingly.
This change can be hard to manage.
Even if the domain objects reside on the same server as the servlets, a servlet still
has to make multiple RMI/IIOP calls, each of which is relatively expensive. The
situation is exacerbated if the servlets are remote from the domain objects.
A solution to these problems is to introduce a session facade, which provides a unified,
workflow-oriented interface to a set of enterprise beans. This facade is implemented as a
session bean. It controls interactions with any domain objects or other EJBs in the EJB
container on behalf of the servlets.
This pattern has the following benefits:






More consistent use of enterprise beans. Business objects are less likely to be
misused, since interactions between them are handled only by the session facade.
Easier support for multiple client types. A JSP page/servlet front-end, a
JFC/Swing front-end, and a web service can access an enterprise data model through
the same facade.
A place to centralise logging, transaction handling, and security. A session
facade is a convenient and logical place to implement these functions, since this is
the single point of entry for clients.
Reduced network traffic. Instead of making multiple remote calls to co-ordinate
enterprise beans, client objects make one remote call to the session facade, which
takes care of the co-ordination.
Greater flexibility with the enterprise data model. It's easier to assess the
impact of changing the enterprise data model if all interactions with the model are
centralised in a facade or set of facades.
Greater flexibility with the server implementation. A session facade can use
enterprise beans, the JDBC API, CORBA, or other technologies to provide application
functionality to its clients. Since the implementation details of the server are hidden
from the client, application services can be implemented or modified without client
redeployment.
5.3.2 Implementation of Business Components and Domain Objects
Whilst the J2EE and EJB specifications (both J2EE 1.2 / EJB 1.1 and J2EE 1.3 / EJB 2.0)
provide a model for implementing objects with identity representing data entities in
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 22 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
persistence stores (i.e. Entity EJBs), they do not directly address the broader topics of
reusable business components and fine-grained versus coarse-grained business objects.
Whilst progress is being made in this area, there is not as yet industry-wide agreement on
how this issues relate to the components defined in the J2EE and EJB specifications.
The problem can best be illustrated by describing the characteristics of some relevant
abstract components that are often identified in a generic multi-layered distributed server
application architecture, and comparing them to the most relevant J2EE / EJB components.
It will be seen there is at worst a mismatch and at best a lack of clarity between the
requirements and the implementation choices. The final two subsections then discuss two
approaches to “bridging the gap”: “Entity EJB Dependent Objects” and “Composed Business
Objects”. Both are recognised in the industry as valid “design patterns” to a certain degree,
but this is a relatively changeable area, and still the subject of extensive discussion.
5.3.2.1 Characteristics of Reusable Business Components or Domain Objects
One common goal of J2EE implementations is to build reusable, functional business
components. It is far more common to state this goal than to achieve it, and there is no real
industry agreement on the best strategy. Even when reuse is not a goal, some of the
requirements of functional business domain objects to provide a usable business logic
programming model are similar. Some of the characteristics common to more successful
implementations are:

Reusable business components and domain objects driven by business
requirements analysis tend to be relatively coarse-grained. It is only at a
relatively coarse grained level that function common to more than one application tends
to appear in significant volume. Equally, developers and business analysts familiar with
business logic and function tend to think in terms of business objects that are more
coarsely grained than the database models used to persist the business data they
encapsulate.

Separation of business modelling and function from persistence mechanism. It
is not uncommon for different applications to share functional requirements (e.g.
business rules), but to use different data stores. In this case the ability to deliver
business model and function as a reusable unit with a flexible persistence strategy
increases the likelihood of successful reuse. This is consistent with a coarse-grained
approach, as fine-grained elements of a specific application design will tend to be more
closely related to the structure of persistent systems.
Even where the back-end persistent store is the same across two or more applications,
one application might require direct, synchronous, transactional interaction, whilst
another might require a more loosely coupled, asynchronous messaging or nontransactional web services-based approach. Similarly, the persistent store or mechanism
for a single application may need to be capable of changing over time. Both these
requirements again favour business components or domain objects whose model is
separated from the persistence implementation.

Provision of a coarse-grained “service” interface. One of the challenges in
providing business components or domain objects that can be re-used across
applications, or across delivery channels, is in separating the concepts of “business
process” and “screen flow”. A failure to take account of this distinction in the API of
business components and domain objects can result in a business logic implementation
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 23 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
that is closely tied to a specific delivery channel or application. Whilst this is not a cut
and dried issue, one means of maximising the reuse potential is to provide a stateless
“service” API to the business components – i.e. where each call is wholly self-contained
and describing, rather than dependent on previous or subsequent calls to complete a
task. It is not uncommon for business components to provide both a granular “object” or
“remote procedure call” API, and a more coarse grained “services” API.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 24 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
5.3.2.2 Characteristics of EJBs
In contrast to the above description of common characteristics for application components,
the following describes the characteristics of the J2EE components within the EJB Container.
It is these components that are commonly used to implement business logic and models, as
they provide access to the location independence and transaction services of the J2EE
server.

Session EJBs do not have a well defined granularity. The granularity of a stateless
session EJB is not defined at all by the specification. Rather, it is defined in practical
terms by the number of methods implemented on each EJB, and the similarities of
function or implementation between those methods. The granularity of stateful session
EJBs is slightly more defined, but only in that each instance relates to a single user – the
arrangement of methods implemented for each class of stateful session EJB is wholly
arbitrary.

BMP Entity EJBs do not have a well defined granularity. A single BMP entity EJB
may represent any granularity of business object, as the mapping of that object to
persistence is implemented by the developer.

The granularity of CMP Entity EJBs is limited by Object-Relational Mapping
tools, and is closely tied to the persistence data model. A single CMP entity EJB
class is mapped to tables in a persistent database using the object-relational mapping
tools provided by the J2EE application server vendor. In EJB1.1, this effectively limits
the CMP Entity EJB to representing a single main table and one or more “extension files”
with the same primary key. EJB2.0 provides a more flexible model by implementing
“container managed relationships” between multiple Entity EJB classes, but the
implementation is still fairly closely tied to the structure and relationships of the
underlying database model.

Entity EJBs are specifically for mapping Business Objects to Database tables.
They do not provide any support for providing persistence via asynchronous messaging,
external transaction monitors such as CICS, or for a combination of persistence systems.
5.3.2.3 Entity EJB Dependent Objects Pattern
A full discussion of this design pattern can be found in the patterns repository at “The
Server Side” (http://www.theserverside.com/patterns/depbmp.jsp) or in the book “J2EE
Core Patterns” published by Addison-Wesley. It should be noted that the status of this
pattern is relatively clear for EJB1.1, but less so for EJB2.0 as it is affected by the “EJB Local
Interface” and “Container Managed Relationships” introduced by that level of the
specification. This section attempts to recognise these issues.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 25 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
Figure: Entity EJB Dependent Object Pattern
Applicability
The “Entity EJB Dependent Objects” pattern may be applicable for an application that
requires coarse-grained business objects to be mapped to a fine-grained data model in a
database.
Implementation
Business objects are implemented as bean-managed persistence entity EJBs, so that the
SQL / object-relational mapping code is implemented by the developer.
The developer chooses to implement the persistence methods (create, load, store, remove)
of the entity EJB using a set of finer-grained “dependent object” classes that represent the
internal data structure of the business object.
Variations
A common variation to this technique is to implement “lazy loading” of the dependent
objects. In this variant, only the core data is by default loaded / updated etc. by the EJB
persistence methods. Any other data is loaded / updated only when required due to
invocation of specific functional methods on the EJB.
Relevance to EJB 2.0 Specification
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 26 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
It is likely, but not certain, that the “dependent objects” pattern will be replaced with the
advent of EJB 2.0 by the use of “container managed relationships” in CMP entity EJBs. This
feature uses low-overhead “local interfaces” and deployment descriptor information to
managed the relationship between several entity EJBs.
A coarse-grained “Customer” EJB might thus have container-managed relationships with
several “Address” EJBs, “Account” EJBs etc. The advantage of this approach is a move from
object-relational modelling hard-coded in dependent objects towards declarative mapping. A
disadvantage is that this approach is still fairly restricted to EJB relationships mapping
closely to underlying data relationships.
Limitations


Object-relational mapping hard-coded in usage of dependent objects, unless a
framework is constructed to allow flexibility.
Limited to database persistence.
5.3.2.4 Composed Business Objects Pattern
The “composed business object” pattern is less-well recognised as a J2EE design pattern,
but has been successfully implemented several times, and is similar to some component
models that exist in the CORBA world. The pattern attempts to fully isolate the business
model and function from the persistence mapping and implementation.
Figure: Example Composed Business Objects Pattern
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 27 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
The preceding figure shows an example of a composed business object design. It should be
noted that this “pattern” is more accurately described as a “design goal” of separating out
the business object class from its persistence implementation. A variety of approaches can
be taken to achieving this goal, none of which is currently agreed as a “standard” or formal
pattern.
Applicability
This pattern is useful if a “common view” of a business object is required across data stored
in multiple persistence systems, or if the persistent strategy for the data needs to be
flexible.
Implementation
The most common implementation of composed business objects is as plain Java classes,
which are used by Session EJBs and in turn may use one or more Entity EJBs or other
persistence mapping components. An alternative is to use Stateful Session EJBs. It is
possible to view the “Entity EJB Dependent Objects” technique above as a special case of
this pattern using BMP Entity EJBs as the implementation technique.
Variations
Whilst it is fairly straightforward to model or implement business objects as plain Java
classes, it is less obvious how to link these classes to one or more persistence technologies.
Some of the alternatives are:

Implement
all
business
object
classes
as
sub-classes
of
an
“AbstractBaseBusinessObject” class. Have the business object classes produce some
form of “persistence event “ (e.g. create, store, delete), the execution of which is
delegated to the superclass. Provide the superclass with either configuration information
or a subclass-specific “PersistenceManager” class in order to execute the “events”.

Implement a set of “PersistenceCommand”s entirely separately from the business
object model. Have these commands accept various business objects as their input
parameters, such that the required information can be extracted.

The “composed business object” can either be designed as using a set of granular “Data
Access Objects” which in aggregate perform complex object-persistence mapping, or as
truly composed from a set of more granular “business objects” which represent both
finer grained business modelling and persistence mapping.
Any of these techniques can allow persistence mapping code to be flexibly implemented in
separate components from the business modelling and functional behaviour of the business
object model itself.
Limitations
 Composed Business Object patterns generally demand significant technical framework
design and implementation effort.
 Such solutions are not the most common in the industry, and demand a non-trivial
learning curve of technical developers (however, “application” or “business logic”
developers are generally well-shielded from complexity).
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 28 of 40
J2EE Design Guidelines for Websphere (P7L)
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Release date: 07/03/05
Page 29 of 40
J2EE Design Guidelines for Websphere (P7L)
6
6.1
Release date: 07/03/05
Organisation of J2EE Implementation Work in Application Development
Projects
Workstream Dependencies and Issues
This section attempts to position J2EE application design and development within an overall
project that contains a J2EE based application with some degree of systems integration. It is
not intended to be a reflection of the overall methodology used in industries, or a
recommended methodology. It is intended to illustrate some of the dependencies and
interactions between different workstreams (solution architecture, operational environment
build, systems integration, application development), and to draw out some of the issues
and tasks specific to J2EE development.
Figure: Example workstream breakdown and dependencies for a J2EE / Systems
Integration Project
At a high level, the issues to draw out are:

Almost all J2EE development projects either contain some degree of systems
integration, or are themselves a part of a larger systems integration project.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 30 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05

Whilst iterative development methodologies can be very effective in delivering
application function within a J2EE project, there are a number of technical issues that
must be addressed which may require considerable effort, and which are not so suited
to iterative delivery.

A critical early part of the overall project work is to identify and define the separate
workstreams involved. The diagram above captures some typical workstreams involved
in a J2EE / systems integration project.

It is important both in the early analysis and design phases, and throughout the project
lifecycle, that both technical and functional J2EE implementation is carried out in the
context of a broader end-to-end architecture and design.
Symptoms exhibited by J2EE projects that do not address these issues tend to include:

Failure to meet delivery targets

High defect rates in code

Confused and inconsistent architecture that is difficult to maintain and modify

Failure to meet required performance, scalability and availability levels, coupled with an
ability to address architectural problems to effect corrections

Application is not amenable to ongoing functional change and evolution
It is not uncommon to encounter J2EE projects where the entire methodology is that
encapsulated in the box “Iterative functional build and deploy” in the diagram above – i.e.
applying a RAD or Extreme Programming approach. Whilst these methods are suitable for
functional application development in a J2EE context, they do not address broader concerns
of solution architecture that are critical to a successful distributed, server-side
implementation (including, but not limited to, J2EE and WebSphere).
6.2
Suggested Approach
The following is a description of the critical systems integration methodology elements that apply
to the J2EE standards and practises discussed in this document:
1. Upfront “Analysis” and “Design” phases for the solution (as opposed to development project)
are shown. These address two concerns:
a. This approach allows workstreams to be identified and defined to reflect technical
areas of the solution, as opposed to areas of application function. This generally
ensures that each technical problem will be addressed and solved by one team at one
time, and allows expert technical resource to be appropriately tasked. By contrast,
where resources are broken into teams and assigned tasks based on functional areas
of the application, multiple teams tend to solve the same architectural problems in
multiple ways (resulting in inconsistent architecture), and assigning expert technical
resource to the correct tasks is problematic.
b. There are several critical aspects of the Design phase that must be carried out before
either the J2EE technical application architecture or the iterative functional build
activity commence. Unless this happens, the solution will not be engineered to achieve
appropriate quality of service levels, particularly for application state data, and will not
be architected to achieve any potential goals of component or service-based reuse
beyond the single project implementation. This tasks are itemised in the next subsection.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 31 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
2. Iterative functional build and deploy takes place within a defined J2EE technical architecture
that specifies how J2EE components (EJBs, servlets, JSPs, HTTPSession) are used to manage
state, to apply transactions to ensure data integrity, to support a business object model, and
to isolate application layers such as presentation, application control, business services etc.
Since defining such an architecture is critical to achieving defined service levels, and is
constrained by known integration requirements to databases, asynchronous messaging etc.,
this activity is more suited to a “waterfall” than “iterative” approach.
It is useful in this context to note that “iterative” approaches depend on end-user cooperation, and are intended to address changing functional requirements not changing
technical requirements. Whereas business requirements may change (or be refined /
clarified) over timescales on the order of days or weeks, technical requirements change over
periods closer to months or years. In order to allow iterative functional build to commence
early in the project lifecycle, it is worth concentrating initially on producing technical
framework interface definitions or patterns on which functional development can begin,
rather than building an entire technical framework before commencing iterative development.
For these reasons, a separate technical framework stream is depicted, following a waterfall
approach, and showing the point at which interface design is complete and functional build
can begin.
3. Two other separate, waterfall streams are shown: physical topology design and build, and
back-end integration. For similar reasons to those given for J2EE technical architecture
above, these are not subject to rapidly changing requirements, and so do not benefit from an
iterative approach. What is depicted for the backend integration is the initial definition and
deployment of integration technologies, followed by the incremental delivery of integration
function. This reflects the fact that once the integration framework is established, individual
“messages” between new applications and existing systems can be added in an incremental
fashion to tie in with the iterative delivery of application function.
6.3
Critical elements of the Solution Design phase for J2EE applications
As described above, there are several critical aspects of the Design phase that must be
carried out before either the J2EE technical application architecture or the iterative
functional build activity commence. These are:

Data modelling and quality of service requirements to enable state management within
the J2EE application to be properly designed so as to be fit for purpose. These topics
are addressed in the section on “Service Availability” below.

J2EE technical architecture for “business components” (i.e. how to use Java classes,
EJBs etc. to implement a “customer” or “account” object) . These topics are addressed
in the “EJB Container Patterns” section above.

Non-functional requirements at enable engineering of physical topology and state
management solutions. A sample “non-functional requirements” template is included as
an appendix to this document.

Definition of different “process” types (e.g. screen flow, long-lived transactional
workflow, micro-flows describing sequences of granular persistence actions), and their
placement as “responsibilities” of specific components in the end-to-end architecture
(including, where applicable, as responsibilities of existing back-end systems).
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 32 of 40
J2EE Design Guidelines for Websphere (P7L)

6.4
Release date: 07/03/05
Definition or categorisation of different types of “business rule” (e.g. validation /
eligibility checks, calculation rules, parameterised rules etc.). It is likely that some form
of business rules will be processed in many different components, and some individual
rules may be required by multiple components (e.g. eligibility checks may both
determine screen flows, and be required for back-end business controls). Understanding
the types of rules that exist and their implementation requirements is critical to
managing the tendency of the entire set of “business rules” to disperse throughout the
architecture.
Communication Points Between Development and Infrastructure Build
The following information needs to be communicated from projects to the infrastructure
build team:
 Required information to determine if the application is “large or critical” or “small and
non-critical” as defined in the WebSphere Productionisation Technical Specification.
 Non-functional requirements (see appendix)
 Names of existing systems with which integration is required:
o Database instances
o CICS regions and transactions
o MQSeries queues and queue managers
Although not a “communication” as such, an early delivery of a “thin function” end-to-end
slice through the application would enable the infrastructure team to support early
performance and scalability testing, which in turn would verify whether the application
development team was on course to hit service level requirements.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 33 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
Appendix A - Application Layer Separation
There are several reasons why presentation and business logic should be divided into
separate software layers, even if they both reside together in the Web tier.

Maintainability. Most business logic occurs in more than one use case of a particular
application. Copying the code for business logic from a scriptlet and pasting it into
another JSP page, or into a client, expresses the same business rule in two places in the
application. Any future change to that logic will require two edits instead of one.
Business logic expressed in a separate component and accessed referentially is easier
to maintain. The component can be modified in one place in the source code, and the
behaviour changes everywhere the component is referenced. Similar arguments hold
for reusing presentation logic with server-side includes, custom presentation tags, and
stylesheets.

Client independence and code reuse. Intermingling data presentation and business
logic ties the business logic to that particular type of client, making new client types
more difficult to add. For example, business logic in JSP scriptlets cannot be used by a
servlet or an application client; the code must be re-implemented for the other client
types.

Isolating developer skill sets. Code that deals with data presentation, request
processing, and business rules all at once is difficult to read, especially for a developer
who may specialise in only one of these concerns.
For these reasons, it's good practice to create business and presentation layers in an
application design. The business layer provides only application functionality, with no
reference to presentation. The presentation layer presents the data and input prompts to
the user (or to another system), delegating application functionality to the business layer.
Business rules can then be changed in the one layer, with little or no modification to the
presentation layer. The presentation or workflow of the application can change without
affecting business logic code. Business logic, available referentially as simple method calls
on business objects, can be used by multiple client types. And developers that specialise in
either business rules or presentation can work relatively independently, concentrating on
the concerns and technologies that they best understand.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 34 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
Appendix B - Non-Functional Requirements Template
Non-functional requirements in general describe those requirements / goals of any system
that do not relate to its business function. These typically include such things as service
levels, expected user community (both total and concurrent), transaction rates, security
policies etc. The information is vital to determining the correct deployment topology,
network and server sizing and technology components.
Non-functional requirements typically include such things as:
Service-level requirements, e.g.

Capacity, e.g. data volumes and growth rates, transaction rates and data sizes,
concurrent users, peak users etc.

Performance, e.g. user response times, required throughput.

Availability, e.g. core business hours, 24/7 requirements, batch windows, disaster
recovery period.

Security, e.g. encryption, certificate
applications and data sources.

Systems management, e.g. source code control, server and application instrumentation
and monitoring.

Logging and audit trails, historical data lifetime etc.
management,
access
policies
for
existing
Environmental constraints, e.g.

Geographical considerations and connecting network capacity.

Corporate IT standards and approved / preferred technologies.

Existing systems context.

Corporate methodology or process standards, required signature authorities.
System lifetime requirements, e.g.

Portability

Maintainability
The following information in particular is useful to perform capacity estimations.

Average number of users visits in a day. A user visit is an entire interaction between
the user and the web application.

Average number of HTML pages users retrieve in a single visit.

Number of concurrent users.

Time period during which the site is in use each day.

The ratio of access to static (e.g. HTML) and dynamic (e.g. JSP or servlet) content.

Duration and relative intensity of peak activity vs. normal.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 35 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05

Identification primary back-end systems (legacy apps, data sources) to be integrated.

Number of read-only versus update interactions with back-end systems.

Size of read-only interactions in terms of number of tables, rows and bytes.

Size of update interactions in terms of number of tables, rows, columns and bytes.

Number of read-only or update interactions in a typical visit.

Target number of transactions per second.

Usage, size and update frequency of session state information to be managed in the
middle tier.
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 36 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
Appendix C - References
C.1. Essential IBM Whitepapers and Technical Articles
The following individual articles are particularly useful, and form the basis for much of this
document:
C.1.1. Performance and Scalability
Harvey Gunther, WebSphere Application Server Development Best
Performance and Scalability
http://www-4.ibm.com/software/webservers/appserv/ws_bestpractices.pdf
Practises
for
C.1.2. EJB
Choosing the Right EJB Type: Some Design Criteria
By Kyle Brown
http://www7.software.ibm.com/vad.nsf/Data/Document2361?OpenDocument&p=1&BCT=3
&Footer=1
EJBs and Transaction Management in WebSphere Advanced Edition
http://www7.software.ibm.com/vad.nsf/Data/Document2357?OpenDocument&p=1&BCT=3
&Footer=1
C.1.3. Servlet
Large-Scale Servlet Programming
Large-Scale Servlet Programming – contains details of state management options in the
application server layer
http://dbsd01.boulder.ibm.com/wsdd/library/techarticles/0011_brown/0011_brown.html
URL Handling
An overview of the three “RequestDispatcher” objects available to Web Applications to
construct responses, and how they handle URL context:
http://www7.software.ibm.com/vad.nsf/Data/Document3722?OpenDocument&p=1&BCT=1
Application Packaging And Classpaths
Article discussing where to put utility code, including a WSAD plug-in tool to automatically
link a Java Project with a .jar file stored in an Enterprise Project .ear file:
http://www7b.boulder.ibm.com/wsdd/library/techarticles/0112_deboer/deboer2.html
Article discussing in detail the organization of class loaders in WebSphere:
http://www7b.boulder.ibm.com/wsdd/library/techarticles/0112_deboer/deboer.html
Infocenter
http://www-4.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/
C.2. Essential Public Articles
C.2.1 EJB
Container Managed Persistence Performance
Some CMP Performance issues explained by Billy Newport gives another overview of EJB
performance issues at:
http://www.ejbinfo.com/WebSphere/00/08/26/1236233.shtml
Stateful Session EJBs: Beasts of Burden
By Tyler Jewel gives a very good overview of the capabilities of different EJB types, and why
Stateful Session EJBs can be more trouble than they’re worth:
http://www.onjava.com/pub/a/onjava/2001/10/02/ejb.html
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 37 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
C.3. Essential Redbooks
WebSphere 4 AD Handbook (SG246134)
The WebSphere 4 Application Development Handbook is essential reading for any
development personnel involved in a WebSphere projects
http://publibb.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/55c2a771edaeb36c
88256a45005df84b?OpenDocument&Highlight=0,SG246134
WebSphere 4 AE Handbook (SG246176)
The WebSphere 4 Advanced Edition Handbook is essential reading for any administrators,
installation and configuration personnel, including operational architects.
http://publibb.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/bb605abea7c2a161
85256b34000340b5?OpenDocument&Highlight=0
J2EE Programming in WebSphere (SG246124)
http://publibb.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/c5052fb03e20c32a
88256a31007e4049?OpenDocument&Highlight=0
WebSphere Scalability: WLM and Clustering Using WebSphere Application Server
Advanced Edition (SG246153)
http://publibb.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/d58650c5b9226e4
98525687e004fc9db?OpenDocument&Highlight=0
IBM WebSphere Advanced Edition Scalability (SG246192)
http://publibb.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/ff31072025dcf5de8
5256aca00781918?OpenDocument&Highlight=0
C.4. Sun
Index to Sun-maintained J2EE Design Patterns and Architecture Guidance
http://java.sun.com/blueprints/
Design Enterprise Applications with the J2EE Platform
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/index.html
Sun Java Coding Guidelines
http://www.java.sun.com/docs/codeconv
“Seven Rules for Entity EJBs”
http://developer.java.sun.com/developer/technicalArticles/eBeans/sevenrules/
C.5. IBM Resource Sites
VisualAge Developer Domain
http://www7.software.ibm.com/vad.nsf
WebSphere Developer Domain
http://www7b.boulder.ibm.com/wsdd/
WebSphere Whitepapers
http://www-4.ibm.com/software/webservers/appserv/whitepapers.html
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 38 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
Public IBM newsgroups
news://new.software.ibm.com
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 39 of 40
J2EE Design Guidelines for Websphere (P7L)
Release date: 07/03/05
C.6. Useful IBM Tools
JInsight
Java performance analyser
http://www.alphaworks.ibm.com/tech/jinsight
WebSphere Log Analyzer
Analyse and troubleshoot log files
http://www-4.ibm.com/software/webservers/appserv/tools_intro.htm
WebSphere Resource Analyzer
Inspect live performance characteristics
http://www-4.ibm.com/software/webservers/appserv/download_ra.html
WebSphere Studio Page Detailer
Analyse page response time in terms of WebSphere components (e.g. servlets, JSPs etc.)
http://www-4.ibm.com/software/webservers/studio/download.html#pd
C.7. Third Party Resource Sites
The Server Side
Major public site hosting technical articles, reviews, discussion groups
http://www.therserverside.com/
EJB Info
Technical articles, reviews, discussion groups
http://www.ejbinfo.com/
Apache
Co-ordinating many open source Java, J2EE and XML development projects
http://www.apache.org/
JSP Tag Library
Contains tutorials and links to third party JSP tag libraries
http://www.java.sun.com/products/jsp/taglibraries.html
Sun Java Developer Connection
http://developer.java.sun.com/developer/
C.8. Useful Third Party Tools
JUnit testing framework
http://www.junit.org/
Log4J
http://jakarta.apache.org/log4j/docs/index.html
Apache Struts
http://jakarta.apache.org/struts/index.html
JDOM - XML Dom handling
http://www.jdom.org/
End of Document
Version No. 1.1
Copyrights & Trademarks
Infrasoft Technologies Limited
Page 40 of 40
Download

5 J2EE Architecture and Design Patterns Overview