http://www.ibm.com/developerworks/websphere/techjournal/0405_brown/0405_brown.

html

http://www.javagyan.com/useful-tips/Java7Updates

https://madhuraoakblog.wordpress.com/category/core-j2ee-design-patterns/

Non-Functional Requirements
Non-Functional Requirements (NFRs) play an equally important role like Functional Requirements (FRs)
in a software system. Architects need to balance out both while designing software systems. The typical
NFRs are listed below:

Performance - The performance requirement is usually measured in terms of response time for
a given screen transaction per user. In addition to response time, performance can also be
measured in transaction throughput, which is the number of transactions in a given time period,
usually one second. For example, you could have a performance measurement that could be no
more than three seconds for each screen form or a transaction throughput of one hundred
transactions in one second. Regardless of the measurement, you need to create an architecture
that allows the designers and developers to complete the system without considering the
performance measurement.
Scalability - Scalability is the ability to support the required quality of service as the system load
increases without changing the system. A system can be considered scalable if, as the load
increases, the system still responds within the acceptable limits. It might be that you have a
performance measurement of a response time between two and five seconds. If the system load
increases and the system can maintain the performance quality of service of less than a five
second response time, then your system is scalable. To understand scalability, you must first
understand the capacity of a system, which is defined as the maximum number of processes or
users a system can handle and still maintain the quality of service. If a system is running at
capacity and can no longer respond within an acceptable time frame, then it has reached its
maximum scalability. To scale a system that has met capacity, you must add additional
hardware. This additional hardware can be added vertically or horizontally. Vertical scaling
involves adding additional processors, memory, or disks to the current machine(s). Horizontal
scaling involves adding more machines to the environment, thus increasing the overall system
capacity. The architecture you create must be able to handle the vertical or horizontal scaling of
the hardware. Vertical scaling of a software architecture is easier than the horizontal scaling.
Why? Adding more processors or memory typically does not have an impact on your
architecture, but having your architecture run on multiple machines and still appear to be one
system is more difficult.
Reliability - Reliability ensures the integrity and consistency of the application and all its
transactions. As the load increases on your system, your system must continue to process
requests and handle transactions as accurately as it did before the load increased. Reliability can
have a negative impact on scalability. If the system cannot maintain the reliability as the load
increases, then the system is really not scalable. So, for a system to truly scale it must be
reliable.
Availability - Availability ensures that a service/resource is always accessible. Reliability can
contribute to availability, but availability can be achieved even if components fail. By setting up
 an environment of redundant components and failover, an individual component can fail and
have a negative impact on reliability, but the service is still available due to the redundancy.
Usability
Throughput
Manageability - Manageability is the ability to manage the system to ensure the continued
health of a system with respect to scalability, reliability, availability, performance, and security.
Manageability deals with system monitoring of the QoS requirements and the ability to change
the system configuration to improve the QoS dynamically without changing the system. Your
architecture must have the ability to monitor the system and allow for dynamic system
configuration.
Security - Security is the ability to ensure that the system cannot be compromised. Security is by
far the most difficult systemic quality to address. Security includes not only issues of
confidentiality and integrity, but also relates to Denial-of-Service (DoS) attacks that impact
availability. Creating an architecture that is separated into functional components makes it
easier to secure the system because you can build security zones around the components. If a
component is compromised, then it is easier to contain the security violation to that
component.
Serviceability
Testability
Scalability
Maintainability - Maintainability is the ability to correct flaws in the existing functionality
without impacting other components of the system. This is another of those systemic qualities
that you cannot measure at the time of deployment. When creating an architecture and design,
you should consider the following to enhance the maintainability of a system: low coupling,
modularity, and documentation.
Extensibility - Extensibility is the ability to add additional functionality or modify existing
functionality without impacting existing system functionality. You cannot measure extensibility
when the system is deployed, but it shows up the first time you must extend the functionality of
the system. You should consider the following when you create the architecture and design to
help ensure extensibility: low coupling, interfaces, and encapsulation.
Flexibility
Reusability
Portability

NFRs are also called as system quality attributes.

The NFRs not only impact the initial up-front architecture but also the design of the subsequent
enhancements and hence they should be properly identified, documented and communicated to all
stakeholders of the project. The system level NFRs are documented in Project Scope document and/or
Architecture Design Document (ADD). Module/Component-level NFRs can be documented in the ADD or
its Software Requirements Specification (SRS).

NFRs could change like FRs. Change in system-level NFRs could bring change in the architecture of the
system. For e.g. if you need your system to be available 24 X 7, you may need to implement Fail-over
clustering. High performance and reliable systems may need to implement load-balancing clustering.
NFRs should be quantifiable. Instead of saying that the response web page should have low latency, it
can be stated that a web page should not take more than 10 seconds to load in the browser. They
should also be tested like FRs.

Communicating the NFRs to developers in a project which maintains no documentation or has outdated
documentation (usually applicable to projects in Application Maintenance phase) is a real challenge. In
such projects it is usually observed that Architects take into account the NFRs in the architecture during
the initial design but due to lack of communication Architects (if they are changed) or developers in the
Application Maintenance phase are not aware of the NFRs. This is a risk since the design or
implementation could not account for the NFRs.

Core J2EE design patterns

The Core J2EE design patterns, which are very commonly used in any Java EE application architecture,
are grouped in three layers Presentation, Business and Integration. A Java EE application usually has
these three layers but it can also have additional layers as needed.

There is a difference between tier and layer. An n-tier application architecture means the application is
deployed and runs on multiple physical devices. A tier refers to the physical separation whereas layer
refers to the logical separation of application components. A layer can use one or more Core J2EE design
patterns.

