1. Application Architectures Vijayan Sugumaran Department of DIS Oakland University

2. Centralized Architecture

3. Online-Processing/Timesharing

4. Two-tier (Fat Client)

5. Three-tier (Thin Client)

6. N-tier with Object Technology

7. Web-based Applications

8. 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

9. J2EE Platform Overview

10. 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

11. 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

12. 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

13. 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.

14. 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

15. Model-View-Controller Architecture

16. 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

17. 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.

18. 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

19. 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

20. 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.