Uncoupling Java Applications

1. Uncoupling Java Applications O’Reilly Conference on Java Brett McLaughlin

2. Roadmap – the Meat • Introduction • Engines • User Store • Validators • Actions • Screens

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

4. Hype, Hype, and More Hype • The Grab Bag of APIs • The “Use It or Lost It” Mentality • Your Responsibility 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?

5. 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.

6. Management, Maintenance, and Modularity • Management: Delivery Focused • Maintenance: Stability Focused • Modularity: A Marriage of the Two Maintenance Management Less More Functionality “Graph”

7. Engines Request  Engine  Response

8. 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

9. 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…

10. User Store userData = UserData(req); userData.setParam(“myParam”, myValue); ... userData.clearVolatile();

11. 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

12. 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.

13. 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)

14. Validators <field name=“firstName” type=“text”> <minLength>4</minLength> <maxLength>20</maxLength> </field>

15. 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

16. 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

17. 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

18. Actions action = ActionLoader.getInstance().load(actionName); action.init(userData); action.execute();

19. 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

20. 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

21. Screens screen = ScreenLoader.getInstance().load(screenName); screen.init(userData); screen.output();

22. 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

23. 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

24. Q & A