J2EE Development

1
J2EE Development DesignJAOO 2001

• Karl Avedal (karl_at_ironflare.com)
• Ironflare AB, Orion Application Server

2
J2EE Development DesignJAOO 2001

• Introduction
• J2EE concepts
• Design models
• Component overview
• Common patterns
• Questions

3
J2EE Concepts

• J2EE Components
• JSPs/Servlets/Filters/Tag extension libraries
• EJBs
• Clients, (Applets)
• J2EE Modules
• Web applications, EJB JARs, Application-clients
• J2EE Applications
• Constructed from different J2EE modules
• Everything is part of an application!

4
J2EE Applications
5
Application Design

• Why is everyone talking about design? I thought
  J2EE solved that
• Just because someone knows how to develop an EJB,
  it doesnt mean that the EJB will be the best
  solution
• If the design is bad, J2EE will not help, it will
  most likely make the solution much worse

6
Application Design

• Historic model (circa 1998)
• Servlets using JDBC 1.x
• HTML and SQL sprinkled around in a Java class
• Proprietary solutions for common problems
  (database pooling, etc.)
• Or (after the introduction of JSP)
• JSPs using JDBC 1.x
• Lots of Java code and SQL sprinkeled around in
  HTML

7
Application Design

• First seperation attempt
• JSP -gt Java Beans -gt JDBC
• Encapsulates (most) logic in beans
• Still SQL in Java code and often much logic left
  in JSPs

8
Application Design

• Further separation
• JSPs with logic in servlets
• No or little Java code in JSPs, servlets invoked
  over HTTP, which fits better with JSP
• HTTP Servlets are web-centric, no point to put
  logic in a web-specific layer

9
Application Design

• Enter EJBs
• JSPs/Servlets -gt Session beans
• Poor separation, but help with certain services,
  not persistence however
• No longer just web applications, both web clients
  and application clients can access the same
  server logic

10
Application Design

• Entity Beans
• JSPs/Servlets -gt Session beans -gt Entity beans
• Getting rid of persistence code (SQL)
• Database independence
• Automatic data caching
• Declarative transactions
• Separation still poor

11
Application Design

• Tag extensions (Taglibs)
• JSPs/Servlets -gt Taglibs -gt Session beans -gt
  Entity beans
• JSPs fit for presenting HTML or XML. Presentation
  details can be done using CSS or XSL.
• Tag extensions is a natural way to interface with
  other pieces from HTML. The tag extensions become
  business delegates
• Servlets are nice for providing non-text output

12
Application Design

• Tag extensions (continued)
• Session beans acts as facades, encapsulating
  business logic
• Entity beans encapsulate persistent data, but
  doesnt need to contain actual persistence code
• Servlet filters can be used to add front
  functionality
• MessageDriven Beans and JMS extend the model
  further
• Perfect? No
• Navigation layout often in JSPs, good or bad?

13
Application Design
14
Application Design

• Front controller (Model 2)
• A controller servlet dispatches requests to
  appropriate action objects.
• Still uses JSPs with tag extensions for
  presentation
• Servlet is always first access point to separate
  view from page flow
• Frameworks based on this
• Struts http//jakarta.apache.org/struts/
• WebWork http//sourceforge.net/projects/webwork/
• Push vs Pull models
• Does the control push data to the view or does
  the view pull data from the model?
• Struts and WebWork are based on Pull

15
Application Design
Servlet (Controller)
Write
Request
Data (Model)
Browser
Forward
JSP Presentation (View)
Response
Read
16
J2EE Components

• Every component type has its intended use
  (Important!)
• Try not to have a favourite component type that
  you use for everything
• When developing for fun, use a certain component
  type just for the sake of trying it out
• Of course, when you do things for real, never add
  complexity just for the sake of it

17
J2EE Components

• JSPs
• Presentation oriented
• Markup langauge layout
• Do not
• Add scriptlets with Java code to JSPs
• If it can't be done with tags it shouldnt be in
  the layout

