J2EE Design

Document Sample
J2EE Design Powered By Docstoc
					J2EE Architecture, System
Qualities and Design Patterns

Enterprise Java Architect
Sun Java Center
Yanchou.Han@sun.com
    Agenda
   J2EE Architecture Fundamentals
   J2EE system Qualities
   J2EE Design Pattern
 What is J2EETM?
•Built on Java 2 SDK
              TM

•J2EE is component based application
 Framework
•J2EE specifies a set of API for Enterprise
 Development
•J2EE platform provides a set of Services
•Development, Deployment, and Management
•J2EE specifies Distributed, Server-Centric
 Applications Architecture Blueprint
J2EE Platform Architecture
    Component Based Framework

   Component
    A component is an application level software unit.
    The J2EE platform supports the following types of
    components: Applets, Application clients, EJB and
    Web components (in addition to J2SE)
   Container
    All J2EE components depend on the runtime support
    of a system-level entity called a container. Containers
    provide components with services such as life cycle
    management, security, deployment, and Transaction
    J2EE API
   Database: JDBC
   Directory:JNDI
   Transaction JTA,JTS
   Mail: Java Mail
   Messaging: JMS
   Communication: RMI
   Server-Side Component: EJB
   Presentation-Side: Servlet, JSP
   Legacy Connector: Connector
    Deployment Services
   J2EE deployment services allow components
    and applications to be customized at the time
    they are packaged and deployed.
   A J2EE application consists of one or more
    J2EE modules and one J2EE application
    deployment descriptor (EAR file)
   A J2EE module consists of one or more J2EE
    components and one deployment descriptor
    of that component type.
    Transaction Services

   The J2EE platform handles many transaction
    details, such as propagating and coordinating
    among multiple transaction managers.
   Web components are not designed to be
    transactional (can demarcate).
   Transactions are propagated from a Web
    component to an enterprise bean only when
    the Web component starts the transaction.
    Security Services

   Authentication--An entity must establish its
    identity through authentication. It typically
    does so by providing authentication data
   Authorization--When an authenticated
    principal tries to access a resource, the
    system determines whether the principal is
    authorized to do so based on the security
    policies in force in the application's security
    policy domain.
J2EE App Architecture BluePrint
    Agenda
   J2EE Architecture Fundamentals
   J2EE System Qualities
   J2EE Design Pattern
Qualities of J2EE Architecture
   Scalability – Scalability relates to the ability for
    an e-commerce site to add capacity and thus add
    users over time. Scalability will usually require the
    addition of resources, but scalability should not
    require changes in the architecture, code to scale.

   Reliability —System reliability describes the
    likelihood of any component failures.

   Availability —The percentage of time that the
    system is available for use.
Qualities of J2EE System
   Maintainability –How easy it is to monitor,
    upgrade and configure a system.

   Securibility – Includes the levels of
    authentication, authorization, audibility supported.

   Performance - relates both to the specific
    performance metrics (e.g., responsiveness, latency)
    and the users expectations about performance.
    Scalability
   Bigger Boxes – Provides More
    capability.
   Pipeline – Applies more processing
    power during a unit of time.
   Load Banancing Router- Handles all
    requests and distributes them among
    the replicated servers
    Availability and Reliability
   Better Boxes – Ensure that an
    appropriate level of reliability and
    availability is provided from the
    hardware
   Cluster - Involves the provision of
    ensembles of hardware resources,
    externally visible as a single resource,
    no noticeable loss of service is
    experienced.
    Maintainability
   Thin Client or Fat client with web start –
    Enables access devices to be treated as
    disposable assets entirely in the control of the
    end user.
   Wrappering – Provides external systems and
    software with nonstandard interfaces with
    given standardized interfaces that conform to
    the rest of the system being built
   Centralized control, configuration and
    management
    Performance - General Procedure
   Understand Application Architecture
   Replicate Runtime Production Environment
   Establish Meaningful Metrics
   Execute Steps to Isolate Bottlenecks
   Review Data Gathered in Metrics and Take
    Corrective Action
   Create a Report Describing Findings and
    Lessons Learned
    Application Performance tuning

   Keep your servlet session object small
   Reuse session EJB handler
   Reuse all datasource Object
   Use DB Connection Pool
   Turn off all ―System.out.print()‖
   Always use PrepareStatement for JDBC
   Avoid Memory Leak in Collection Object
    Application Performance tuning

   Avoid Type Casting
   Avoid Use of Reflection
   Use the right type JDBC Connector
   Use coarse granularity Object if
    networking involves
   Always minimize the web response size
   Always set the response size if possible
    Platform parameter tuning
   Http – Keep Alive
   TCP/IP – wait_Time_Interval
   Different Encoding schema between
    Application and platform
   Native IO driver instead pure Java Drive
   Thread Model – Native Thread,
    alternative thread lib(solaris)
   Data Source Pool size
