Uncoupling Java Applications

O’Reilly Conference on JavaBrett McLaughlin

Roadmap – the Meat Introduction Engines User Store Validators Actions Screens

Introduction

JSP + Servlets + EJB + XML + JDBC + JNDI = !@$!%

Hype, Hype, and More Hype

When do I use JDBC and when do I use EJB?Does JSP truly provide a separation of content and logic?Is XML right for my application?One engine? Two engines? (Red engine? Blue engine?)

Am I asking the right Questions?

The Grab Bag of APIs The “Use It or Lost It” Mentality Your Responsibility

All the Abbreviations != Solid Application

The truth about: JSP XML (XSL, XSLT, XSP, and all the rest…) JDBC EJB

You dictate technology; Technology does not dictate you! Management doesn’t know or care about how “cool” your use of

technology is.

Management, Maintenance, and Modularity

Management: Delivery Focused Maintenance: Stability Focused Modularity: A Marriage of the Two

Maintenance Management

Functionality “Graph”Less More

Engines

Request Engine Response

Building a Generic Engine HTTP and the Request/Response Model The Servlet API

Abstracts Details of Network Communication Access to Session Variables and Objects Responsiveness to a Variety of Responses

Easy Interface with other Java Specifications (EJB, JDBC, RMI) Why JSP Doesn’t Work

Using a Central Controller Single Point for all Requests Request Parameters and POST

Disguises Request Information Allows use of Hidden Fields and Variables Additional Security Mechanism

Provides Continuity in Application Requests Request generates Response, which generates Request… and on…

User Store

userData = UserData(req);

userData.setParam(“myParam”, myValue);

...

userData.clearVolatile();

A Flexible Data “Connector”

How to handle data across contractual objects Code Tying Objects Together (tight coupling) Specific Object Types for Specific Implementations (semi-tight

coupling) Generic Data “Connector” Across All Implementations (loose

coupling) Also Adds Persistence of Data Across Requests

Loading at Request Time The User Store is Always Created/Loaded

Load From the Session, Update from the Request Create from the Request

Request Parameters Available No Differentiation Between Original and Added Request Parameters Generic Object Allows Generic Contracts Results in Logical Groupings, Not Code-Based Ones.

Storing at Response Time The User Store is Always Stored

Purge Request and Volatile Data Store in the Session Object

Allows Process Lifecycle Continuity Preserves Persistent Data

Authentication Credentials Application Preferences Complex Derived Data Remote References (Persistence Load-Balancing)

Validators

<field name=“firstName” type=“text”>

<minLength>4</minLength>

<maxLength>20</maxLength>

</field>

Balancing the Teeter Totter

Coarse Grained Validation (+) Allows Generic Interfaces and Implementations (-) Never Provides Sufficient Validation for Business Rules

Fine Grained Validation (+) Very Specific and Ensures Correct Business Information is Present (-) Requires Specific Implementation for Every Possible Request

Coarse Grained Validation Configuration File Based

Properties Files, ala Java Hierarchical Files, ala XML

Single Implementation Set Handles All Requests Provides “first-run” Error and Mistake Catching Allows Short-Circuit of Complex Business Logic if General Rules Not

Followed

Fine-Grained Validation Code Based

Sometimes Within Java Code Sometimes Within Configuration Files

Tied to a Specific Business Process (Action) 1:1 Mapping Between Implementation and Task

Provides Complex Error Handling Business Logic Inherent to Process, so no Short-Circuiting Occurs

Actions

action = ActionLoader.getInstance().load(actionName);

action.init(userData);

action.execute();

What are Actions? Contract Based Request Handlers Business Logic Assemblers

Do Not Replace EJB, JDBC, etc. Do Replace Spaghetti Code

Abstraction of Interface to Business Components Engine has no Information about Communication Mechanisms (JNDI, RMI, etc.) Logic Changes without Engine Calls Changing

Use of Actions Loading

Generic Loader from Action Name Name Action Mapping in Files or Database

Initializing One Application Engine always uses Same Initializing Object Type (UserData) Isolates Execution from Application Logic

Execution Return Result Based on Application Logic, not Business Logic Loads any Screen-relevant Information to UserData

Screens

screen = ScreenLoader.getInstance().load(screenName);

screen.init(userData);

screen.output();

What are Screens? Contract Based Response Handlers Display Logic Assemblers

Do Not Replace XML, HTML, etc. Do Replace Hard-Coded Markup Language

Abstraction of Interface to Visual Components Engine has no Information about Markup Language(s) (HTML, XML, WML, etc.) Output Changes without Engine Calls Changing

Use of Screens Loading

Generic Loader from Screen Name Name Action Mapping in Files or Database

Initializing One Application Engine always uses Same Initializing Object Type (UserData) Isolates Output from Application Logic

Display/Output Return Based on Use of Output (e.g. Cocoon) Retrieves Needed Information from UserData

Q & A