1 / 24

Uncoupling Java Applications

Uncoupling Java Applications. O’Reilly Conference on Java Brett McLaughlin. Roadmap – the Meat. Introduction Engines User Store Validators Actions Screens. Introduction. JSP + Servlets + EJB + XML + JDBC + JNDI = !@$!%. Hype, Hype, and More Hype. The Grab Bag of APIs

mandar
Download Presentation

Uncoupling Java Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related