18
J2EE Components

• Servlets
• Request/response oriented
• HTTP Servlets
• Centered around HTTP methods
• Good for
• Generating non-text responses like graphs,
  downloads
• Not as good for
• Outputting HTML
• Serving as generic action classes

19
J2EE Components

• Servlet Filters
• Allows you to
• Intercept a servlet's invocation before the
  servlet is called
• Examine a request before/after a servlet is
  called
• Modify the request headers and request data
• Modify the response headers and response data
• Advantages
• Loose coupling with application
• Reuse

20
J2EE Components

• Tag extensions
• Allows you to define custom tags for JSPs and
  associated actions
• Use as business delegates for JSPs to access
  business logic
• Do not try to build a new programming language
  using tags
• Reuse standard tag libraries

21
J2EE Components

• Session beans
• Central place for business logic
• Use as façade for Entity beans
• Stateful or stateless
• Consider what state you keep in your sessions
• Use declarative (Container managed) transactions.
  Keep transactions short

22
J2EE Components

• Entity Beans
• Keep business logic not directly associated with
  the entity out
• Use CMP whenever possible!
• Do not try to reinvent every optimization the
  Container does for you.
• Database neutral application
• If possible, use JDBC 2.0 compliant DataSources
  to avoid emulation and dirty connections
• Should all entity bean access be indirected via
  session beans?

23
J2EE Components

• MessageDriven Beans
• Asynchronous business processes
• Missing piece pre-EJB 2.0
• Bridge into the EJB space

24
J2EE Components

• Application-clients
• Never demarcate transactions from
  application-clients
• Network latency, network failures
• Not required feature in J2EE containers

25
Common Applications

• How to identify common problems?
• One way is to indentify common applications

26
Common Applications

• 1. Content (cnn.com, yahoo, Documentation
  management systems)
• Read-mostly data, controlled updates, bulk
  updates, searching
• 2. Personal Services (Online brokers, Travel
  booking)
• DB intensive, transactional, client state,
  security
• 2b. Matching Services (Ebay)
• Same basic challenges as 2
• 3. Group Services (Slashdot, Notes)
• Read-mostly data, uncontrolled updates
  (long-running pseudo-transactions)

27
Common Designs/Patterns

• Read-mostly data
• Entity bean caching
• Proprietary ways to mark no-modification, use
  them
• Facilitate fragment caching
• Long lived pseudo-transactions
• Read for a long time, update old data
• Pessimistic vs optimistic locking
• What fits your application?

28
Common Designs/Patterns

• Bulk updates of read-mostly data
• Proprietary cache timeouts, cache invalidation
• Client state
• Clustering
• Scalability
• Stability
• Where to put state
• Stateful and stateless business processes

29
Common Designs/Patterns

• Security
• Use built-in mechanisms
• Underspecified area
• Proprietary solutions for plugging into security
  systems
• Servlet filters

30
Common Designs/Patterns

• Presenting search results
• Value lists
• Scrollable result sets
• Lazy fetching of the actual data in the container
  might help, but doesnt eliminate problem
• Ugly non-portable solution Write your own SQL
  for the finders
• Somewhat more portable solution Searcher Session
  bean
• Missing feature in J2EE

31
Summary

• Let the container do what it can, whenever it can
  help!
• Let the components do what they are meant for
• High level of abstraction leaves more room for
  optimizations done by the server
• Dont fight the platform
• Keep an open mind, refactor
• Prepare for change

32
Summary

• Test with many J2EE containers, make deployment
  choice late
• Find information, this is just an introduction
• Find the right tools
• Amazing IDEA from Intellij (www.intellij.com/idea
  )

33
Other Sources of Information

• http//java.sun.com/j2ee
• http//www.theserverside.com/patterns
• Close to 50 pattern threads
• Core J2EE Patterns (Alur, Crupi and Malks)
• Design, Refactorings, Pattern Catalog

34
Questions (and answers?)