VM Performance Tuning
   How garbage collection works
   Hotspot VM tuning
    How Garbage collection works?

   Young Generation Eden, SurvivorX2
    space
   Old Generation perm
    Object migration thru ‗Spaces‘
   When an Object is first created, it is allocated
    in the Eden Space
   When Eden space fills up, a garbage
    collection occurs (GC).
   Objects that are reachable are copied to one
    of survivor space
   If survivor space fills up, a Full GC occurs. A
    Full GC will tenure Objects from survivor to
    the perm space, collect all unreachable
    objects in the perm space, Eden space and
    survivor space. Then do what GC will do.
How to observe Garbage Collector?
 •   Use the VM command line switch -verbose:gc
         IMPORTANT: All threads in the JVM block while
          garbage collection is running. Example output:


 •   [GC 1868K->1445K(1984K), 0.0049082 secs]
 •   [GC 1957K->1506K(1984K), 0.0041218 secs]
 •   [Full GC 2018K->1218K(2608K), 0.1059716 secs]
HotSpot VM Tuning

 Unless you have problems with pauses, try
 granting as much memory as possible to the
 JVM. The default size 64MB is too small for server
 side application
 Set the maximum heap size to 25% larger than
 the largest amount memory used by the
 application under a load test.
 set minimum and maximum heap sizes to the
 same
 Set young generation 25% of the max heap.
 Always use –server as first arguments for Server
 side application
    Security

   Client tier Security
   Communication Security
   J2EE Security Services
    Thin Client tier Security
    HTML hidden variables – Don‘t use hidden
     variables to keep sensitive information
    Parameter Tampering – Parameters sent to
     the server can be tampered legal clients
    Client side user validation – Only for
     performance and user friendly. Server side
     app should never trust the client side user
     validation
    GET vs. Post – Always use Post
    Cookies – Cookie can be used to track the
     client activities, the content of Cookie can be
     exposed to the third party
    Communication Security
   Authentication – Establishes the identity
    between the client and the server side
   Authorization – Determine what the
    authenticated identity can do
   Confidentiality-Message is only read by
    intended recipient
   Integrity - Message sent is the message
    received
   Nonrepudiation – Provides a way to prove
    that certain principal sent or received a
    particular message
    J2EE Security - GOAL
   Supports security application
    deployments without relying on private
    networks environments.
   Minimizes the application developer‘s
    responsibility and delegate the
    responsibility to the more qualified
    security administrator
   Be policy driven and requires no
    application code
    How to get J2EE Security Services?

   Defines Security Identity using
    deployment tools
   Defines Authentication policy in
    web.xml
   Defines Authorization Policy for Web
    Tier in web.xml
   Defines Authorization Policy for EJB Tier
    in ejb-jar.xml
    J2EE security Identity
   User – Legal identity that is allowed to
    access system.
   Group – Global Categories of users for
    enterprise
   Role - An application specific type of
    group defined by application assembler.
