Application Architectures
Vijayan Sugumaran
Department of DIS
Oakland University
Centralized Architecture
Online-Processing/Timesharing
Two-tier (Fat Client)
Three-tier (Thin Client)
N-tier with Object Technology
Web-based Applications
Terminology




J2SE - Java 2 Platform, Standard Edition, provides a
complete environment for writing, deploying, and
running applets and applications in the Java
programming language
J2EE - Java 2 Platform, Enterprise Edition, defines
the standard for developing component-based
multitier enterprise applications
JavaBeans - JavaBeans technology is the
component architecture for the Java 2 Platform,
Standard Edition (J2SE).
EnterpriseJavaBeans - Enterprise JavaBeans (EJB)
technology is the server-side component architecture
for the Java 2 Platform, Enterprise Edition (J2EE)
platform. EJB technology enables rapid and
simplified development of distributed, transactional,
secure and portable applications based on Java
technology
J2EE Platform Overview
MVC Architecture

MVC: Model-View-Controller Architecture

Widely used for interactive applications

It divides functionality among objects involved in
maintaining and presenting data

Minimize the coupling between them

Traditional application tasks (input, processing, and
output) mapped to the graphical user interaction
model

MVC architecture divides applications into three
layers – Model, View, and Controller

Specific tasks and responsibilities for each layer
MVC Architecture Advantages

MVC separates design concerns (data persistence
and behavior, presentation, and control), decreasing
code duplication, centralizing control, and making the
application more easily modifiable
 MVC also helps developers with different skill sets to
focus on their core skills and collaborate through
clearly defined interfaces
 New data sources are easy to add to an MVC
application by creating code that adapts the new data
source to the view API
 New client types are easy to add by adapting the new
client type to operate as an MVC view
 MVC clearly defines the responsibilities of
participating classes, making bugs easier to track
down and eliminate
Model

The model represents business data and
business logic

Operations that govern access and
modification of the business data

Often the model serves as a software
approximation to real-world functionality

It notifies views when it changes and provides
the ability for the view to query the model
about its state

It also provides the ability for the controller to
access application functionality encapsulated
by the model
View
 The
view renders the contents of the
model
 It
accesses data from the model and
specifies how that data should be
presented
 It
updates data presentation when the
model changes.
 The
view also forwards user input to the
controller.
Controller

The controller defines the application behavior
 Dispatches user requests and selects views for
presentation
 Interprets user inputs and maps them into
actions to be performed by the model
 In a stand-alone GUI client, user inputs include
button clicks and menu selections.
 In a Web application, they are HTTP GET and
POST requests to the Web tier.
 The controller selects the next view to display
based on the user interactions and the outcome
of the model operations
 An application typically has one controller for
each set of related functionality
Model-View-Controller Architecture
J2EE Web Application

The Web-tier controller receives each incoming HTTP
request and invokes the requested business logic
operation in the application model

Based on the results of the operation and state of the
model, the controller then selects the next view to display

Finally, the controller generates the selected view and
transmits it to the client for presentation
Model-1 Vs Model-2 Architecture

Model 1







Web browser directly accessing Web-tier JSP pages
The JSP pages access Web-tier JavaBeans that represent
the application model
The next view to display is determined either by hyperlinks
selected in the source document or by request parameters
A Model 1 application control is decentralized, because the
current page being displayed determines the next page to
display
In addition, each JSP page or servlet processes its own
inputs (parameters from GET or POST)
The Model 1 architecture can provide a more lightweight
design for small, static applications
Model 1 architecture is suitable for applications that have
very simple page flow, have little need for centralized
security control or logging, and change little over time.
Model-1 Vs Model-2 Architecture

Model 2

Model 2 architecture introduces a controller servlet between
the browser and the JSP pages or servlet content being
delivered

The controller centralizes the logic for dispatching requests
to the next view based on the request URL, input
parameters, and application state

The controller also handles view selection, which decouples
JSP pages and servlets from one another

Model 2 applications are easier to maintain and extend,
because views do not refer to each other directly

The Model 2 controller servlet provides a single point of
control for security and logging, and often encapsulates
incoming data into a form usable by the back-end MVC
model

For these reasons, the Model 2 architecture is
recommended for most interactive applications
J2EE Design Patterns




Intercepting filter--This pattern applies to request
pre- and post-processing. It applies additional
services needed to process a request.
View helper--A view helper encapsulates the
presentation and data access logic portions of a view,
thus refining the view and keeping it simpler.
Composite view--This pattern makes view
presentation more manageable by creating a
template to handle common page elements for a
view. The composite view template captures the
static features (headers, footers, etc.)
Front controller--This pattern provides a centralized
controller for managing requests. A front controller
receives all incoming client requests, forwards each
request to an appropriate request handler, and
presents an appropriate response to the client
J2EE Design Patterns




Value object--This pattern facilitates data exchange
between tiers (usually the Web and EJB tiers) by
reducing the cost of distributed communication
Session facade--This pattern coordinates operations
between cooperating business objects. It
encapsulates and hides the complexity of classes
that must cooperate, and isolates its callers from
business object implementation changes
Business delegate--This pattern intervenes between
a remote business object and its client, adapting the
business object's interface to a friendlier interface for
the client.
Data access object--This pattern abstracts data
access logic to specific resources. It separates the
interfaces to a systems resource from the underlying
strategy used to access that resource.