J2EE Architecture and Design Patterns - Northwestern Polytechnic ...


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

J2EE Architecture and Design Patterns - Northwestern Polytechnic ...

  1. 1. J2EE Architecture and Design Patterns Student: Fang Fang Advisor: Dr. Glen Qin Date: 05/14/2005
  2. 2. Agenda <ul><li>Introduction to “Architecture” </li></ul><ul><li>J2EE Architecture Diagram </li></ul><ul><li>Distributed Programming Serviced </li></ul><ul><li>Modular-Based Development </li></ul><ul><li>J2EE Application Deliverable </li></ul><ul><li>J2EE Standards </li></ul><ul><li>Patterns Arose from Architecture </li></ul><ul><li>Gang of Four Patterns </li></ul><ul><li>Q & A </li></ul>
  3. 3. Introduction to Arthitecture <ul><li>Architecture is the overall structure of a system, and it can contain subsystems that interface with other subsystems </li></ul><ul><li>Architecture versus Design (level of details) </li></ul><ul><li>Architecture considers bunch of *abilities </li></ul>Capability Availability Reliability Manageability and Flexibility Performance Scalability Extensibility, Validity, Reusability Security
  4. 4. Multi-tiered J2EE applications J2EE Application I Web tier Business tier EIS tier J2EE Application II Client tier Client machine J2EE Server machine DataBase Server machine Application Client Dynamic HTML pages JSP/Servlet Enterprise Beans Database Database Enerprise Beans
  5. 5. Distributes Programming Services <ul><li>Naming and Registration (JNDI) </li></ul><ul><li>Remote Method Invocation (RMI) </li></ul><ul><li>Protocols </li></ul><ul><ul><li>Distributed Object Frameworks </li></ul></ul>Between user interface and business tiers HTTP, RMI, CORBA, DCOM, JMS Between business and persistence tiers JDBC, IDL to COM bridge, JMS, plain socket, native APIs via JNI embedded in resource adapters - CORBA - Native Language Integration - Java/RMI - DCOM <ul><ul><li>XML </li></ul></ul>
  6. 6. EJB Distributed Nature (I) EJB Container Bean EJBObject EJBHome Remote Stub Home Stub Client
  7. 7. EJB Distributed Nature (II)
  8. 8. J2EE Modular-Based Development <ul><li>Presentation tier developer </li></ul><ul><li>Bean provider </li></ul><ul><li>Application assembler </li></ul><ul><li>Component provider </li></ul><ul><li>Application server provider </li></ul><ul><li>EJB container provider </li></ul>Staff be categories into different roles:
  9. 9. J2EE Application Deliverable Web archive (.war) web.xml EJB archive (.jar) ejb-jar.xml Client archive (.car) application-client.xml Enterprise archive (.ear) application.xml
  10. 10. Deployment Descriptor Sample <ejb-jar> <enterprise-beans> ... </enterprise-beans> <assembly-descriptor> <security-role> <description> This role represents everyone who is allowed full access to the Cabin EJB. </description> <role-name>everyone</role-name> </security-role> <method-permission> <role-name>everyone</role-name> <method> <ejb-name>CabinEJB</ejb-name> <method-name>*</method-name> </method> </method-permission> <container-transaction> <method> <ejb-name>CabinEJB</ejb-name> <method-name>*</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> </assembly-descriptor> </ejb-jar>
  11. 11. J2EE Standards <ul><li>CTS </li></ul><ul><li>J2EE SDK </li></ul><ul><li>EJB spec </li></ul><ul><li>Servlet spec </li></ul><ul><li>JSP spec </li></ul>Contains following specs Together with below's offerings
  12. 12. Patterns Arose from Architecture and Anthropology - Christopher Alexander <ul><li>Is quality objective? </li></ul><ul><li>How do we get good quality repeatedly? </li></ul><ul><li>Look for the commonalities </li></ul><ul><li>...especially commonality in the features of the problem to be solved </li></ul>
  13. 13. Moving from Architectural to Software Design Patterns <ul><li>Adapting Alexander for software </li></ul><ul><li>The Gang of Four did the early work on design patterns (Gamma, Helm, Johnson, Vlissides) </li></ul>
  14. 14. Key Features of Patterns Item Description ------------------------------------------------------------------------------------------------------------- Name All patterns have a unique name that identifies them Intent The purpose of the pattern Problem The problem that the pattern is trying to solve Solution How the pattern provides a solution to the problem in the context in which it shows up Participants The entities involved in the pattern and collaborators Consequences The consequences of using the pattern. Investigates the forces at play in the pattern Implementation How the pattern can be implemented Generic structure A standard diagram that shows a typical structure for the pattern
  15. 15. Enumerate GoF Patterns Structural Patterns Adapter Bridge Composite Decorator Facade Flyweight Proxy Behavioral Patterns Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor Creational Patterns Abstract Factory Builder Factory Method Prototype Singleton
  16. 16. Abstract Factory Pattern “ Provide an interface for creating families of related or dependent objects without specifying their concrete classes.&quot; - GoF Solution A Switch to Control Which Driver to Use class ApControl { . . . public void doDraw() { . . . switch (RESOLUTION) { case LOW: // use lrdd case HIGH: // use hrdd } } public void doPrint() { . . . switch (RESOLUTION) { case LOW: // use lrpd case HIGH: // use hrpd } } } Problem class ApControl { . . . public void doDraw() { . . . myDisplayDriver.draw(); } public void doPrint() { . . . myPrintDriver.print(); } } abstract class ResFactory { abstract public DisplayDriver getDispDrvr(); abstract public PrintDriver getPrtDrvr(); } class LowResFact extends ResFactory { public DisplayDriver getDispDrvr() { return new LRDD(); } public PrintDriver getPrtDrvr() { return new LRPD(); } } class HighResFact extends ResFactory { ... }
  17. 17. The Facade Pattern <ul><li>“ Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.” - GoF </li></ul>Problem Solution
  18. 18. Stragegy Pattern Solution “ Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.” - GoF Problem
  19. 19. J2EE Best Practice – MVC Pattern (I) <ul><li>Model </li></ul><ul><li>Controller </li></ul><ul><li>View </li></ul>Represents the application data along with methods that operate on that data. Displays that data to the user. Translates user actions such as mouse movement and keyboard input and dispatches operations on the Model.
  20. 20. J2EE Best Practice – MVC Pattern (II) Forward Dispatch Update Extract Http request or post Response Client browser Controller (action servlet) Business logic Model (server side JavaBean/EJB) View (JSP page)
  21. 21. <ul><li>Q & A </li></ul><ul><li>Thank you!! </li></ul>