J2EE security identity (cont.)
       Principlas       Group           Role


       Keven


                     Teller Group       Teller

        Tom




       Larry        Manager Group     Supervisior




     customer1       EveryOne Group   EveryOne
    J2EE Authentication
   HTTP Basic Authentication – Web server
    authenticate user by ID and Password
   Form-based Authentication – Servlet Engine
    authenticate user by ID and password and
    store security context in Cookie and server
    container. Key tech to single sign-on and
    declarative security
   Customize Basic Authentication – Application
    programmatically authenticate user ID and
    Password
   Client-certificate Authentication –
    Authenticate client side by client certificate
 WEB Tier Authorization Policy Sample

 <security-constraint id=“supervisor">
   <web-resource-collection id=“Super_Res_1">
     <web-resource-name> Super_Res</web-resource-name>
       <url-pattern>/Supervisor</url-pattern>
       <url-pattern>/Manager</url-pattern>
       <http-method>POST</http-method>
   </web-resource-collection>
      <auth-constraint id="AuthConstraint_1">
        <description>ManagerSecuirty</description>
        <role-name>supervisor</role-name>
      </auth-constraint>
</security-constraint>
EJB Tier Authorization Example


Roles             AccountBean. AccountBean.
                  getBanance() setBalance()
Teller            Yes            No


supervisor        Yes            Yes
    Declarative Security
   Containers intercept requests/method
    invocations, enforce security policy
   Access security policy is declared at
    deployment
          Not embedded in code
          Flexible, just change and redeploy
    Programmatic Security
   Programmatic Security
        For custom security functionality not
         provided by declarative security
             Determine the principle associated with a
              request
                  HttpServletRequest.getUserPrinciple()
                  EJBContext.getCallerPrinciple()
             Determine if the caller/user is in the specified
              role
                  HttpServletRequest.isUserInRole()
                  EJBContext.isCallerInRole()
    Case Study
   Web Page: Search by Transaction
    Number
       Transaction:    123456


   Server Object create SQL as:
Select * from tranTable where
  tranID=123456 ;
    Case Study (Cont.)
   Web Page: Search by Transaction
    Number
       Transaction:   123456;drop table tranTbl;


   Server Object create SQL as:
Select * from tranTbl where
  transactionID=123456 ; Drop Table
  TranTbl;
    Agenda
   J2EE Architecture Fundamentals
   J2EE System Qualities
   J2EE Design Pattern
    What are Patterns?
   Patterns are about communicating
    problems and solutions

   Recurring problems within a context

   Expert solutions
    J2EETM Design Patterns


   Based on experience in SJC

   Collection of best practices
    J2EE Patterns Partitioning
   Presentation Tier
        a.k.a. Web Tier
        Building application's presentation
   Business Tier
        a.k.a. Enterprise JavaBeansTM (EJB TM) Tier
        Contains business logic
        Business processing and data access
   Integration Tier
        a.k.a. EIS Tier
        Integration of J2EE code with legacy systems /
         applications
    Presentation-Tier Patterns
   Intercepting Filter <----
   Front Controller
   View Helper
   Composite View
   Dispatcher View
   Service To Worker
    Intercepting Filter
   Problem:
        Preprocessing and post-processing of a
         client web request and response are
         required
   Forces:
        Centralization of common logic
        Processing components should be easily
         added and removed
 Intercepting Filter : Solution
When a request enters a Web application, it often
must pass several entrance tests prior to the main
processing stage. For example:

• Has the client been authenticated?
• Does the client have a valid session?
• Does the request path violate any constraints?
• What encoding does the client use to send the
data?
• Do we support the browser type of the client?
Intercepting Filter : Class
Diagram
    Presentation-Tier Patterns
   Intercepting Filter
   Front Controller      <----
   View Helper
   Composite View
   Dispatcher View
   Service To Worker
    Front Controller Pattern
   Problem:
      There is no centralized access point for
       presentation request handling
   Forces
      There is common processing that is performed
       across requests.
        Common logic is duplicated in numerous views
        Need to perform
             Request handling
             Data access
             View management
             Navigation and Dispatch
    Front Controller: Solution
   Use a FrontController as the initial point
    of contact for handling requests.

   The FrontController is responsible for
    managing the handling of the request.

   Its responsibilities include delegation of
    business processing, managing the choice an
    appropriate view, error handling, selecting
    content-creation strategies.
    Front Controller—Class Diagram

   Use a controller as the initial point of
    contact for handling requests
