j2ee architecture, system qualities and design patterns enterprise java architect sun java center...
Post on 27-Dec-2015
227 Views
Preview:
TRANSCRIPT
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 JavaTM 2 SDK
•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
ComponentA 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)
ContainerAll 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.
InternetClient
Load Balancer
GateWay GateWay
J2EE ApplicationJ2EE Application
DataBase Database
Client
DMZVirtual IP
ClusterSession Replicator
Sticky IPSticky Cookie
Firewall
Firewall
SUN Cluster
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 applicationSet 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.)
Tom
Keven
Larry
Teller Group
Manager Group
customer1 EveryOne Group
Teller
Supervisior
EveryOne
Principlas Group Role
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.getBanance()
AccountBean.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:
Server Object create SQL as:Select * from tranTable where
tranID=123456 ;
123456
Case Study (Cont.)
Web Page: Search by Transaction Number
Transaction:
Server Object create SQL as:Select * from tranTbl where
transactionID=123456 ; Drop Table TranTbl;
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 layer to separate business object implementation from business service abstraction.
Avoid exposing the underlying business objects directly to the client to keep tight coupling between the two tiers to a minimum.
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
top related