Docstoc

J2EE Patterns - PowerPoint

Document Sample
J2EE Patterns - PowerPoint Powered By Docstoc
					J2EE Patterns
 Slides by Igor Polevoy
       October 30 2003
          Pattern Definition
• Pattern is a best practice solution to a
  common recurring problem
• Pattern describes a recurring problem
• Pattern describes a typical solution to the
  problem
• Patterns are collective knowledge
• Patterns are great vehicle to share
  knowledge with more people
           Pattern Benefits
• Provides a high level language for design
  discussions
• Provides a well tested solution for a
  common problem
• Helps provide some design work
• Combinations of patterns tend to provide
  for reusable architecture frameworks
           Pattern History
• Christopher Alexander: A Pattern
  Language 1977
• Gamma, etc (Gang of Four, GoF): Design
  Patterns: Elements of Reusable Object-
  Oriented Software 1994
    GoF Pattern Categories
• Creational
  – Singleton
  – Abstract Factory
• Structural
  – Decorator
  – Adapter
• Behavioral
  – Strategy
  – Chain of Responsibility
          EJB Layer Patterns
•   Session Façade
•   Message Façade
•   EJB Command
•   Data Object Transfer Factory
•   Generic Attribute Access
•   Business Interface
Example of J2EE Application
           Fine-Grained Access
              Disadvantages
• Increased network overhead
• Client needs to have intimate knowledge of server side
  components
• Data access, business and workflow logic scattered
  across client
• Tight coupling of clients and server components
• Transaction not managed, funds can be in the undefined
  state
• Poor people role separation
• Poor maintainability
• Poor reusability
Fine-Grained Access Solutions
 – Encapsulate all logic inside entity beans, have
   client make just one call
   • Disadvantages: tight coupling of business logic
     and data, lower level of component reuse
 – Transaction demarcation handled by client
   • If client is far away, transactions will run for long
     time, reducing overall performance of system
   • Client needlessly complex
   • Solves only data integrity problem
      Session Façade Pattern
• Façade Pattern (GoF) provides a unified
  interface to a set of interfaces in a subsystem.
  Façade provides a higher-level interface that
  makes it the sub-system easier to use
• Session Façade Pattern applied to J2EE only
• Session Façade provides a layer of abstraction
  to subsystem of session beans, entity beans and
  other components
• Hides server component complexity from client
     Session Façade Pattern
• Implemented as a layer of stateless beans
  (sometimes statefull)
• Provides a clean interface to execute
  business logic and workflow
• Separates complexity from client
• Provides for automatic transaction support
• Separates development roles
• From OO point of view provides for layer
  of abstraction and encapsulation
     Session Façade Pattern
• Before
      Session Façade Pattern
• After:
      Session Façade Pattern
• Solution:
              Session Facade
• Benefits:
  – Lower network overhead
  – Separation of business logic from
    presentation
  – Inherent transaction support
  – Promotes reusability
  – Looser coupling
     Session Facade Dangers

• Do not create a God Session Façade
• Do not put presentation logic into façade
• Do not use Session Façade as domain
  model, use it only as glue
       Situation in Enterprise
• Need to execute a number of session and
  entity beans in a context of the same
  transaction
• Immediate response is not required
• Client does not have to be required to wait
  end of execution
Situation in Enterprise
                     Solutions
• Use Session Façade Pattern
  – Solves the following problems:
    •   Coupling
    •   Performance
    •   Maintainability
    •   Data integrity
  – Does not solve:
    • Response time
    • Reliability
Message Façade Pattern
    Message Façade Pattern
• Use a Message Driven Bean to create a
  reliable fault-tolerant façade
• Client should only send messages to JMS
  destination. They should not access
  session and entity beans directly
     Message Façade Pattern
• Solves:
  – Response time
     • Inherently by use of messaging
  – Reliability
     • If a transaction fails, then the MDB can push the
       message back into destination; the message will
       be re-delivered
    Message Façade Pattern
• Usage:
  – Do not put business logic into MDB
  – Use Message Façade pattern together with
    Session Façade Pattern
• Disadvantages:
  – Propagate results back to client
  – Cannot perform compile time type checking
  Command Design Pattern (GoF)
• Used to encapsulate executable logic in
  command units
• Decouples application client component
  from domain model
• Used to provide undo/redo functionality
     EJB Command Pattern
• Goal: to decouple application client
  component from binding to concrete
  domain model objects
• Separate development roles in projects
• Simplify access to Session Façade
• Use command beans with set/get methods
  and execute method
EJB Command Pattern
      EJB Command Pattern