Front Controller: Strategies
   ServletFront Strategy – The Front Controller
    is implemented as a servlet. This is the
    preferred strategy.

   JSPFront Strategy – The Front Controller is
    implemented as a JSPTM. More cumbersome
    and difficult to debug than using a servlet for
    this function.
Front Controller:
Consequences
   Centralized control
   Improves Reusability
   Improves manageability, as typically
    only one resource is registered with
    web container
    Presentation-Tier Patterns
   Intercepting Filter
   Front Controller
   View Helper           <----
   Composite View
   Dispatcher View
   Service To Worker
    View Helper
   Problem – Presentation tier changes
    occur often and are difficult to develop
    and maintain when business logic and
    presentation formatting logic are
    interwoven.
    View Helper: Forces
   Embedding business logic in the view
    promotes a copy-and-paste type of reuse.
   It is desirable to promote a clean separation
    of roles
        Software developer
        Web production team



   Enforces logical separation of View and Model
    View Helper: Solution
   A View contains formatting code,
    delegating its processing responsibilities
    to its helper classes, implemented as
    JavaBeansTM or custom tags.



   Helpers also store the view’s
    intermediate model and serve as
    business data adapters.
View Helper: Class Diagram
    View Helper: Consequences
   Improved application partitioning
   Improved role separation
   Reusability
    Presentation-Tier Patterns
   Intercepting Filter
   Front Controller
   View Helper
   Composite View <----
   Dispatcher View
   Service To Worker
Composite View Example
    Composite View Pattern
   Problem:
        Instead of providing a mechanism to
         combine modular, atomic portions of a
         view into a composite whole, pages are
         built by embedding formatting code
         directly within each view.
   Forces:
        Multiple composite view use similar
         subviews
        Modularity
    Composite View: Forces
   Layout changes are more difficult to
    manage and code harder to maintain
    when subviews are directly embedded
    and duplicated in multiple view.
   Atomic portions of view content change
    frequently.
   Managing Content versus Managing
    Layout.
    Composite View: Solution
   Use CompositeViews that are composed
    of multiple atomic subviews.
    Composite View Example
   And numerous pages like this...
    Composite View:
    Consequences
   View based on role or policy-based decisions

   Improved manageability

   Enhances flexibility

   Improved reusability

   Performance impact
    Presentation-Tier Patterns
   Intercepting Filter
   Front Controller
   View Helper
   Composite View
   Service To Worker <----
   Dispatcher View    <----
Service To Worker and Dispatcher View

•Problem – The problem is a combination of
  the problems solved by the Front Controller
  and View Helper patterns in the presentation
  tier. There is no centralized component for
  managing access control, content retrieval, or
  view management, and there is duplicate
  control code scattered throughout various
  views.
• Additionally, business logic and presentation
  formatting logic are intermingled within these
  views, making the system less flexible, less
  reusable, and generally less resilient to
  change.
    Service To Worker: Solution
   Combine a Controller and Dispatcher
    with Views and Helpers (see Front
    Controller and View Helper Patterns) to
    handle client requests and prepare a
    dynamic presentation as the response.
Service To Worker




Dispatcher View
    Service To Worker / Dispatcher View:
    Consequences
   Centralized control
   Improved reusability and maintainability
   Improved role separation
    J2EE Pattern Catalog -
    Business Tier
   Service Locator   <----
   Business Delegate
   Session Façade
   Value Object
   Value Object Assembler
   Value List Handler
   Composite Entity
    Service Locator
   Problem - J2EE clients interact with
    service components such as EJB
    components, which provide business
    services and persistence capabilities.
Service Locator: Forces
   EJB clients need to use the JNDITM API to
    lookup EJBHome objects by using the
    enterprise bean's registered JNDI name.
   Lookup and creation of service components
    could be complex and may be used
    repeatedly in multiple clients in the
    application.
   EJB Clients may need to re-establish
    connection to a previously accessed
    enterprise bean having only its EJB Handle
    object.
    ServiceLocator: Solution
   Use a Service Locator object to abstract
    all JNDI usage and to hide the
    complexities of initial context creation,
    EJB home object lookup, and EJB object
    re-creation. Multiple clients can reuse
    the Service Locator object to reduce
    code complexity, provide a single point
    of control, and improve performance by
    providing a caching facility.
