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

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 MaintenanceManagement Functionality “Graph” LessMore

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

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