Hibernate Overview

This diagram shows Hibernate using the database and configuration data to provide persistence services (and
persistent objects) to the application.
Hibernate is flexible and supports several approaches.
The "lite" architecture has the application provide its own JDBC connections and manage its own transactions. This approach uses a minimal subset of Hibernate's APIs:

The "full" architecture abstracts the application away from the underlying JDBC/JTA APIs and lets Hibernate take care of  the details.

Heres some definitions of the objects in the diagrams:

SessionFactory (org.hibernate.SessionFactory) : A threadsafe (immutable) cache of compiled mappings for a single database.

Session (org.hibernate.Session) : A single-threaded, short-lived object representing a conversation between the application and the persistent store. Wraps a JDBC connection. Factory for Transaction. Holds a mandatory (first-level) cache of persistent objects, used when navigating the object graph or looking up objects by identifier.

Persistent objects and collections : Short-lived, single threaded objects containing persistent state and business function. These might be ordinary JavaBeans/POJOs, the only special thing about them is that they are currently associated with (exactly one) Session. As soon as the Session is closed, they will be detached and free to use in any application layer (e.g. directly as data transfer objects to and from presentation).

Transient and detached objects and collections : Instances of persistent classes that are not currently associated with a Session. They may have been instantiated by the application and not (yet) persisted or they may have been instantiated by a closed Session.

Transaction (org.hibernate.Transaction) : (Optional) A single-threaded, short-lived object used by the application to specify atomic units of work.
Abstracts application from underlying JDBC, JTA or CORBA transaction. A Session might span several Transactions in some cases. However, transaction demarcation, either using the underlying API or Transaction, is never optional!

ConnectionProvider (org.hibernate.connection.ConnectionProvider) : (Optional) A factory for (and pool of) JDBC connections. Abstracts application from underlying Datasource or DriverManager. Not exposed to application, but can be  extended/implemented by the developer.

TransactionFactory (org.hibernate.TransactionFactory) : (Optional) A factory for Transaction instances. Not exposed to the application, but can be extended/implemented by the developer.

Extension Interfaces : Hibernate offers many optional extension interfaces you can implement to customize the behavior of your persistence layer. See the API documentation for details.

Given a "lite" architecture, the application bypasses the Transaction/TransactionFactory and/or ConnectionProvider APIs to talk to JTA or JDBC directly.

Overview of Spring Framework

Spring is an open source framework, originally created by Rod Johnson and described in his book Expert One-on-One: J2EE Design and Development. Spring was created to address the complexity of enterprise application development, and makes it possible to use plain-vanilla JavaBeans to achieve things that were previously only possible with EJBs. But Spring’s usefulness isn’t limited to server-side development. Any Java application can benefit from Spring in terms of simplicity, testability, and loose coupling.

A 'plain-vanilla' bean/class means a very basic class usually with the following properties:
- Doesn't extend or implement anything
- Has private class variables
- Has an empty constructor
- Has standard getter/setter methods

How does Spring simplify Java development?
Spring employs four key strategies:
- Lightweight and minimally invasive development with plain old Java objects (POJOs)
- Loose coupling through dependency injection and interface orientation
- Declarative programming through aspects and common conventions
- Boilerplate reduction through aspects and templates

Modules
The Spring Framework consists of features organized into modules. These modules are grouped into Core Container, Data Access/Integration, Web, AOP (Aspect Oriented Programming), Instrumentation, and Test, as shown in the following diagram.

CORE SPRING CONTAINER
The centerpiece of the Spring Framework is a container that manages how the beans in a Spring-enabled application are created, configured, and managed.
Within this module you’ll find the Spring bean factory, which is the portion of Spring that provides dependency injection.
Building upon the bean factory, you’ll find several implementations of Spring’s application context, each of which provides a different way to configure Spring.
In addition to the bean factory and application context, this module also supplies many enterprise services such as email, JNDI access, EJB integration, and scheduling.

