Designing Web Applications

Designing Web Applications

• client server architectures

• design patterns

• model 2 web applications

client-server systems

• network of machines, each designated as a client or server

• not exclusive to intranet systems– but large web sites now the main examples– account here is web and eCommerce-biased

• different levels of complexity exist– related to more sophisticated functionality

• peer-to-peer network– any machine has client and server roles

client-server systems

• client– active (master)– sends requests– awaits response

• server– passive (slave)– waits for requests– serves requests and sends a response

thin client vs fat client

• thin client– function is mainly presentational

• e.g. standard browser functionality

– all significant processing done by server– client-server communication is frequent

• fat client– significant processing on client– e.g. Java applet, Flash, JavaScript– less communication required, less server load

2-tier client-server architecture

• client (browser)– http request– mainly for presentation of information– serving mainly static (D)HTML pages

• server (simple web server)– http response– web-server processing http– perhaps SSI, simple CGI– earliest and low-end web-sites

3-tier client-server architecture

• 3rd tier is a database layer– data persists beyond request and response

• server layer– expanded functionality

• database connectivity• user authentication and sessions• perhaps multi-threading

• client layer (web browser)– forms interface to interact with data

a typical 3-tier architecture

database/file system

webserver

andprograms

webbrowser

presentation tier logic tier data tier

multi-tier architecture• additional business logic layer(s)• middleware

– preprocessing and error handling– sophisticated transaction management

• multiple middle-ware servers– server farms linking to database layer

• web layer– standard web server

• JSP/Servelets | ASP.NET | ColdFusion |PHP

web applications

• Applications delivered over the web!

• Many server side components– N-tier architecture

• Very wide range of functionality– web mail– online retail sales and auction sites– wikis, discussion boards, weblogs– multi-player online role-playing games, etc…

software components of a web app

• web server– configuration files

• general processor components– e.g. PHP, ASP processor, XSLT processor

• application-specific software– servelets– scripts

data components of a web app

• databases– possibly distributed or mirrored

• session information– stateful servers retain session information– may persist in a database

• global information– shared by all or many web app processes– e.g. number of hits on the site, user profiles

file components of a web app

• web pages– html files, stylesheets– script files, applets– images

• dynamically generated pages– templates, e.g. PHP, ASP pages– xml files

• web app architecture– structure definition and global data files

design problems

• construction and testing– how do we build a web application?– what technology should we choose?

• re-use– can we use standard components?

• scalability– how will our web application cope with

• large numbers of requests?• large volumes of data exchanged?

design problems

• security– how do we protect against attack?

• viruses• malicious data access• denial of service

– different data views• user types• individual accounts• data protection

design patterns

• a design pattern is a general solution to a common software design problem

• provides a development template

• OO design patterns:– relationships and interactions between objects

• not a finished design– the pattern must be adapted to the application– cannot simply translate into code

design patterns

• originally developed for architecture– Christopher Alexander

• ideas were adapted to OO Design– Beck and Cunningham, 1987– Design Patterns: elements of Re-useable

Object-oriented software, 1994• Reprinted and analysed many times

• now widely-used in software engineering

The Model-View-Controller Pattern

• very widely used pattern

• allows separation of development effort

• model– contains data and system state

• view– presents data and system state

• controller– handles events affecting model or view

model-view-controller

• model knows little about the view– simply signals changes (alerts listeners)

• view understands the model interface– uses model methods to get update data

• controller knows model and view interfaces– updates model in response to events– updates view in response to events or changes

in the model

model-view-controller

model

view controller

event

event is passed to the controller

controller updates model and/or view

controller updates model and/or view

view queries model

model signals changes

example

• design and build a computer Monopoly game

• model– ???

• view– ???

• controller– ???

Monopoly model

• game state– board data

• properties• cards (chance and community chest)

– player data• money and properties owned, token, location

– rules• pay rent• build houses and hotels• Go to Jail

Monopoly View

• Representation of game state

• Various views possible

• Simple text– List of players, positions, properties owned,…

• Graphic presentation– Image of Monopoly Board– Visual positioning of players– Visualisation of money, properties owned,…

Monopoly view

Monopoly controllerstart game

select next player

player move

end player turn

playerbankrupt?

N

end game

gamewon?

Y

Y

N

remove player

updates tomodel and view

advantages of M-V-C

• clarity of design– model methods give an API for data and state– eases the design of view and controller

• efficient modularity– any of the components can be easily replaced

• multiple views– many views can be developed as appropriate– each uses the same API for the model

advantages of M-V-C

• easier to construct and maintain– simple (text-based) views while constructing– more views and controllers can be added– stable interfaces ease development

• distributable– natural fit with a distributed environment

• powerful user interfaces– controller supports “macro-like” interaction

with the model API

developing a M-V-C app

• build the model– public methods become the interface for views and

controller– build simple views to test the model

• build the view(s)– use simple controllers to test view and model

• build the controller– implement handling of all events

• maintain– model remains fairly stable, views and controller may

become more elaborate

M-V-C for web applications

Model for Web Applications

• model consists of data and system state

• database tables– persistent data

• session information– current system state data

• business logic (eCommerce)– rules governing the transaction

View for web applications

• view gives a presentation of the model

• client-side presentation in a browser window– (D)HTML– CSS stylesheets– server-side templates

• administrative information– server output logs

Controller for web applications

• controller handles events

• user-generated events– client-side scripting– http request processing– redirection– preprocessing

• system maintenance– web application management

M-V-C Example

PHP/CGI

WebServer

WebBrowser

presentation request processing program logic

controllerview model

two-tier client-server architecture

M-V-C Example

JSP/ASP/CF

WebServer

WebBrowser

entity

entity

database

view

controller

view/controller model

model

multi-tier client server architecture

development of absence monitoring web app

• model data– student ids and names– number of absences

• model API– list names– list names and absences– update absences

• implement as a relational database

development of absence monitoring web app

• views– attendance register– list of absences– add a student– delete a student

• implemented in a browser– DHTML interface– pages dynamically generated from model

development of absence monitoring web app

• controller– handle requests for views

• generate correct page from the database

– update the model• translate user action into a database update

– update the views• refresh browser when view changes

build the model

• design data structure• implement tables• create SQL queries

– support all required functionality

• test queries against sample data– this is a simple view

build the view

• develop server side scripts to query the database– SQL already tested is

the model API

• design web pages and embed the scripts– view now updates

from the model

build the controller

• add client side scripts– JavaScript– HTML forms– input validation

• add navigation functionality– frames– layers

• update confirmation pages

web application frameworks

web application frameworks

• technologies designed to implement web apps in M-V-C– model 2 architecture

• provide standard re-useable components for model, view and controller

• greatly ease the design of large sophisticated web apps

• significant learning curve

web application frameworks

• typically xml configuration files “glue” components into an application

• implement standard web concepts– interface features (forms)– request and response objects– sessions– database interactions

• many frameworks exist

web application frameworks

• Many frameworks are being developed…– JavaServer Faces, Struts, Webwork2– WebObjects (.NET specific)– Model Glue (ColdFusion specific)– Velocity, Fusebox, Mach II, Maypole, Catalyst,

Tapestry, ZNF, Phrame, Cocoon, Ruby on Rails, …

• Most, but not all, are based around M-V-C