1 / 20

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.

florence-malone
Download Presentation

Application Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related