Uncoupling Java Applications O’Reilly Conference on Java Brett McLaughlin
Mar 31, 2015
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