SPRING’S AOP MODULE
AOP is used in Spring:
- To provide declarative enterprise services, especially as a replacement for EJB declarative services. The most important such service is declarative transaction management, which is build on Spring’s transaction abstraction layer.
- To allow users to implement custom aspects, complementing their use of OOP with AOP. The Spring AOP module also introduces metadata programming to Spring. This is used to add annotation to the source code that instructs Spring on where  and how to apply aspects.

DATA ACCESS AND INTEGRATION
Working with JDBC often results in a lot of boilerplate code that gets a connection, creates a statement, processes a result set, and then closes the connection. Spring’s JDBC and data access objects (DAO) module abstracts away the boilerplate code so that you can keep your database code clean and simple, and prevents problems that result from a failure to close database resources. This module also builds a layer of meaning-ful exceptions on top of the error messages given by several database servers. No more trying to decipher cryptic and proprietary SQL error messages!
For those who prefer using an object-relational mapping (ORM) tool over straight JDBC, Spring provides the ORM module.
Spring’s ORM support builds on the DAO support, providing a convenient way to build DAOs for several ORM solutions. Spring doesn’t attempt to implement its own ORM solution, but does provide hooks into several popular ORM frameworks, including Hibernate, Java Persistence API, Java Data Objects, and iBATIS SQL Maps.
Spring’s transaction management supports each of these ORM frameworks as well as JDBC.
This module also includes a Spring abstraction over the Java Message Service (JMS) for asynchronous integration with other applications through messaging. And, as of Spring 3.0, this module includes the object-to-XML mapping features that were originally part of the Spring Web Services project.
In addition, this module uses Spring’s AOP module to provide transaction management services for objects in a Spring application.

WEB AND REMOTING
The Model-View-Controller (MVC) paradigm is a commonly accepted approach to building web applications such that the user interface is separate from the application logic. Java has no shortage of MVC frameworks, with Apache Struts, JSF, WebWork, and Tapestry among the most popular MVC choices.
Even though Spring integrates with several popular MVC frameworks, its web and remoting module comes with a capable MVC framework that promotes Spring’s loosely coupled techniques in the web layer of an application. This framework comes in two forms: a servlet-based framework for conventional web applications and a portlet-based application for developing against the Java portlet API.
In addition to user-facing web applications, this module also provides several remoting options for building applications that interact with other applications.
Spring’s remoting capabilities include Remote Method Invocation (RMI), Hessian, Burlap,JAX-WS, and Spring’s own HTTP invoker.

TESTING
Recognizing the importance of developer-written tests, Spring provides a module dedicated to testing Spring applications.
Within this module you’ll find a collection of mock object implementations for writing unit tests against code that works with JNDI, servlets, and portlets. For integration-level testing, this module provides support for loading a collection of  beans in a Spring application context and working with the beans in that context.

JavaServer Faces (JSF) Overview

In short, JSF is a UI component framework for J2EE applications.

Component Model

We will see an improvement in productivity with JSF using UI components that hide most of the grunt work of integrating richer functionality into Web applications. The goal is to provide an easy way to construct UIs from a set of reusable UI components. We can use these components to construct a page and nest UI components within each other to get the desired effect.

This structure of nested components is often referred to as a parent-to-child relationship and visualized as a UI component hierarchy. This UI component hierarchy represents a JSF page description at runtime.

Navigation Model

JSF provides a declarative navigation model, which allows application developers to set navigation rules to define the navigation from one view to another in a Web application. 

Navigation rules in JSF are defined inside the JSF configuration file, faces-config.xml, and are page-based. 

This code shows a navigation rule configured in faces-config.xml :

<navigation-rule>

<from-view-id>/login.jspx</from-view-id>

<navigation-case>

<from-outcome>success</from-outcome>

<to-view-id>/result.jspx</to-view-id>

</navigation-case>

</navigation-rule>

From a view, login.jspx, on an outcome of success, the user will be sent to a page called result.jspx. 

