B. WEB APPLICATION ARCHITECTURE MODELS 1. Web application, what, why and how? 2. N-Tier architecture 3. Historical review of architecture models 4. How does this relate to MVC? 83
B.1 Web application, what, why and how? 84 WHAT IS A WEB APPLICATION? [wikipedia.org] A web application is an application that is accessed over a network such as the Internet or an intranet. The term may also mean a computer software application that is hosted in a browser-controlled environment or coded in a browser-supported language and reliant on a common web browser to render the application executable [ ] Web applications can be considered as a specific variant of client-server [sitepoint.com] Web applications are stored on a server and delivered to users over the Internet. A Web application is usually a three-tier structure, comprising a User Service tier (allowing user access to the application), a Business Service tier (allowing the user to carry out complex activities) and a Data. [about.com][shklar & Rosen]A web application is any application that uses a web browser as a client.
B.1 Web application, what, why and how? 85 EMERGENCE OF 2 WORLDS [msdn.com] Also known as a virtual server (in sharepoint v2) and an web site / application pool, web apps allow for logical separation of sharepoint content. Each web app runs under a different process on the IIS web server. [wantii.com] A Java web-app has a fixed directory structure and can be packaged as a WAR file. Java web-apps are self-contained so that their resources, dependent libraries and configuration files are all part of the directory structure. The welldefined layout of a Java web-app allows webapps to be very portable. This portability allows web-apps to be developed and tested in one environment and easily moved to a QE or production web server.
B.1 Web application, what, why and how? 86 WHY DEVELOP A WEB APP? (1/2) Better client maintenance (i.e., thin client) No data stored on the client side Business logic & application data not on the client side Client is standardized (e.g., Web browser, HTTP API) Standardization of architectures No technological patchwork Better development productivity Reusability (e.g., software component, framework, design patterns)
B.1 Web application, what, why and how? 87 WHY DEVELOP A WEB APP? (2/2) Reach a huge amount of user Reach them every time, everywhere (cell phone, computer, etc.) Buisness-to-buisness (B2B) interaction not just buisness-to-employee in a classic information system compose your business processes and services with others Outsource
B.1 Web application, what, why and how? 88 WHAT IS THE COST? 100% availability Web scale (robustness and performance) Application and transaction security New use, new law and juridical aspects (e.g., license) Be ready to provide support Be ready to be dynamic and evolutive: a frozen web app is a dead web app Be fast!
B. WEB APPLICATION ARCHITECTURE MODELS 1. Web application, what, why and how? 2. N-Tier architecture 3. Historical review of architecture models 4. How does this relate to MVC? 89
B.2 N-Tier architecture 90 CLIENT/SERVER MODEL Resources are centralized on the server Server always alive Must be robust to serve many clients Data is not distributed Security is easier Integrity/coherence is easier Examples: FTP, X terminal, web servers Several small machines rather than a huge one Load balancing techniques to avoid bottlenecks
B.2 N-Tier architecture 91 The layer-based architecture is a specialization of the client/server model architecture All Web app could be abstracted to those 3 layers The architecture determines the different types of layers and their interactions
B.2 N-Tier architecture 92 CLIENT/SERVER FOR WEB APPS The separation is always localized in the application layer (i.e., presentation & business logic) UI is always on the client side Data is always on the server side Server side is made of several types of servers: Distributed object server Transaction Processing Monitor Web server (deals with HTTP) Security server (LDAP) Application server (deals with a specific technology) Challenge: deciding what s going to be on the client side and what s going to be on the server side
B.2 N-Tier architecture 93 N-TIER ARCHITECTURE (1/2) The 3-tier model takes the form of a multi-tier or n-tier implementation Each layer, as well interaction between layers, require a specific technology How to avoid the mess?
B.2 N-Tier architecture 94 N-TIER ARCHITECTURE (2/2) Any number of levels arranged above another, each serving distinct and separate tasks A good design and separation of the layers will enable you to replace/change/update any component of your architecture without changing the full stack dynamic world where things change everyday what if your company decides one day to switch from MS to Java?
B.2 N-Tier architecture 95 ADVANTAGES OF A LAYER-BASED ARCHITECTURE Decompose the architecture into layers to decrease the complexity of the application Components themselves can be distributed Component can be added & removed without changing the core of the application e.g., several UIs/clients for the same application (e.g., phone, tablet, browser) e.g., data persistence can be changed (e.g., from files to SQL) without changing the business logic Loose coupling
B.2 N-Tier architecture 96 STRONG COUPLING VS. LOOSE COUPLING Strong coupling: interdependency between the application components Loose coupling: no inter-dependency Easier development, test & maintenance Components can be replaced by other ones achieving the same task (e.g., using other technologies) Removing a component does not kill the other ones Service vision
B.2 N-Tier architecture 97
B.2 N-Tier architecture 98 HOW TO DECIDE? Type of application Web or Intranet What kind of data will be exchanged What are the resources (financial, computing, staff)? Which scale? How many users? What users? Security required? Type of services exchanged Complex and long interaction required vs. simple request-response Support and performance What s already there? Skillpool and core competencies
B.2 N-Tier architecture 99 EVERYTHING IS A TRADE-OFF What you win on one side is lost on the other side! For examples: Thin client are nice to maintain but requires more processing on the server side Less middleware requires more standardization Openness introduces security problems Portability sometimes means less capability Generic is faster than specificity but less specific (e.g., mobile app)
B.2 N-Tier architecture 100 4 AXES FOR QUALITY MANAGEMENT Development Deployment Update & Support Reusability
B.2 N-Tier architecture 101 CLIENT: THIN OR THICK? The thinner the better for portability and maintenance
B.2 N-Tier architecture 102 FAT CLIENT (OR THICK CLIENT) Provides rich functionality independent of the central server For web apps: Java Applet, MS ActiveX, Adobe Flex, or something not in the browser Advantages Fewer server requirements Offline working Better multimedia performance More flexibility
B.2 N-Tier architecture 103 THIN CLIENT Does as little processing as possible and relies on accessing the server each time input data needs to be processed or validated Usually nothing to install on the client side For Web apps: browser, JavaScript, AJAX Very often limited to graphical user interface
B.2 N-Tier architecture 104 PRESENTATION LOGIC LAYER (1/2) Provides an interface for the end user into your application Works with the results of the business logic layer to handle the transformation into something usable and readable by the end user For Web apps: template approaches (e.g., ASP, PHP) Should be separated from the business logic and should not contain any direct access to data Do not simply throw some SQL in your ASP/JSP/PHP, connect to the DB, get the resultset, and loop in their ASP to output the result
B.2 N-Tier architecture 105 PRESENTATION LOGIC LAYER (2/2) The proxy tier is acting on behalf of the distributed logic layer (or end-user's requests) to provide access to the business logic layer required for distributed computing The proxy tier contains the distributed object method Simple Object Access Protocol (SOAP) Common Object Request Broker Architecture (CORBA) Remote Method Invocation (RMI) Distributed Component Object Model (DCOM)
B.2 N-Tier architecture 106 BUSINESS LOGIC LAYER Where the brains of your application resides business rules, data manipulation, algorithms This layer does NOT know anything about HTML, nor does it output it. It shouldn't have any code to access directly the database or the like Object-oriented model and languages used here Enable to encapsulate within the object the logic related to this object e.g., gettotalprice() on ShopingBasket
B.2 N-Tier architecture 107 DATA ACCESS LAYER Generic methods to interface with your data Object-relational mapping (ORM) e.g., creating/opening/closing DB connection, parse/load file It is a reusable interface to the database Data Access Object (DAO) Abstract interface to some type of persistence mechanism (database, files, etc.), providing some specific operations without exposing details converting data btw incompatible type systems in object-oriented programming languages. creates, "virtual object database" that can be used from within the programming language e.g. hibernate, JPA
B.2 N-Tier architecture 108 DATA LAYER This layer is only intended to deal with the storage and retrieval of information doesn't care about how you plan on manipulating this data Do not place business logic in here, no matter how tempting Types of storage Relational database i.e., SQL Object database Plain text or binary files XML or other semi-structured files (CSV, XLS) RDF triple store Any other means to store the data persistently Must ensure persistence & integrity
B.2 N-Tier architecture 109 DATA LAYER WITH STORED PROCEDURES The data tier also should include your stored procedures Subroutine available to applications accessing a relational database system stored directly in the DBMS e.g., data validation, access control mechanisms Extensive or complex processing that requires the execution of several SQL statements all applications call the stored procedures
B.2 N-Tier architecture WHAT ABOUT THE LINKS BETWEEN THOSE LAYERS? 110 This is usually done by the middleware No unified middleware patchwork! Framework (e.g., J2EE &.NET) to implement unified middleware Middleware tends to disappear with Service- Oriented Architectures that are loose-coupled
B.2 N-Tier architecture 111 TYPES OF MIDDLEWARE Data access middleware connect applications to data Remote Procedure Call (RPC) client makes calls to procedures running on remote systems (usually synchronous) Object Request Broker (i.e., RPC for remote object) enable communication between distributed objects e.g., CORBA, DCOM, RMI Transaction Processing Monitor deals with transaction Message Oriented Middleware enables communication between application (usually asynchronous) e.g., SOAP
B. WEB APPLICATION ARCHITECTURE MODELS 1. Web application, what, why and how? 2. N-Tier architecture 3. Historical review of architecture models 4. How does this relate to MVC? 112
B.3 Historical review of architecture models 113 REVIEW OF ARCHITECTURE MODEL Let s review a bit what was done in the past to help us figure out architectural choices Before the Web Thin C/S Data oriented C/S Distributed C/S Object oriented distributed C/S Web applications architecture HTML/Web C/S Mobile code C/S Service Oriented Architecture
B.3 Historical review of architecture models 114 3 COMPARISON CHARACTERISTICS Type of data exchanged Presentation data only Raw data extracted from the data layer Remote Procedure Calls Serialized data Communication mode Stateful/connected Stateless/not connected Business logic localization Mainly on the server side Mainly on the client side
B.3 Historical review of architecture models 115 GENERIC C/S ARCHITECTURE
B.3 Historical review of architecture models 116 THIN CLIENT C/S Type of data exchanged Presentation data only Communication mode Connected Business logic localization 100% on the server side
DATA ORIENTED C/S B.3 Historical review of architecture models 117 Appeared with PC in the 80 s Let s use PCs potential All the data processing happen on the client side Not present anymore today Too hard to maintain bad! Type of data exchanged SQL queries + data Communication mode Connected Business logic localization Mostly on the client side
DISTRIBUTED C/S B.3 Historical review of architecture models 118 Beginning of the 90 s apparition of stored procedures but this is not enough to fix Data C/S architecture apparition of the application (i.e., business logic) tier with application servers and remote procedure calls Type of data exchanged [1] RPC calls (btw client et app) [2] Data (btw app and DB server) Communication mode Connected Business logic localization Mostly on the server side Specifically located in the application server
B.3 Historical review of architecture models 119 OBJECT ORIENTED DISTRIBUTED C/S (1/2) Appear with the explosion of object-oriented languages & models (mid 90 s) OMG proposes Common Object Request Broker Architecture (CORBA) Based on new middleware: ORB Enable remote object message passing (with IIOP or RMI) Takes the form of an object with methods enabling connection to the objects being served. After an object connects to the ORB, the methods of that object become accessible for remote invocations
B.3 Historical review of architecture models 120 OBJECT ORIENTED DISTRIBUTED C/S (2/2) New with CORBA: normalized architecture implemented by several editors Multiplication of server is easier The very first step toward interoperability ORB can be different on the client and server side But this is still a nightmare to set up Type of data exchanged Object messages (btw client et app) Data (btw app and DB server) Communication mode Connected Business logic localization Mostly on the server side Specifically located in the application server
B.3 Historical review of architecture models 121 THE WEB REQUIRE MORE! All of these architecture seen before where more or less before the Web The Web require more! More openness More standardization More security (e.g., firewall) More speed (network bandwidth used to be limited) More simplicity
HTML/WEB C/S B.3 Historical review of architecture models 122 Over HTTP, apparition of the web servers in the mid 90 s The web server replace the middleware Similar to the thin client C/S but on the Web and via HTTP (i.e., asynchronous) Type of data exchanged Presentation data: HTTP messages with HTML content (btw client et app) Data (btw app and DB server) Communication mode Not connected Business logic localization Mostly on the server side Specifically located in the application server
B.3 Historical review of architecture models 123 DATA ORIENTED MOBILE CODE C/S Similar to data oriented C/S but for the Web Code previously downloaded from the web server, then the client talk to the DB server Less maintenance of the client Type of data exchanged [1 ]Code first then [2] SQL queries + data Communication mode Connected using session Business logic localization 100% on the client side
DISTRIBUTED (OBJECT) MOBILE CODE C/S B.3 Historical review of architecture models 124 Similar to the distributed C/S but for the web code previously downloaded from the web server then the client talk to the app server Type of data exchanged [1] Code first then [2] RPC calls (btw client et app) [3] Data (btw app and DB server) Communication mode Connected using session Business logic localization Mostly on the server side Specifically located in the application server
B.3 Historical review of architecture models 125 DISTRIBUTED MOBILE CODE C/S Idem, without distributed object protocols Type of data exchanged [1] Code first then [2] RPC calls (btw client et app) [3] Data (btw app and DB server) Communication mode Not connected via HTTP Business logic localization Mostly on the server side Specifically located in the application server
EXAMPLES B.3 Historical review of architecture models 126 Type Description HTML/Web CS Serveur Web : Serveur Web iplanet Serveur d application : IBM WebSphere hébergeant des servlets qui accèdent à des composants EJB Source de données : transactions CICS sur OS390 Data Oriented Mobile Code C/S Distributed (Object) Mobile Code C/S Client : applet Java Protocole de communication C/S : protocole propriétaire Oracle mis en œuvre par le driver JDBC (Java Database Connectivity) de l éditeur Source de données : base de données relationnelle Oracle Client : applet Java (utilisant l ORB RMI) Protocole de communication entre client et serveur d application : Remote Method Invocation (RPC objet pour Java) Serveur d application : BEA WebLogic Application Server Protocole de communication entre serveur d application et base de données : protocole propriétaire véhiculant un dialogue SQL. Source de données : base de données relationnelle Sybase
B.3 Historical review of architecture models A NEW ELEMENT: THE APPLICATION SERVER 127 A software framework dedicated to the efficient execution of procedures for supporting the construction and execution of applications ( ) acts as a set of components accessible to the software developer through APIs defined by the platform itself. For web applications, these components are usually performed in the same machine where the web server is running, and their main job is to support the construction of dynamic pages. Target much more than just web pages generation, they implement services like clustering, fail-over and load-balancing, so developers can be focused just on implementing the business logic 2 main classes of application servers J2EE (or JEE): Sun/Oracle, IBM, HP, BEA, etc..net: Microsfot
B.3 Historical review of architecture models 128 ROLE OF THE APPLICATION SERVER Hosting environment for multi-tier application : aggregation of software components includes: server side scripting, RPC middleware, some persistence service, deployment tools
B.3 Historical review of architecture models 129 A BUNCH OF APIS An Application Programming Interface (API) is an interface implemented by a software program that enables it to interact with other software Every service within the application server is defined by an API e.g., J2EE APIs http://download.oracle.com/javaee/1.3/tutori al/doc/overview7.html
B.3 Historical review of architecture models 130 SOFTWARE COMPONENTS (1/2) Piece of software that provides a public interface to describe it s methods (i.e., what the it does) properties (i.e., what characterize it) events (i.e., what events the it catches) Implementation of the component is hidden to the software that uses the component J2EE: Java Beans (and Enterprise Java Beans).NET: COM etc.
B.3 Historical review of architecture models 131 SOFTWARE COMPONENTS (2/2) Component will support the separation of presentation logic and business logic Application server contains several types of component e.g., J2EE: Client component (e.g., Applet) Web components (e.g., Servlet) Business components (e.g., EJB) Facilitates MVC design e.g., Struts framework
APPLICATION SERVER GENERIC ARCHITECTURE B.3 Historical review of architecture models 132
B. WEB APPLICATION ARCHITECTURE MODELS 1. Web application, what, why and how? 2. N-Tier architecture 3. Historical review of architecture models 4. How does this relate to MVC? 133
B.4 How does this relate to MVC? 134
B.4 How does this relate to MVC? 135 REMINDERS ABOUT MVC Separating content (the model) from presentation (the view) when a model changes its state, it notifies its associated views so they can be refreshed Increase application flexibility confusing the map and the territory Appropriate division of responsibility designers and programmers MVC is a architectural pattern for software engineering not originally for web app
B.4 How does this relate to MVC? 136 ARE N-TIER WEB APPS MVC? N-tier is an technical architecture MCV is higher level design pattern At first glance, classical MVC would be not possible for web apps the key idea of 3-tier architecture is to avoid model-view interactions, because each interaction has to go through the network web apps seen until now fit more into the MVP model
B.4 How does this relate to MVC? 137 MVC VS. MVP
B.4 How does this relate to MVC? 138 HOW TO MVC MORE YOUR WEB APPS? Introduction of the presentation business logic layer i.e., a controller between the view and the model some of it on the client side (AJAX), some of it on the server side (distributed objects) Recent approaches enrich the client with more presentation business logic (i.e., AJAX methods) are simulating model-view interactions UIs can be dynamic (i.e., refreshed) without requesting the web server UI events are caught by specific UI components embedded in the HTML page originally sent by the web server Use a good MVC-based framework (Struts, Ruby on Rails, Spring MVC, etc.)
B.4 How does this relate to MVC? 139 SUMMARY WHAT HAS BEEN DONE UNTIL NOW We have reviewed the main technical bricks of the web We have reviewed the possible web application architectures Next classes Let s learn more about the technologies for web apps Client side Server side (the big piece!)
B.4 How does this relate to MVC? 140 PRESENTATION OF NEXT CLASSES First, within the very frequent HTML/Web client/server architecture CGI, Servlet, JSP, ASP Client side with mobile code approaches Applet, Active X Then, client & server side with distributed object approaches CORBA, RMI, DCOM Then, client & server sides with Web application framework J2EE,.NET