ServiceLocator: Class
Diagram
    Service Locator:
    Consequences
   Abstracts complexity
   Provides uniform access to clients
   Improves network performance
    J2EETM Pattern Catalog -
    Business Tier
   Service Locator
   Business Delegate    <----
   Session Facade
   Value Object
   Value Object Assembler
   Value List Handler
   Composite Entity
    Business Delegate
   Problem - Presentation-tier components
    interact directly with business services.
    This direct interaction exposes the
    underlying implementation details of
    the business service API to the
    presentation tier.
Business Delegate : Forces
   It is desirable to minimize coupling
    between presentation-tier clients and
    the business service, thus hiding the
    underlying implementation details of
    the service, such as lookup and access.
   It is desirable to reduce network traffic
    between client and business services.
    Business Delegate : Solution
   Use a Business Delegate to reduce
    coupling between presentation-tier
    clients and business services. The
    Business Delegate hides the underlying
    implementation details of the business
    service, such as lookup and access
    details of the EJBTM architecture.
Business Delegate : Class
Diagram
    Business Delegate: Strategies
   Delegate Proxy Strategy - The
    BusinessDelegate exposes an interface that
    provides clients access to the underlying
    methods of the business service API.
   Delegate Adapter Strategy - The Business
    Delegate proves to be a nice fit in a B2B
    environment when communicating with J2EE
    services. Disparate systems may use an XML
    as the integration language. Integrating one
    system to another typically requires an
    Adapter [GoF] to meld the two disparate
    systems.
Business Delegate:
Consequences
   Reduces Coupling, Improves Manageability -
    Reduces coupling between the Presentation
    tier and the Business tier
   Translates Business Service Exceptions - The
    BusinessDelegate is responsible for
    translating any network or infrastructure-
    related exceptions into business exceptions.
   Impacts Performance - The BusinessDelegate
    may provide caching services
    J2EE Pattern Catalog -
    Business Tier
   Business Delegate
   Service Locator
   Session Façade      <----
   Value Object
   Value Object Assembler
   Value List Handler
   Composite Entity
Session Facade
   Problem - Three problems may arise in
    a multi-tiered J2EE application
    environment:
       Tight coupling which leads to direct
        dependence between clients and business
        objects
       Too many method invocations between
        client and server leading to network
        performance problems
       Lack of a uniform client access strategy
        exposing business objects to misuse
    Session Facade: Forces
   Provide a simpler interface to the clients by
    hiding all the complex interactions between
    business components.
   Reduce the number of business objects that
    are exposed to the client across the service
    layer over the network.
   Hide from the client the underlying
    interactions and inter-dependencies between
    business components. This provides better
    manageability, centralization of interactions
    (responsibility), greater flexibility, and greater
    ability to cope with changes
   Provide a uniform coarse-grained service
    Session Facade: Solution
   Use a session bean as a Facade to
    encapsulate the complexity of
    interactions between the business
    objects participating in a workflow. The
    Session Facade manages the business
    objects, and provides a uniform,
    coarse-grained service access layer to
    clients.
Session Facade: Class
Diagram
    Session Facade:
    Consequences
   Introduces Business Tier Controller
    layer
   Reduces Coupling, Increases
    Manageability
   Improves Performance, Reduces Fine-
    grained Methods
   Provides Coarse-Grained Access
   Centralizes Transaction Control
    J2EE Pattern Catalog -
    Business Tier
   Business Delegate
   Service Locator
   Session Facade
   Value Object       <----
   Value Object Assembler
   Value List Handler
   Composite Entity
    Value Object
   Problem - J2EE applications implement
    server-side business components as
    session beans and entity beans. Some
    methods exposed by the business
    components return data to the client.

   Often, the client invokes a business
    object‘s get methods multiple times
    until it obtains all the attribute values.