• Elements:
  – Command Beans
  – Client side routing logic
  – Command server
      EJB Command Pattern
• Benefits:
  – Easier to deploy the application (fewer
    session beans)
  – Separates business logic from presentation
  – Decouples application client component from
    EJBs
  – Command can execute locally, produce fake
    data to facilitate independent development
      EJB Command Pattern
• Disadvantages
  – Primitive transaction control (limited by
    command server)
  – Commands are stateless – no easy way to
    access statefull beans
  – Limited exception handling mechanism
  – Command beans classes loaded into J2EE
    runtime – no easy way to change functionality
    on the fly
Data Transfer Object Pattern
Data Transfer Object Pattern
        DTO Factory Pattern
• Problem with DTO:
  – DTOs change very often
  – Entity beans need to be updated
  – DTO consumption is unclear
  – Business domain logic creeps into entity
    beans
• Solution:
  – Place responsibility for creation/consumption
    of DTOs onto DTO Factories
        DTO Factory Pattern
• DTO Factory Pattern can be implemented
  as:
  – Simple java class
  – Session bean
DTO Factory Pattern
            DTO Factory Pattern
• Benefits:
   – Changes in creation of DTOs are performed in DTO Factories,
     making entity beans more stable
   – DTO Factory can create different views of the same data
   – DTO Factory can create complex composite DTOs, which hold
     data from multiple entity beans
   – DTO Factory can provide consumption of DTOs:
       • Application client will create a DTO, will set all necessary attributes,
         it will then pass it to DTOFactory.setXXXDTO() – this will cause the
         factory to find appropriate entity beans ad call their respective set
         methods all in the context of one transaction
   – Multiple applications can reuse the same persistence layer as
     long as they provide DTO Factories with appropriate logic
DTO Factory Usage
 DTO Factory Pattern Problems
• Does not scale well with attribute number
  growth
• Entity bean clients are tightly coupled with
  entity bean interfaces
• Solution: Generic Attribute Access Pattern
 Generic Attribute Access Pattern
• Move attribute access logic from entity
  bean client to a generic attribute access
  class
• This class will provide access to attributes
  via Maps of attribute keys and their
  respective values
  Generic Attribute Access Pattern
• Attribute access is built into entity beans as
  implementation of AttributeAccess interface
• Such interface would be implemented by a
  remote or local interface and the beans itself
interface AttributeAccess
{
   void setAttributes(Map attributes);
   Map getAttributes();//gets all attributes
   Map getAttributes(Set keys);//gets some attributes
}
Generic Attribute Access Pattern
  Generic Attribute Access Pattern
• Benefits:
  – A BMP can hold it’s state in a Map, simplifying the
    GAA implementation
  – No need to program DTOs
  – Attribute access code can be shared by all beans in
    the system – simplicity
  – In CMP, Java Reflection API can be used for updates
    – same code can be shared between all CMPs in the
    system (use a super class)
  – Scales well for large number of attributes/beans
  – One attribute access interface across all beans
  – Allows for creation of generic clients
 Generic Attribute Access Pattern
• Tradeoffs:
  – Additional overhead: need to construct an
    attribute access call, need to cast the attribute
    value
  – Need to maintain attribute contract
  – No compile-time type checking
  Generic Attribute Access Pattern
• Recommendations:
  – Provide a well documented contract for attribute naming
    conventions
  – Use Java Beans design patterns for naming conventions
  – Can se static finals on bean classes for run time name checking
  – Can use a shared interface that serves as a name binding
    contract:
  Interface PersonBeanNames
  {
    public static final String firstName;
    public static final String lastName;
    public static final String ssn;
    .   .   .
  }
    Business Interface Pattern
• Create a business interface for a bean
• Extend it in the remote/local interface
• Implement it in the bean class
 Data Transfer RowSet Pattern
• Transfer relational data in a tabular format
  to client application
• If use DTOs you convert tabular data to
  OO (EJB), then back to tabular (HTML)
• Use JDBC + RowSet to transfer tabular
  data directly to client
 Data Transfer RowSet Pattern
• Advantages:
  – Can use the same generic client code to process all
    tabular requests
  – Can use GUI automation (automatic rendering of
    ResultSet)
• Tradeoffs:
  – No compile time checking
  – Not OO
  – Client may need to know DB structure (can be
    remedied by Session Facade Pattern)
     Version Number Pattern
• Problem:
  – Data read is performed in a different
    transaction then data update
  – Hence – danger of update on stale data
  – Difficult to wrap read/write into the same
    transaction because of “think time”
  – Data collision can happen
     Version Number Pattern
