Download - Application Architectures
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
ViewThe 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.