5 J2EE Architecture and Design Patterns Overview

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

W HO S HOULD U SE T HIS D OCUMENT ? ................................................................................... 5

2.2

W HEN T O U SE T HIS D OCUMENT ? ........................................................................................ 5

2.3

W HAT T O U SE T HIS D OCUMENT F OR ? .................................................................................. 5

2.4

O THER D OCUMENTS R EFERENCED ........................................................................................ 5

3 OVERVIEW AND SCOPE ................................................................................................. 6

3.1

D OCUMENT S UMMARY ...................................................................................................... 6

3.2

P RODUCTIONISATION C ONSIDERATIONS ................................................................................ 6

4 APPLICATION "PATTERNS OF USAGE" UTILISING J2EE ................................................ 7

4.1

C LIENT /S ERVER (U SER BASED ) P ATTERNS OF U SAGE ................................................................ 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

S ERVICE B ASED P ATTERNS OF U SAGE ................................................................................. 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

W EB C ONTAINER P ATTERNS ............................................................................................ 18

5.1.1

J2EE Model 1 Pattern (Web Page Navigation) ......................................................... 18

5.1.2

J2EE Model 2 Pattern (Controller Code Navigation) ................................................. 19

5.2

P ATTERNS FOR C OMMUNICATING B ETWEEN THE W EB AND EJB C ONTAINER ..................................... 21

5.2.1

Value Object Pattern ........................................................................................... 21

5.3

EJB C ONTAINER P ATTERNS ............................................................................................. 22

5.3.1

Facade .............................................................................................................. 22

5.3.2

Implementation of Business Components and Domain Objects ................................. 22

5.3.2.1

Characteristics of Reusable Business Components or Domain Objects ..................... 23

5.3.2.2

Characteristics of EJBs ...................................................................................... 25

5.3.2.3

Entity EJB Dependent Objects Pattern ................................................................ 25

5.3.2.4

Composed Business Objects Pattern ................................................................... 27

6 ORGANISATION OF J2EE IMPLEMENTATION WORK IN APPLICATION DEVELOPMENT

PROJECTS ......................................................................................................................... 30



Page 2 of 40


6.1

W ORKSTREAM D EPENDENCIES AND I SSUES ........................................................................... 30

6.2

S UGGESTED A PPROACH .................................................................................................. 31

6.3

C RITICAL ELEMENTS OF THE S OLUTION D ESIGN PHASE FOR J2EE APPLICATIONS ............................... 32

6.4

C OMMUNICATION P OINTS B ETWEEN D EVELOPMENT AND I NFRASTRUCTURE B UILD .............................. 33



Page 3 of 40


1 Document Information

Document Name:

Document

Identification:

1.

2.

J2EE Design

Websphere

P7L

Guielinesfor

Release

Date

Author

1.0 30-Apr-2004 Ranjay Shah

1.1 07-Mar-05 Alice Chettiar

Reviewer Reason for Change

Ajit Ganaptye Initial Release

Amita

Sawardekar

Change in logo and company name.



Page 4 of 40


2 Introduction

2.1

Who Should Use This Document?

 Applications Designers

 Application Implementers

When considering the use of a J2EE solution.

When researching J2EE features and options.

 J2EE Solution Architects When designing solutions using J2EE.

 Infrastructure community management In understanding the background behind application design decisions.

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 the design level guidance as well as the implementation standards and guidelines

2.4

Other Documents Referenced

 Java Coding Standards



Page 5 of 40


3 Overview and Scope

3.1

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

 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.

3.2

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)



Page 6 of 40


4 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.



Page 7 of 40


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.

Large scale (Enterprise): Core, widely and heavily used, system with high 5.

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)



Page 8 of 40


Complexity

Publishing

Static Web Publishing Dynamic Publishing

Ÿ HTML pages

Ÿ

Images

Ÿ

Documents

Ÿ Brochures

Ÿ HTML pages

Ÿ

JSP

Ÿ

Servlets

Ÿ Database Access

(Simple)

Forms-based Data

Maintenance

Application Development

Componentised

Development

(Departmental)

Large Scale

(Enterprise)

Ÿ HTML pages

Ÿ

JSP

Ÿ

Servlets

Ÿ JavaBean components

Ÿ custom tags

Ÿ

Database Access

(Update - Non

Transactional)

Ÿ HTML pages

Ÿ

JSP

Ÿ

Servlets

Ÿ JavaBean components

Ÿ custom tags

Ÿ

Database Access

(Update - Single

Database

Transactional)

Ÿ 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

Transactional Database

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:



Page 9 of 40


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



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.



Page 11 of 40


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.



Page 12 of 40


4.2

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.



Page 13 of 40


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.



Page 14 of 40


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



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.



Page 16 of 40


5 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



Page 17 of 40


5.1

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.

HTML layout with ability to execute code as the page is rendered (Java Server Pages)

2.

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.



Page 18 of 40


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



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.



Page 20 of 40


5.2

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.



Page 21 of 40


5.3

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



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



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.



Page 24 of 40


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.



Page 25 of 40


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



Page 26 of 40


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



Page 27 of 40


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).



Page 28 of 40




Page 29 of 40


6 Organisation of J2EE Implementation Work in Application Development

Projects

6.1

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.



Page 30 of 40


 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.



Page 31 of 40


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).



Page 32 of 40


 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.

6.4

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.



Page 33 of 40


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.



Page 34 of 40


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 management, access policies for existing 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.

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.



Page 35 of 40


 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.



Page 36 of 40


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 Practises for

Performance and Scalability http://www-4.ibm.com/software/webservers/appserv/ws_bestpractices.pdf

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



Page 37 of 40


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



Page 38 of 40


Public IBM newsgroups news://new.software.ibm.com



Page 39 of 40


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



Page 40 of 40

5 J2EE Architecture and Design Patterns Overview

J2EE Design Guidelines for WebSphere

(P7L)

Table of contents

2 Introduction

3 Overview and Scope

4 Application "Patterns of usage" utilising J2EE