j2ee - best practices

Implementing Business Objects Consider the use of a standard interface BusinessObject for business objects  Provides consistency across objects  Property management, formatting, conv

Architecture Strategies and Best Practices for Server-Side

J2EE Development

Darren Broemmer

Guiding Principles

Elements of Transactional, Based Business Applications

Web- Business applications share many

 The reference architecture is based on a

mapping of this analysis to J2EE

The Structure of Business

Applications

Business Entities

 The ‘things’ a business deals with

 Range from high-level entities such as Customer

down to lower-level entities such as Purchase Order

Business Processes

 The processes used to carry out the work of the

business

 Defined workflow

 Involve business entities as participants

 Need to be executed in a secure manner

User Interaction

 Providing users access to services and

processes

 Application presentation (i.e HTML/XML over HTTP)

 Access to business functions and services

 Static and dynamic content

 Screen flow, or page navigation

 Forms processing

 Error handling

 Includes user interface, interaction with web

service clients, etc.

Reference Architecture (PIM):

Realization of Bus App Analysis

Usage of Design Patterns

 Patterns provide a foundation of proven,

reusable solutions

 Model-View-Controller (MVC)

 GoF Design Patterns

 Sun’s Core J2EE Patterns

 Reference architecture is largely defined by the

interaction of a number of design patterns

 Variations of many existing patterns as applied to

J2EE

Architectural (or Large-Scale)

Design Patterns

 Layered Architecture

 Logical software layers that isolate and modularize

responsibilities

 Building-block type approach that requires only

knowledge of adjacent level directly below given layer

 Model-View-Controller (MVC)

 Proven object-oriented pattern used for applications

with graphical user interfaces

 Separation of concerns between content,

presentation logic, and business logic

 Common functions can be automated (i.e Struts)

Reference Architecture

Mapped to J2EE

Automating Common Functions

 From the analysis of transactional,

web-based business applications:

 Common characteristics can be implemented

through configurable, extendible foundation

components

 A Business Logic Foundation (BLF) enables:

 Higher level of quality

 Consistency

 Less duplication of effort, faster development times

Metadata-Driven Components

 Metadata is input to automated, configurable

common functions

 Run-time libraries

 Development-time code generation

 Industry trend is evident

 Most component architectures are defined in part by

metadata (EJB, Struts, O/R mapping tools, etc.)

 Most UML design tools now support XMI (XML

Metadata Interchange)

 JSR-40 – Java Metadata Interface (JMI)

 Complementary to MDA (Model-Driven Architecture)

Performance and Scalability

 Java, the language itself, starting to approach C/

C++ performance, particularly on server side

 Due to aggressive Just-In-Time (JIT) compilers

 Enterprise Java services, however, add another

level of overhead

 Must weigh the benefits vs the performance costs

 Example: Entity Beans not ideal for fine-grained

business objects

 Performance must be considered from the beginning

of the architecture discussion

Implementing Business Objects

 Consider the use of a standard interface

BusinessObject for business objects

 Provides consistency across objects

 Property management, formatting, conversion

 save(), validate()

 Allows other components to generically deal with

business objects

 Helpful in reusable services/workflow components

 Example: Generic update service

 Base class implementation of interface can provide

common foundation logic in one place

 Can be configurable through metadata generated from design models

Business Object Interface

 public interface BusinessObject {

public void setProperty(String propertyName,

Object value) throws PropertyException;

public String getProperty(String propertyName) throws PropertyException;

public BigDecimal getDecimalProperty(

String propertyName) throws PropertyException;

public Date getDateProperty(

String propertyName) throws PropertyException;

// other property methods

public void save() throws BlfException;

public void validate() throws BlfException;

}

Class Diagram for Business

Object Implementation

Benefits of Common Business

Object Interface & Base Class

 Standardize property management, relationship

management, validations, etc.

 Property level validations

 Required field checking

 Endless possibilities to what business object

metadata can be used to drive processing

 Development of standard, reusable property

‘handlers’ for each data type

 Extensible: Allows for creation of user defined types such as Social Security Number property

 Handles validation, formatting, and type conversion

 Configurable through metadata

Property Handler Mechanism

Property Handler Interface

public String convertToStringFormat(

Object value) throws CommonException;

public Object convertToObjectFormat(

Object value) throws CommonException;

public String convertToDisplayFormat(

Object value) throws CommonException;

public void validateProperty(

BusinessObjectPropertyMetadata pm,

Object value) throws CommonException;

}

Configuring Property Handlers

 Can use metadata to configure property

handlers and subclasses of

