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.