Value Object: Forces

   The client usually requires more than
    one attribute value of an enterprise
    bean.

   The number of calls made by the
    client to the enterprise bean impacts
    network performance.
    Value Object : Solution
   Use a Value Object to encapsulate the
    business data. A single method call is
    used to send and retrieve the Value
    Object.
Value Object : Class Diagram
    Value Object : Consequences
   Transfers more Data in fewer remote
    calls
   Reduces Network Traffic
   Reduces Code Duplication
   May Increase Complexity due to
    Synchronization and Concurrent Access
    and Transactions
    J2EE Pattern Catalog -
    Business Tier
   Business Delegate
   Service Locator
   Session Facade
   Value Object
   Value Object Assembler <----
   Value List Handler
   Composite Entity
    Value Object Assembler
   Problem - Application clients typically
    require the data for the model or parts
    of the model to present to the user or
    to use it for an intermediate-processing
    step before providing some service.
Value Object Assembler: Forces
   Separation of business logic is required
    between the client and the server side
    components.
   Because the model consists of distributed
    components, access to each component is
    associated with a network overhead.
   Clients do not need to be aware of the
    intricacies and dependencies in the model
    implementation.
   Clients do not otherwise need to have the
    additional business logic required to
    construct the model from various business
    components.
Value Object Assembler: Solution

   Use a Value Object Assembler to build
    the required model or sub-model. The
    Value Object Assembler uses value
    objects to retrieve data from various
    business objects and other objects that
    define the model or part of the model.
Value Object Assembler: Class Diagram
    Value Object Assembler: Strategies

   JavaTM Object Strategy - The
    ValueObjectAssembler can be an arbitrary
    Java object and need not be an enterprise
    bean.
   Session Bean Strategy - This strategy
    implements the ValueObjectAssembler as a
    session bean
   Note: The BusinessObject role in this pattern
    can be supported by different types of
    objects
        Session Bean
        Entity Bean
        DAO
    Value Object Assembler: Consequences

   Separates business logic
   Reduces coupling between clients and
    the Application Model
   Improves Network performance
    J2EE Pattern Catalog -
    Business Tier
   Business Delegate
   Service Locator
   Session Facade
   Value Object
   Value Object Assembler
   Value List Handler   <----
   Composite Entity
    Value List Handler
   Problem -Most J2EE applications have a
    search / query requirement to search
    and list certain data. In some cases,
    such a search and query operation
    could yield results that can be quite
    large. It is impractical to return the full
    result set when the client‘s
    requirements are to traverse the
    results, rather than process the
    complete set.
Value List Handler: Forces
•The application client needs an efficient
 query facility to avoid having to call the
 entity bean‘s ejbFind method and
 invoking each remote object returned.
•A query that is repeatedly executed on
 reasonably static data can be optimized
 to provide faster results.
•Client may want to scroll forward and
 backward within a result set.
    Value List Handler: Solution
   Use a Value List Handler to control the
    search, cache the results, and provide
    the results to the client in a result set
    whose size and traversal meets the
    client‘s requirements.
Value List Handler: Class Diagram
    ValueListHandler: Consequences

   Provides alternative to EJB Finders for
    large queries
   Caches query results on server-side
   Provides better querying flexibility
   Improves network performance
    J2EE Pattern Catalog - Business Tier

   Business Delegate
   Service Locator
   Session Facade
   Value Object
   Value Object Assembler
   Value List Handler
   Composite Entity   <----
    Composite Entity.
   Problem - In a J2EE application, clients
    (applications, JSPTM technology,
    ServletsTM, JavaBeans) access entity
    beans via their remote interfaces. When
    entity beans are fine-grained objects,
    clients tend to invoke more individual
    entity bean methods, resulting in high
    network overhead.
