J2EE Patterns considerations

Front end design considerations

Session state on client

• only good for small amounts of data
• avoids problem of replicating data across servers

Implementation

• HTML hidden fields
• HTTP cookies
• URI encoding

Problems

• Expose state/information to client
• Data must be encoded as text
• performance of large quantities of data

State on server

• identify with session id
• expire state on server shutdown/timout/explicit removal

Multiple front end options

• replicate state
• use server affinity
• store state on business tier/resource tier

Controlling access

Embed guard in a view

• Deny access to entire page (embedded guard tag only reasonable for few pages)
  • use a central controller instead
• Deny access to portion of page
  • wrap restricted section in a tag

Guard by configuration

• use features of servlet spec (2.2 but 2.3 more consistent) configure in web.xml
• supports part view and entire view
• unassigned = no direct access - may still forward to these pages
• prevent direct access - put page in WEB-INF directory

Duplicate form submission

• use controller servlet
• synchroniser - deja-vu token
  • set token in session and in page
  • submitted token must match session stored token

Validation

• Don't rely on client side checks - scripting may be turned off / circumvented

Server side

• form based - typically duplication of code
• abstract types - separate validation model from application logic
  • typically use metadata + constraints e.g. properties file
  • may be slower and more complex - harder to maintain
  • e.g. use factory for creating validators and xml config file

Helper properties

<jsp:setProperty name="bean" property="*"/>

• Sets matching name & type to value automatically
• Does _NOT_ set empty or null values => may need to manually clear
• Check boxes only set items set => may need to manually clear

Business tier design considerations

Storing state

• If all traffic via web interface - state may be stored in web server
• If via web & thick client - consider state in middle tier
• Consider clustering, server affinity, replication, persistence, traffic management

Session beans

• dedicated to a single client
• lives for duration of client
• transient - lives with the container - not persisted
• can time out
• can participate in transactions
• can be stateful or stateless

• stateless - bean available as soon as method completes
• Scalability issues typically due to miss application of stateful/statless beans
  • use stateful for instances requiring conversation
  • multiple calls resending/persisting state is often the wrong design

Control code in multiple views

=> changes impact multiple pages

• Consolidate controle code
  • introduce controller
  • localise disparate logic

For similar control in multiple places

• view helper
• guarding a view

Don't allow presentation tier objects into business tier

• copy state into generic object to share
• similarly for domain objects

Fat Controllers

Too much logic in one place

• factor out - delegate - use helpers

Helpers as scriptlets

• try and create interfaces that expose intent - meaning (e.g. using custom tags)

Entity beans

• best suited to coarse grained logic
• mapping to persistence data
• transactional
• multi threaded
• long lived
• App server provides: scalability, security, clustering
• composite key
  • must create separate object to represent key - serialisable
  • attributes must be public - match name and type of entity bean
  • should override equals and hash