You are on page 1of 21

J2EE Architecture and Design Patterns

Student: Fang Fang Advisor: Dr. Glen Qin Date: 05/14/2005

Agenda
Introduction to Architecture J2EE Architecture Diagram Distributed Programming Serviced Modular-Based Development J2EE Application Deliverable J2EE Standards Patterns Arose from Architecture Gang of Four Patterns Q&A

Introduction to Arthitecture
Architecture is the overall structure of a system, and it can contain subsystems that interface with other subsystems Architecture versus Design (level of details) Architecture considers bunch of *abilities Capability Availability Reliability Manageability and Flexibility Performance Scalability Extensibility, Validity, Reusability Security

Multi-tiered J2EE applications


J2EE Application I
Application Client

J2EE Application II
Dynamic HTML pages

Client tier

Client machine

JSP/Servlet

Web tier

Enerprise Beans

Enterprise Beans

J2EE Server machine

Business tier

Database

Database

EIS tier

DataBase Server machine

Distributes Programming Services


Naming and Registration (JNDI) Remote Method Invocation (RMI) Protocols
Between user interface and business tiers Between business and persistence tiers HTTP, RMI, CORBA, DCOM, JMS JDBC, IDL to COM bridge, JMS, plain socket, native APIs via JNI embedded in resource adapters

Distributed Object Frameworks


- CORBA - Native Language Integration - Java/RMI - DCOM

XML

EJB Distributed Nature (I)

EJB Container
Remote Stub EJBObject

Client
Home Stub EJBHome

Bean

EJB Distributed Nature (II)

J2EE Modular-Based Development

Staff be categories into different roles:


Presentation tier developer Bean provider Application assembler Component provider Application server provider EJB container provider

J2EE Application Deliverable

Enterprise archive (.ear) application.xml


Web archive (.war) web.xml EJB archive (.jar) ejb-jar.xml Client archive (.car) application-client.xml

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>

J2EE Standards
Contains following specs
EJB spec Servlet spec JSP spec

Together with below's offerings


CTS J2EE SDK

Patterns Arose from Architecture and Anthropology - Christopher Alexander


Is quality objective? How do we get good quality repeatedly? Look for the commonalities ...especially commonality in the features of the problem to be solved

Moving from Architectural to Software Design Patterns


Adapting Alexander for software The Gang of Four did the early work on design patterns (Gamma, Helm, Johnson, Vlissides)

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

Enumerate GoF Patterns

Creational Patterns Abstract Factory Builder Factory Method Prototype Singleton

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

Abstract Factory Pattern


Provide an interface for creating families of related or dependent objects without specifying their concrete classes." - GoF

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

Solution

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 { ... }

The Facade Pattern


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

Problem

Solution

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

Solution

J2EE Best Practice MVC Pattern (I)

Model
Represents the application data along with methods that operate on that data.

View
Displays that data to the user.

Controller
Translates user actions such as mouse movement and keyboard input and dispatches operations on the Model.

J2EE Best Practice MVC Pattern (II)

Http request or post

Controller (action servlet)

Dispatch

Business logic

Client browser

Forward

Update

Response

View (JSP page)

Extract

Model (server side JavaBean/EJB)

Q&A Thank you!!

You might also like