Designing Web Applications

1
Designing Web Applications
2
Designing Web Applications

• client server architectures
• design patterns
• model 2 web applications

3
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

4
client-server systems

• client
• active (master)
• sends requests
• awaits response
• server
• passive (slave)
• waits for requests
• serves requests and sends a response

5
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

6
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

7
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

8
a typical 3-tier architecture
presentation tier
logic tier
data tier
database/ file system
web server and programs
web browser
9
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

10
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

11
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

12
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

13
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

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

15
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

16
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

17
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

18
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

19
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

20
model-view-controller
model
controller updates model and/or view
view queries model
model signals changes
view
controller
controller updates model and/or view
event
event is passed to the controller
21
example

• design and build a computer Monopoly game
• model
• ???
• view
• ???
• controller
• ???

22
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

23
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,

24
Monopoly view
25
Monopoly controller
start game
select next player
player move
updates to model and view
end player turn
N
player bankrupt?
game won?
N
Y
remove player
Y
end game
26
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

27
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

28
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

29
M-V-C for web applications
30
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

31
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

32
Controller for web applications

• controller handles events
• user-generated events
• client-side scripting
• http request processing
• redirection
• preprocessing
• system maintenance
• web application management

33
M-V-C Example
presentation
request processing
program logic
PHP /CGI
Web Server
Web Browser
controller
view
model
two-tier client-server architecture
34
M-V-C Example
model
entity
multi-tier client server architecture
JSP /ASP /CF
Web Server
Web Browser
database
controller
entity
view
view/ controller
model
35
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

36
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

37
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

38
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

39
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

40
build the controller

• add client side scripts
• JavaScript
• HTML forms
• input validation
• add navigation functionality
• frames
• layers
• update confirmation pages

41
web application frameworks
42
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

43
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

44
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