The outcome is the return value from an action performed in the application such as a button being clicked. 

Application Lifecycle

Another benefit that application developers will discover when using JSF is that the framework helps manage UI state across server requests. 

Instead of having to take care of user selections and passing these selections from page to page, the framework will handle this for you. 

The JSF framework also has built-in processes in the lifecycle to assist with validation, conversion, and model updates.

How Struts 2 works

The high-level design of Struts 2 follows the well-established Model-View-Controller design pattern.
The MVC design pattern identifies three distinct concerns: model, view, and controller.
In Struts 2, these are implemented by the action, result, and FilterDispatcher, respectively.

An application has any number of actions to handle whatever set of commands it exposes to the client. The controller, after receiving the request, must consult its mappings and determine which of these actions should handle the request.
Once it finds the appropriate action, the controller hands over control of the request processing to the action by invoking it. This invocation process, conducted by the framework, will both prepare the necessary data and execute the action’s business logic. When the action completes its work, it’ll be time to render a view back to the user who submitted the request. Toward this end, an action, upon completing its work, will forward the result to the Struts 2 view component.

CONTROLLER—FILTERDISPATCHER : 
The controller’s job is to map requests to actions.
The role of the controller is played by the Struts 2 FilterDispatcher.
This important object is a servlet filter that inspects each incoming request to determine which
Struts 2 action should handle the request. You just need to inform the framework which request URLs map to
which of your actions. You can do this with XML-based configuration files or Java annotations.

MODEL—ACTION :
The model is implemented by the Struts 2 action component.
The model is the internal state of the application.
This state is composed of both the data model and the business logic.

A Struts 2 action serves two roles.
* First, an action is an encapsulation of the calls to business logic into a single unit of work.
* Second, the action serves as a locus of data transfer.

VIEW—RESULT :
The view is the presentation component of the MVC pattern.

In the figure, the FilterDispatcher has already done its controller work by selecting the appropriate action to handle the request. The figure demonstrates what really happens when the action is invoked by the controller.

INTERCEPTORS
There is a stack of interceptors in front of the action.
The invocation of the action must travel through this stack.
most every action will have a stack of interceptors associated with it.
These interceptors are invoked both before and after the action
Interceptors don’t necessarily have to do something both times they fire, but they do have the opportunity.
Some interceptors only do work before the action has been executed, and others only do work afterward.
The important thing is that the interceptor allows common, cross-cutting tasks to be defined in clean, reusable components that you can keep separate from your action code.

What kinds of work should be done in interceptors? Logging is a good example.
Logging should be done with the invocation of every action, but it probably shouldn’t be put in the action  itself.
Why? Because it’s not part of the action’s own unit of work. It’s more administrative, overhead if you will.
Earlier, we charged a framework with the responsibility of providing built-in functional solutions to common domain tasks such as data validation, type conversion, and file uploads. Struts 2 uses interceptors to do this type of work.
While these tasks are important, they’re not specifically related to the action logic of the request. Struts 2 uses
interceptors to both separate and reuse these cross-cutting concerns. Interceptors play a huge role in the Struts 2 framework.

THE VALUESTACK AND OGNL
The ValueStack is a storage area that holds all of the data associated with the processing of a request.
OGNL (Object-Graph Navigation Language) is the tool that allows us to access the data we put in that central repository.
More specifically, it is an expression language that allows you to reference and manipulate the data on the ValueStack.

Understanding the Flow of Execution for a Struts 1.x application

1. The browser makes a request to the Struts application that is processed by ActionServlet (Controller).

2. ActionServlet (Controller) populates the ActionForm (View) object with HTML form data and invokes its validate( ) method.

3. ActionServlet (Controller) executes the Action object (Controller).

4. Action (Controller) interfaces with model components and prepares data for view.

5. Action (Controller) forwards control to the JSP (View).

6. JSP (View) uses model data to generate a response to the browser.