• Solution:
  – Use record (bean) version number
  – Include version number into the cross tier
    transmission
  – Send version number back for update along
    with any changed attributes
  – Before update, validate version number
  – Reject update if stale record is updated
  – When update happen, increment version
    number
     Version Number Pattern
• Implementation
  – Depends on inter-tier transmission pattern
  – Have legacy applications update data through
    J2EE persistence layer; if impossible, write
    DB triggers that update version numbers
        JDBC For Reading
                or
     Fast Lane Reader Pattern
• Problems accessing entity beans for
  reading:
  – N+1 DB read problem
  – Network overhead for multiple calls
  – Join operations are difficult
     JDBC For Reading Pattern
• Solution:
   – Use straight JDBC for read operations
   – Use CMPs for update operations
   – Use in conjunction with other patterns
• Benefits:
   – No transaction dependency
   – DBMS cache mechanism used
   – Simple to join data
• Tradeoffs:
   – Bug prone
   – No compile time type checking
   – Tight coupling of client and persistence layers
   Data Access Command Bean
             Pattern
• Without DACB, session beans access
  entity beans and JDBC directly
• Problems:
  – Tight coupling between session layer and
    persistence implementation
  – Data access logic mixed in with business logic
  – Session bean layer is dependent on schema
    changes
  – High potential for copy/paste style code reuse
    Data Access Command Bean
              Pattern
• Encapsulate persistence logic into Bean
  Command classes
• Bean Command interfaces provide a layer of
  abstraction from concrete implementation of
  persistence layer
• Similar to EJB Command Pattern
• Differences from EJB Command Pattern:
  – DACB provides transparent interface to EJBs, JDBC,
    ObjectStore, etc (as opposed to session bean layer)
  – Serves as insulation layer between Session Beans
    (facade) and concrete persistence implementation
  – Semantically models data closer
Data Access Command Bean
          Pattern
Data Access Command Bean
          Pattern
Data Access Command Bean
          Pattern
   Data Access Command Bean
             Pattern
• Benefits:
  – Provides a clean abstraction layer for data
    store
  – Usable in any tier
  – Decouples business logic from storage logic
  – Facilitates independent development if
    dummy commands are used
• Disadvantages:
  – Extra work for developers
      EJBHomeFactory Pattern
      (Service Locator Pattern)
• Problems:
  – Client has repetitive code for lookups of home
    interfaces
  – Each time the lookup is done, a potential
    network call is performed
    EJBHomeFactory Pattern
• Solution:
  – Provide a factory class, which encapsulates
    all of the lookup code, and potentially caches
    home interfaces
  – Usually implemented as Singleton
  Example:
    Account acc =
    BusinesInterfaceFactory.getInstance().getInterf
    ace(com.acme.Account.class);
  All of the factory parameters for JNDI lookups
    are stored in the configuration of a factory.
    EJBHomeFactory Pattern
• Can be used in conjunction with Abstract
  Factory Pattern to make creation of
  business interfaces completely transparent
  to client code
    Business Delegate Pattern
• Problem:
  – When client uses a session façade or other interface
    to J2EE logic, there is a tight coupling between
    application client components and EJBs
  – Programming directly to EJB layer in not the best way
     • Clients need to be aware and handle transaction J2EE
       exceptions
     • Complicates client logic with EJB exception handling
     • Couples client directly to EJB or JMS (message facade) APIs
    Business Delegate Pattern
• Solution:
  – Create a layer of abstraction that insulates
    application client components from handling
    service discovery, complex exception
    handling and recovery
  – A Business Delegate is a plain Java class that
    usually maps to session façade one – to one
Business Delegate Responsibilities
• Delegate requests to session façade or
  message façade
• Hide EJB API exceptions behind application
  level exceptions
• May cache data locally
• May retry failed requests transparently to client
• Assists in large projects if dummy business
  delegates are used to asynchronously develop
  client and server functionality
                    Pattern Categories
•   EJB Layer
     –   Session Façade
     –   Message Façade
     –   EJB Command
     –   Data Transfer Object Factory
     –   Generic Attribute Access
     –   Business Interface
•   Inter-tier data transfer
     –   DTO
     –   Data Transfer HashMap
     –   Data Transfer RowSet
•   Transaction/persistence
     –   Version Number
     –   JDBC for Reading
     –   Data Access Command Bean
     –   Dual Persistence Entity Bean (CMP/BMP)
•   Client-side EJB Interaction
     –   EJB Home Factory
     –   Business Delegate

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:24
posted:10/1/2011
language:English
pages:64