Configuring Business Objects

 Business object properties are given a

 public void setProperty(String propertyName,

Object value) throws PropertyException {

 public String getProperty(String propertyName)

throws PropertyException {

try {

// Get the member variable value as an object

Object obj = PropertyUtils.getProperty(

this, propertyName); // Convert the object to a string using the

// property handler mechanism

Additional Uses of Metadata

 Ex Required field checking

 <Property name=“accountNumber”

type=“String”

required=“true” />

 Add validateRequiredFields() method to

BaseBusinessObject as part of validate template

 Many other possibilities

 Range checking, valid values, regular expressions,

display masks, etc

 Metadata is input into property handlers (i.e

NumericRangePropertyHandler)

Value Objects and Lightweight

Business Objects

 Value object (Data Transfer Object)

 Same property management methods, can use

similar interface as BusinessObject

 Can share same property management framework

 Business object can then add bulk getter/setter

methods

 Void setProperties(ValueObject inputValues);

 ValueObject getProperties();

 Implementation Options

 BO & VO as separate object hierarchies

 BO interface extends standard VO interface

 BO implementation classes extend

BO & VO Class Diagram

Object Validation and Error

Handling

 Types of validation & implementation

 Data Type (ex Characters in numeric field)

 BO, VO Base class – validate, setProperty

 Required field checking

 BO, VO Base class – validate

 Application specific field level (ex SSN property)

 Reusable PropertyHandler mechanism

 Object-level (ex account balance > $50)

 Business object methods or validate template

 Cross-object level (ex Inactive account can’t post

transactions)

 Business object or workflow

// Base class implementation empty

public void blfValidate() throws BlfException {

}

Error List Utility

 Use a consistent ErrorList utility to:

 Manage a list of business and info errors

 Integrate errors with user message templates

 Associate errors with properties if applicable

 Report whether errors warrant a transaction

rollback

 Integrate error management with

transactions, logging, page navigation, etc.

Exceptions and Error Handling

 Can use a ValidationException class to

communicate business errors from a method

 Map system level exceptions to defined,

user-friendly business errors

Application Exception Hierarchy

The “Save” Template

 Part of standard BusinessObject interface

 May or may not include actual persistence (for

example, CMP Entity Beans)

 Typically used for the following purposes:

 Property and object-level validation integrated with

transaction management

 Manipulation of aggregated objects

 Pre-save business logic

Save Template Code

(CMP Entity Bean)

 public void save() throws BlfException {

// Initialize the error list for theobject

Managing Aggregated Objects

 Parent business object often responsible

for:

 Providing accessor methods

 Can add standard methods to BusinessObject interface

 Cascading validation and persistence

 A “Save” template

 Cascading deletes

Configuring Aggregated Objects

</BusinessObject>

Business Object Creation and

Instantiation

 Consider use of a consistent Factory

mechanism

 Same abstraction whether you use Entity

Beans, Java Objects, or something else.

 Provides template hooks for creation and

deletion business logic

 Simplifies client code

 Can encapsulate optimizations

 Caching EJB Home interfaces

Business Object Factory Class

Diagram

Object Collection Services

 Consider using a utility class to manage

data retrieval and selective updates

 Consistent, effective list management

 Data retrieval as lightweight value objects

 Smart instantiation of business objects,

particularly Entity Bean implementations

Object List Class Diagram

Business Objects:

Design Considerations

 Entity Beans vs POJO

 Plan for potential migration

 EJB as a component wrapper

 Standard business object factory

 EJB 2.0 provides potential for much improved

performance

 Container optimizations enabled through abstract

persistence schema

 Aggressive and lazy-loading strategies

 Optimize unnecessary read/writes down to property

level

Use of Entity Beans

 Perform load testing early for proposed solutions

 Look for continued improvements in CMP engines

from vendors via abstract persistence schema

 As a general rule, consider POJO for:

 Extremely high-throughput applications

 Fine-grained business objects

 Large number of business objects in typical transaction

 Use Entity EJBs where they provide the most

value

 Standard component services and deployment

 Plan for a potential migration if need be

Service-Based Architecture

 Process-oriented objects & components

 Used to manage workflow and coordinate multiple

business objects in a transaction

 Reduces coupling between web and EJB tiers

 Limits RMI and network overhead

 Distributes business functionality through standard,

service-like interface

 Utilizes most efficent EJB, the SLSB, to take

advantage of container managed services

 Provides potential for common base class to

generically manage security, logging, audit trail, etc

Using the Session Bean as a

Component Wrapper

The Service Interface

 Explicit vs Generic Interfaces

 Type-safety/readability vs flexibility

 Standard interface allows for automation of

front-end processing

 Packaging request data and service invocation

 Can chain service calls together

 ServiceData class used to encapsulate request

 Input, output, and error data

 Data type options include argument list (name/value pairs), value objects, XML, etc.

Service Component Class

Diagram

 Generic, reusable services

 Controller pattern in service components

 Object-centric services

 Workflow-type services

 Service chaining

User Interaction Architecture

 4 Key Abstractions, 8 Core

Responsibilities

8 Core Web UI Controller

Responsibilities

 Basic flow of Controller (MVC) Architecture

 Determine user event and appropriate action

 Create the event object

 Invoke the appropriate action class

 Perform application validations/handle errors

 Invoke application services and handle errors

 Manage the user context

 Determine the next page

 Forward the request to the next page

Overall Architecture with Jakarta Struts MVC Framework

User Interaction Best Practices

 Use a generic, extendible MVC implementation

such as Jakarta Struts

 Use a template mechanism

 Minimize or isolate scriptlets in JSP

 Use JSP custom tag mechanism

 Reusable UI components (vertical and horizontal)

 Integrate with Business Logic Foundation

 Can extend Struts/JSTL tags

 Minimize the size of the HttpSession

 Consider the alternatives

Further Info

 “J2EE Best Practices: Java Design

Patterns, Automation, and Performance”

Darren Broemmer, Wiley 2002.

 http://www.broemmer.com/j2ee

 Email: darren@broemmer.com