J2EE Patterns

Slides by Igor Polevoy

October 30 2003

Pattern Definition
Pattern is a best practice solution to a common recurring problem Pattern describes a recurring problem Pattern describes a typical solution to the problem Patterns are collective knowledge Patterns are great vehicle to share knowledge with more people

Pattern Benefits
Provides a high level language for design discussions Provides a well tested solution for a common problem Helps provide some design work Combinations of patterns tend to provide for reusable architecture frameworks

Pattern History
Christopher Alexander: A Pattern Language 1977 Gamma, etc (Gang of Four, GoF): Design Patterns: Elements of Reusable ObjectOriented Software 1994

GoF Pattern Categories

Creational
Singleton Abstract Factory

Structural
Decorator Adapter

Behavioral
Strategy Chain of Responsibility

EJB Layer Patterns

Session Faade Message Faade EJB Command Data Object Transfer Factory Generic Attribute Access Business Interface

Example of J2EE Application

Fine-Grained Access Disadvantages

Increased network overhead Client needs to have intimate knowledge of server side components Data access, business and workflow logic scattered across client Tight coupling of clients and server components Transaction not managed, funds can be in the undefined state Poor people role separation Poor maintainability Poor reusability

Fine-Grained Access Solutions

Encapsulate all logic inside entity beans, have client make just one call
Disadvantages: tight coupling of business logic and data, lower level of component reuse

Transaction demarcation handled by client

If client is far away, transactions will run for long time, reducing overall performance of system Client needlessly complex Solves only data integrity problem

Session Faade Pattern

Faade Pattern (GoF) provides a unified interface to a set of interfaces in a subsystem. Faade provides a higher-level interface that makes it the sub-system easier to use Session Faade Pattern applied to J2EE only Session Faade provides a layer of abstraction to subsystem of session beans, entity beans and other components Hides server component complexity from client

Session Faade Pattern

Implemented as a layer of stateless beans (sometimes statefull) Provides a clean interface to execute business logic and workflow Separates complexity from client Provides for automatic transaction support Separates development roles From OO point of view provides for layer of abstraction and encapsulation

Session Faade Pattern

Before

Session Faade Pattern

After:

Session Faade Pattern

Solution:

Session Facade
Benefits:
Lower network overhead Separation of business logic from presentation Inherent transaction support Promotes reusability Looser coupling

Session Facade Dangers

Do not create a God Session Faade Do not put presentation logic into faade Do not use Session Faade as domain model, use it only as glue

Situation in Enterprise
Need to execute a number of session and entity beans in a context of the same transaction Immediate response is not required Client does not have to be required to wait end of execution

Situation in Enterprise

Solutions
Use Session Faade Pattern
Solves the following problems:
Coupling Performance Maintainability Data integrity

Does not solve:

Response time Reliability

Message Faade Pattern

Message Faade Pattern

Use a Message Driven Bean to create a reliable fault-tolerant faade Client should only send messages to JMS destination. They should not access session and entity beans directly

Message Faade Pattern

Solves:
Response time
Inherently by use of messaging

Reliability
If a transaction fails, then the MDB can push the message back into destination; the message will be re-delivered

Message Faade Pattern

Usage:
Do not put business logic into MDB Use Message Faade pattern together with Session Faade Pattern

Disadvantages:
Propagate results back to client Cannot perform compile time type checking

Command Design Pattern (GoF)

Used to encapsulate executable logic in command units Decouples application client component from domain model Used to provide undo/redo functionality

EJB Command Pattern

Goal: to decouple application client component from binding to concrete domain model objects Separate development roles in projects Simplify access to Session Faade Use command beans with set/get methods and execute method

EJB Command Pattern

EJB Command Pattern

Elements:
Command Beans Client side routing logic Command server

EJB Command Pattern

Benefits:
Easier to deploy the application (fewer session beans) Separates business logic from presentation Decouples application client component from EJBs Command can execute locally, produce fake data to facilitate independent development

EJB Command Pattern

Disadvantages
Primitive transaction control (limited by command server) Commands are stateless no easy way to access statefull beans Limited exception handling mechanism Command beans classes loaded into J2EE runtime no easy way to change functionality on the fly

Data Transfer Object Pattern

Data Transfer Object Pattern

DTO Factory Pattern

Problem with DTO:
DTOs change very often Entity beans need to be updated DTO consumption is unclear Business domain logic creeps into entity beans

Solution:
Place responsibility for creation/consumption of DTOs onto DTO Factories

DTO Factory Pattern

DTO Factory Pattern can be implemented as:
Simple java class Session bean

DTO Factory Pattern

DTO Factory Pattern

Benefits:
Changes in creation of DTOs are performed in DTO Factories, making entity beans more stable DTO Factory can create different views of the same data DTO Factory can create complex composite DTOs, which hold data from multiple entity beans DTO Factory can provide consumption of DTOs:
Application client will create a DTO, will set all necessary attributes, it will then pass it to DTOFactory.setXXXDTO() this will cause the factory to find appropriate entity beans ad call their respective set methods all in the context of one transaction

Multiple applications can reuse the same persistence layer as long as they provide DTO Factories with appropriate logic

DTO Factory Usage

DTO Factory Pattern Problems

Does not scale well with attribute number growth Entity bean clients are tightly coupled with entity bean interfaces Solution: Generic Attribute Access Pattern

Generic Attribute Access Pattern

Move attribute access logic from entity bean client to a generic attribute access class This class will provide access to attributes via Maps of attribute keys and their respective values

Generic Attribute Access Pattern