Composite Entity: Forces
   Entity beans are best implemented as coarse-
    grained objects due to the high overhead
    associated with each entity bean.
   Applications that directly map relational
    database schema to entity beans (where
    each row in a table is represented by an
    entity bean instance) tend to have a large
    number of fine-grained entity beans.
   Direct mapping of object model to EJB model
    yields fine-grained entity beans. Fine-grained
    entity beans usually map to the database
    schema.
    Composite Entity: Solution
   Use Composite Entity bean to model,
    represent, and manage a set of inter-
    related persistent objects rather than
    representing them as individual fine-
    grained entity beans. An Composite
    Entity bean represents a graph of
    objects.
Composite Entity: Class Diagram
    J2EE Pattern Catalog - Integration Tier

   Data Access Object
   Service Activator
    Data Access Object
   Problem: Many real-world J2EE
    applications need to use persistent data
    at some point. For many applications,
    persistent storage is implemented with
    different mechanisms, and there are
    marked differences in the APIs used to
    access these different persistent
    storage mechanisms.
    Data Access Object: Forces
   Components such as bean-managed entity
    beans, session beans, servletsTM and JSPsTM
    need to retrieve and store information from
    persistent stores.
   Components typically use proprietary APIs to
    access legacy systems to retrieve and store
    data.
   Components need to be transparent to the
    actual persistent store or data source
    implementation to provide easy migration to
    different vendor products, different storage
    types, and different data source types.
    Data Access Object: Solution
   Use a Data Access Object to abstract
    and encapsulate all access to the data
    source. The Data Access Object
    manages the connection with the data
    source to obtain and store data.
Data Access Object: Class
Diagram
DataAccessObject: Strategies
   Automatic DAO Code Generation - Each
    BusinessObject has its own DAO and storage
    (for example, table in RDBMS). Build or buy a
    code generator to create DAOs from
    metadata automatically.
   Factory for DAO - Define an Abstract Factory
    for DAOs. Each concrete DAO Factory
    encapsulates storage vendor-specific details.
    Clients request DAOs from the abstract
    factory, which delegates creation to the
    appropriate concrete DAO factory.
    Data Access Object:
    Consequences
   Enables transparency
   Enables easier migration to different
    persistent storage implementation
   Reduces code complexity in business
    objects
   Centralizes data access into a separate
    layer
   Not useful for EJBsTM with container-
    managed persistence
    J2EE Pattern Catalog -
    Integration Tier
   Data Access Object
   Service Activator    <----
    Service Activator
   Problem: Enterprise beans implemented
    prior to the EJB specification version 2.0
    (EJB 2.0) do not support asynchronous
    invocation. EJB 2.0 introduces
    integration with JMS by providing a
    Message Driven Bean, which is a new
    type of stateless session bean.
Service Activator: Forces
•EJBs are accessed using remote interfaces,
 which support synchronous processing only.
•All interactions are performed through
    remote references. Implementing JMS
    listener by an EJB is not allowed.
•   An application might need to provide a
    publish/subscribe framework for EJBs.
•   Clients want to invoke EJBs asynchronously
    without waiting for processing to complete.
•   Clients want to use the messaging facilities
    offered by JMS interfaces to call an EJB
•   An EJB needs to provide daemon-like
    facilities without being passivated
    Service Activator: Solution
   Use a Service Activator to receive
    asynchronous client requests and
    messages. On receiving a message, the
    Service Activator locates and invokes
    the necessary business methods on the
    business service components to fulfil
    the request asynchronously.
Service Activator: Sequence
Diagram
    Service Activator:
    Consequences
   Integrates JMS into pre-EJB 2.0
    implementations
   Provides asynchronous processing for
    any enterprise beans
   Standalone process
Find out More…
   Check out the book—Core J2EE™ Patterns
   Subscribe to J2EE Patterns Interest alias
    http://archives.java.sun.com/j2eepatterns-
    interest.html
   Tools:
       TogetherSoft
       Rational
       iPlanet
   Updates at
    http://www.phptr.com/corej2eepatterns
    Reference
   Architecturing and J2EE Patterns -Mark Cada
   SUN One Architecture
   Enterprise Java Architecture-Sameer Tyagi
   Garbage Collection & Performance Tuning -Charlie Hunter

				
DOCUMENT INFO