The commonly used Core J2EE design patterns used in Java EE applications are given below:

Presentation Tier Patterns

Intercepting Filter
Intercepts incoming requests and outgoing responses and applies a filter. These filters may be added
and removed in a declarative manner, allowing them to be applied unobtrusively in a variety of
combinations. After this preprocessing and/or post-processing is complete, the final filter in the group
vectors control to the original target object. For an incoming request, this is often a Front Controller, but
may be a View.

Front Controller
Is a container to hold the common processing logic that occurs within the presentation tier and that may
otherwise be erroneously placed in a View? A controller handles requests and manages content
retrieval, security, view management, and navigation, delegating to a Dispatcher component to dispatch
to a View.

Application Controller
Centralizes control, retrieval, and invocation of view and command processing. While a Front Controller
acts as a centralized access point and controller for incoming requests, the Application Controller is
responsible for identifying and invoking commands, and for identifying and dispatching to views.
Context Object
Encapsulates state in a protocol-independent way to be shared throughout your application. Using
Context Object makes testing easier, facilitating a more generic test environment with reduced
dependence upon a specific container.

View Helper
Encourages the separation of formatting-related code from other business logic. It suggests using Helper
components to encapsulate logic relating to initiating content retrieval, validation, and adapting and
formatting the model. The View component is then left to encapsulate the presentation formatting.
Helper components typically delegate to the business services via a Business Delegate or an Application
Service, while a View may be composed of multiple subcomponents to create its template.

Composite View
Suggests composing a View from numerous atomic pieces. Multiple smaller views, both static and
dynamic, are pieced together to create a single template. The Service to Worker and Dispatcher View
patterns represent a common combination of other patterns from the catalog. The two patterns share a
common structure, consisting of a controller working with a Dispatcher, Views, and Helpers. Service to
Worker and Dispatcher View have similar participant roles, but differ in the division of labor among
those roles. Unlike Service to Worker, Dispatcher View defers business processing until view processing
has been performed.

Service to worker
Performs core request handling and invoke business logic before control is passed to the view. It
centralizes control and request handling to retrieve a presentation model before turning control over to
the view. The view generates a dynamic response based on the presentation model.

Dispatcher View
Combines a controller and dispatcher with views and helpers to handle client requests and prepare a
dynamic presentation as the response. Controllers do not delegate content retrieval to helpers, because
these activities are deferred to the time of view processing. A dispatcher is responsible for view
management and navigation and can be encapsulated either within a controller, a view, or a separate
component.

Business Tier Patterns

Business Delegate
Reduces coupling between remote tiers and provides an entry point for accessing remote services in the
business tier. A Business Delegate might also cache data as necessary to improve performance. A
Business Delegate encapsulates a Session Faade and maintains a one-to-one relationship with that
Session Faade. An Application Service uses a Business Delegate to invoke a Session Faade.

Service Locator
Encapsulates the implementation mechanisms for looking up business service components. A Business
Delegate uses a Service Locator to connect to a Session Faade. Other clients that need to locate and
connect to Session Faade, other business-tier services, and web services can use a Service Locator.
Session Faade
Provides coarse-grained services to the clients by hiding the complexities of the business service
interactions. A Session Faade might invoke several Application Service implementations or Business
Objects. A Session Faade can also encapsulate a Value List Handler.

Application Service
Centralizes and aggregates behavior to provide a uniform service layer to the business tier services. An
Application Service might interact with other services or Business Objects. An Application Service can
invoke other Application Services and thus create a layer of services in your application.

Business Object
Implements your conceptual domain model using an object model. Business Objects separate business
data and logic into a separate layer in your application. Business Objects typically represent persistent
objects and can be transparently persisted using Domain Store.

Composite Entity
Implements a Business Object using local entity beans and POJOs. When implemented with bean-
managed persistence, a Composite Entity uses Data Access Objects to facilitate persistence.

The Transfer Object

Pattern provides the best techniques and strategies to exchange data across tiers (that is, across system
boundaries) to reduce the network overhead by minimizing the number of calls to get data from
another tier.

The Transfer Object Assembler

Constructs a composite Transfer Object from various sources. These sources could be EJB components,
Data Access Objects, or other arbitrary Java objects. This pattern is most useful when the client needs to
obtain data for the application model or part of the model.

The Value List Handler

Uses the GoF iterator pattern to provide query execution and processing services. The Value List Handler
caches the results of the query execution and return subsets of the result to the clients as requested. By
using this pattern, it is possible to avoid overheads associated with finding large numbers of entity
beans. The Value List Handler uses a Data Access Object to execute a query and fetch the results from a
persistent store.

Integration Tier Patterns

Data Access Object
Enables loose coupling between the business and resource tiers. Data Access Object encapsulates all the
data access logic to create, retrieve, delete, and update data from a persistent store. Data Access Object
uses Transfer Object to send and receive data.
Service Activator
Enables asynchronous processing in your enterprise applications using JMS. A Service Activator can
invoke Application Service, Session Faade or Business Objects. You can also use several Service
Activators to provide parallel asynchronous processing for long running tasks.

Domain Store
Provides a powerful mechanism to implement transparent persistence for your object model. It
combines and links several other patterns including Data Access Objects.

Web Service Broker

Exposes and brokers one or more services in your application to external clients as a web service using
XML and standard web protocols. A Web Service Broker can interact with Application Service and
Session Faade. A Web Service Broker uses one or more Service Activators to perform asynchronous
processing of a request.