Attribute access is built into entity beans as implementation of AttributeAccess interface Such interface would be implemented by a remote or local interface and the beans itself
interface AttributeAccess { void setAttributes(Map attributes); Map getAttributes();//gets all attributes Map getAttributes(Set keys);//gets some attributes }

Generic Attribute Access Pattern

Generic Attribute Access Pattern

Benefits:
A BMP can hold its state in a Map, simplifying the GAA implementation No need to program DTOs Attribute access code can be shared by all beans in the system simplicity In CMP, Java Reflection API can be used for updates same code can be shared between all CMPs in the system (use a super class) Scales well for large number of attributes/beans One attribute access interface across all beans Allows for creation of generic clients

Generic Attribute Access Pattern

Tradeoffs:
Additional overhead: need to construct an attribute access call, need to cast the attribute value Need to maintain attribute contract No compile-time type checking

Generic Attribute Access Pattern

Recommendations:
Provide a well documented contract for attribute naming conventions Use Java Beans design patterns for naming conventions Can se static finals on bean classes for run time name checking Can use a shared interface that serves as a name binding contract:
Interface PersonBeanNames { public static final String firstName; public static final String lastName; public static final String ssn; . . . }

Business Interface Pattern

Create a business interface for a bean Extend it in the remote/local interface Implement it in the bean class

Data Transfer RowSet Pattern

Transfer relational data in a tabular format to client application If use DTOs you convert tabular data to OO (EJB), then back to tabular (HTML) Use JDBC + RowSet to transfer tabular data directly to client

Data Transfer RowSet Pattern

Advantages:
Can use the same generic client code to process all tabular requests Can use GUI automation (automatic rendering of ResultSet)

Tradeoffs:
No compile time checking Not OO Client may need to know DB structure (can be remedied by Session Facade Pattern)

Version Number Pattern

Problem:
Data read is performed in a different transaction then data update Hence danger of update on stale data Difficult to wrap read/write into the same transaction because of think time Data collision can happen

Version Number Pattern

Solution:
Use record (bean) version number Include version number into the cross tier transmission Send version number back for update along with any changed attributes Before update, validate version number Reject update if stale record is updated When update happen, increment version number

Version Number Pattern

Implementation
Depends on inter-tier transmission pattern Have legacy applications update data through J2EE persistence layer; if impossible, write DB triggers that update version numbers

JDBC For Reading or Fast Lane Reader Pattern

Problems accessing entity beans for reading:
N+1 DB read problem Network overhead for multiple calls Join operations are difficult

JDBC For Reading Pattern

Solution:
Use straight JDBC for read operations Use CMPs for update operations Use in conjunction with other patterns

Benefits:
No transaction dependency DBMS cache mechanism used Simple to join data

Tradeoffs:
Bug prone No compile time type checking Tight coupling of client and persistence layers

Data Access Command Bean Pattern

Without DACB, session beans access entity beans and JDBC directly Problems:
Tight coupling between session layer and persistence implementation Data access logic mixed in with business logic Session bean layer is dependent on schema changes High potential for copy/paste style code reuse

Data Access Command Bean Pattern

Encapsulate persistence logic into Bean Command classes Bean Command interfaces provide a layer of abstraction from concrete implementation of persistence layer Similar to EJB Command Pattern Differences from EJB Command Pattern:
DACB provides transparent interface to EJBs, JDBC, ObjectStore, etc (as opposed to session bean layer) Serves as insulation layer between Session Beans (facade) and concrete persistence implementation Semantically models data closer

Data Access Command Bean Pattern

Data Access Command Bean Pattern

Data Access Command Bean Pattern

Data Access Command Bean Pattern

Benefits:
Provides a clean abstraction layer for data store Usable in any tier Decouples business logic from storage logic Facilitates independent development if dummy commands are used

Disadvantages:
Extra work for developers

EJBHomeFactory Pattern (Service Locator Pattern)

Problems:
Client has repetitive code for lookups of home interfaces Each time the lookup is done, a potential network call is performed

EJBHomeFactory Pattern
Solution:
Provide a factory class, which encapsulates all of the lookup code, and potentially caches home interfaces Usually implemented as Singleton Example:
Account acc = BusinesInterfaceFactory.getInstance().getInterf ace(com.acme.Account.class);

All of the factory parameters for JNDI lookups are stored in the configuration of a factory.

EJBHomeFactory Pattern
Can be used in conjunction with Abstract Factory Pattern to make creation of business interfaces completely transparent to client code

Business Delegate Pattern

Problem:
When client uses a session faade or other interface to J2EE logic, there is a tight coupling between application client components and EJBs Programming directly to EJB layer in not the best way
Clients need to be aware and handle transaction J2EE exceptions Complicates client logic with EJB exception handling Couples client directly to EJB or JMS (message facade) APIs

Business Delegate Pattern

Solution:
Create a layer of abstraction that insulates application client components from handling service discovery, complex exception handling and recovery A Business Delegate is a plain Java class that usually maps to session faade one to one

Business Delegate Responsibilities

Delegate requests to session faade or message faade Hide EJB API exceptions behind application level exceptions May cache data locally May retry failed requests transparently to client Assists in large projects if dummy business delegates are used to asynchronously develop client and server functionality

Pattern Categories
EJB Layer
Session Faade Message Faade EJB Command Data Transfer Object Factory Generic Attribute Access Business Interface DTO Data Transfer HashMap Data Transfer RowSet Version Number JDBC for Reading Data Access Command Bean Dual Persistence Entity Bean (CMP/BMP) EJB Home Factory Business Delegate

Inter-tier data transfer

Transaction/persistence

Client-side EJB Interaction