www architecture i - graz university of...

WWW Architecture ISoftware Architecture VO/KU (707.023/707.024)

Denis Helic, Roman Kern

KMI, TU Graz

Nov 28, 2012

Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture I Nov 28, 2012 1 / 67

Section

Recap


Recap

Software architecture related to multiple views

Conceptual view

Implementation view

Execution view


Recap

Conceptual view

Focuses on domain-level responsibilities

Initial architectural design

First response to stakeholder needs

Design by analyzing requirements

Contains components and connectors (box-and-line)


Recap

Implementation view

Focuses on how the system is built

Which technological elements are needed to implement the system

Software packages, libraries, frameworks, classes, ...

Addresses non-runtime quality attributes: configurability, testability,reusability, ...

Comprised of components and connectors


Recap

Execution view

Focuses on the system runtime structure

Hardware elements, subsystems, processes and threads

Suited for examining quality attributes, most-notably runtimeattributes

E.g. performance, security, usability, ...

But also e.g. scalability

Similarly to conceptual architecture comprised of components andconnectors


Outline

1 Introduction

2 Quality Requirements

3 Web Architecture

4 Web Systems

5 Web Applications

6 Web n-Tier Architecture

7 Web Data Management


Introduction

Section

Introduction


Introduction

The Web

Started as a static information system

Hypermedia: documents linked into a web

By following links users retrieve the documents

Based on HTTP, HTML, URL (global addressing schema)

All components very simple: the major reason for the huge success


Introduction

Systems’ Rate of Growth

Time to reach 50 million people

Telephone 75 yearsRadio 35 yearsTV 13 yearsThe Web 4 years


Introduction

Functional Requirements

Berners-Lee: “Web’s major goal was to be a shared information spacethrough which people and machines could communicate.”

A way for people to structure their information

Usable for themselves and others

A way to reference and structure information provided by others

Cross-platform, global scope


Quality Requirements

Section




Quality attributes

Usability: it must be very easy to use

I.e. very easy to create, structure and reference information

Participation was voluntary and it was the only possibility to attractthe users

Very error forgiving in structuring and referencing because ofnon-technical background of users



Quality attributes

Technical simplicity: it must be very easy for developers toimplement

All components simple and text-based

I.e the first version of HTTP: servers need to respond to the GETmethod

HTML very simple: easy to write parsers and browsers

URLs extremely simple



Quality attributes

Extensibility: it must be easy to add new features

The first versions of components very simple - improvements wereneeded

User requirements change even in a closed environment

In a global scope the change is only feature that does not change

E.g. very soon users wanted to have search facility apart browsing -HTML forms were introduced



Quality attributes

Scalability: it needs to match the Internet-scale

More precisely: anarchic scalability

The Internet is not under control of a single organization – it istotally decentralized

Need to continue operating when under an unanticipated load ormalformed or maliciously constructed data



Quality attributes

Anarchic scalability: consequences

Clients cannot be expected to maintain knowledge of all servers

Servers cannot be expected to retain knowledge of state acrossrequests

Documents cannot have back-links: the number of references to aresource is proportional to the number of people interested in thatinformation



Development of The Web

The original Web was not designed to meet all of therequirements and quality attributed defined above

It lacked also an architectural vision at that time that would meetthese ambitious requirements

Web Consortium was founded to solve these problems

A lot of researchers worked on defining an architecture to meet theseneeds


Web Architecture

Section

Web Architecture


Web Architecture

Deriving the Web architecture

Introducing constraints on the Web architecture to obtain an optimalsolution to the requirements and quality attributes

Each constraint will have advantages and disadvantages

The whole design process is then a balancing process

Optimisation to obtain a best-match for the Web architecture


Web Architecture

Client-server

Figure: Client-server style


Web Architecture

Client-server

Separation of concerns

Separates user-interface from data manipulation concerns

Supports independent evolvability

E.g. clients and servers can be developed independently and acrossorganizational boundaries

Supports Internet-scale attribute


Web Architecture

Stateless

Figure: Stateless server


Web Architecture

Stateless

Communication must be stateless in nature

Each request from client must contain all the information needed toprocess that request

I.e. it can not take advantage of session information stored on theserver

Session state is completely on the client


Web Architecture

Stateless

Supports visibility, reliability and scalability

Visibility: only look at a single request to determine the full nature ofthe request

Reliability: it eases the task of recovering from partial failures

Scalability: not having to store state between requests allows theserver component to quickly free resources

Scalability: simplifies implementation because servers do not need tomanage information across multiple requests


Web Architecture

Cache

Figure: CacheDenis Helic, Roman Kern (KMI, TU Graz) WWW Architecture I Nov 28, 2012 26 / 67

Web Architecture

Cache

Information can be labeled (by servers) as cachable

If a response is cacheable, then a client cache is given the right toreuse that response data for later, equivalent requests

Improves efficiency, scalability, user-perceived performance

Decreases reliability if the data does not match

Midway: ask a server if the data has changed


Web Architecture

Uniform interface

Figure: Uniform Interface


Web Architecture

Uniform interface

Uniform interface between components

Visibility of interactions is improves

Simplifies the overall architecture

Decouples implementations from the services

Improves Internet-scale


Web Architecture

Uniform interface

Uniform interface degrades efficiency

Information is accessed and transferred in a standardized form ratherthan in an application specific form

To define a uniform interface we need:

Identification of resources (URL)

Manipulation of resources through representations (HTML, recentlyXML)

Self-descriptive messages (GET, POST, PUT, DELETE in HTTP)


Web Architecture

Layered system

Figure: Layered system


Web Architecture

Layered system

Improves Internet-scale

Application composed of layers that are only aware of theneighbouring components not the complete system

Bounds complexity and promotes independence between components

Supports scalability by introduction of proxies, shared-caches,gateways

E.g. load-balancing behind a gateway

Reduce user-perceived performance because they add processingoverhead


Web Architecture

Code on demand

Figure: Code on demand


Web Architecture

Code on demand

Client functionality can be extended by downloading code

E.g. Java applets, Flash, JavaScript

Improves extensibility

Independent development


Web Systems

Section

Web Systems


Web Systems

The Evolution of the Web

The Web evolved as a platform

Started out with simple Homepages with static documents

Developed more and more interactivity

Finally into a complex system of different types


Web Systems

Types of Web Systems


Web Systems

The Web

Two faces of the Web

The Web as an application platform

The Web as a huge distributed database


Web Applications

Section

Web Applications


Web Applications

Specifics of Web applications

What are the issues when building Web applications?

User requirements

User interface and usability

Application state (manage state) and hypertext (navigate)

Addressability

Architecture


Web Applications

Application state on the Web: Hypertext

Traditionally, application logic manages the application state

E.g., the current state of the data, user inputs, etc.

Typically, Web browsers supported only HTML and does not havedirect connection to the application logic

Communication over network and HTTP with the application logic

Web server needs to track users and sessions

HTTP is stateless (connection-less), need for special mechanics

E.g., session id in cookies or added to the URL


Web Applications

Typical Stack of Web-Applications


Web Applications


However, Web server provides only low-level tracking

Responsibility of the application logic to manage sessions

Manage it within the application server

Application server has other responsibilities as well

⇒ Can lead to serious scalability problems


Web Applications


We can move session management to the client?

Transfer parts of the application logic into the client(Code on demand)

E.g. Manage it there with AJAX(Asynchronous JavaScript and XML)

But other problems arise

How to recover states with a new session: AJAX applications havetypically single URLs?

How to recover previous state, i.e. browser back button problem?


Web Applications


The optimal solution is typically somewhere in the middle:

⇒ Manage only important states on the server

Manage those states with unique URLs

E.g. each important application state has a new unique URLs

Use linking to relate states to each other

No management of the state on the server: no scalability problems

No management of the state on the client: no recovery problems


Web Applications


Example: Google Maps

Google Maps uses AJAX to maintain a permalink

Any action that you execute changes the permalink

The permalink is kept as a part of HTML

This is the equivalent of the address bar


Web Applications

Example: Google Maps Permalink


Web Applications


A little bit of extra DOM/JavaScript work keeps the Permalink up todate as you navigate

Every point on the map is a separate application state that has itsown URL

Application states were destroyed by AJAX but was put back byapplication design

It allowed communities to grow around the Google Maps application

Only because of proper management of application states with URLs


Web Applications

Addressability

URL as the addressing schema

For example:

/student/add

/student/show

/student/exam/add

/student/exam/show

Allow you to share application states for UI and services

Just offer different content representations

E.g. for UIs: HTML, for services: XML or JSON


Web Applications

Addressability

Advantages for humans (UIs)

Meaningful, easier for humans

URL can be bookmarked

Search engines can retrieve different parts and index it

Advantages for service integration

You might link services to each other


Web n-Tier Architecture

Section




Architecture: User-oriented database applications

In traditional software engineering UODA are built with an N-tierarchitecture

They started as 2-layer applications

Data management layer and application/presentation layer



Architecture: 2-layer applications

Relational database as the Data Management layer

Scripts (e.g. PHP) as application/presentation layer

One and the same scripts implements application logic and thepresentation (e.g. generating of HTML)

Everything runs on the server



Architecture: Problems of 2-layer applications

Mixture of application and presentation related functionality

Changes in application logic lead to changes in presentationfunctionality and vice versa

E.g. changing a table that present some application data leads tochanges in the return values of some application specific functions

Even more dangerous the presentation layer talks directly to the DML

⇒ Better modularity is achieved with the third layer




Separation between Application and Presentation layer

No direct connection between Presentation and Data Management

Decoupling of Application and Presentation layer

Possibility to exchange Presentation layers

Example: making a Web gateway to an existing application

The old GUI (e.g. a standalone GUI) is replaced with a Web GUI




Presentation tier: HTML, templates and scripts to generate HTML

Application logic tier: the actual application, the business logic

Data access tier: manages persistent application data




With introduction of AJAX different possibilities where to situate tiers

E.g. presentation in browser: HTML + (presentation) JavaScript,application and data access on server

E.g. presentation and application in browser: HTML + (presentationand application) JavaScript, data access on server

Note: May require additional considerations in regard to security (ifthe application logic is done on the client)




There are numerous architecture variants built on the top of N-tierarchitectures

The most important for Web applications: Model-View-Controllerarchitecture

It was invented in the early days of GUIs

To decouple the graphical interface from the application data andlogic

Very useful also for Web applications


Web Data Management

Section

Web Data Management


Web Data Management

Architecture: Data Management

Often Web applications deal with relational databases

Need to manage relational data in object-oriented applications

Use design patterns like Data Access Object (DAO)

Use object/relational mapping (ORM), like Hibernate framework orJPA


Web Data Management


The Web we use is full of data (Web as a database)

Book information, opinions, prices, arrival times, blogs, tags, tweets,etc.

The data is organized around a simple data model: node-link model

Each node is a data item that has a unique address and arepresentation

Representation formats are e.g. HTML, PDF,... for humans, or e.gXML, JSON for programs

Nodes can be interlinked using their unique addresses


Web Data Management


Information retrieval

How to find what I’m looking for?

The mainstream approach are search engines with full-text processing

Another approaches analyze links

Links in databases, or within/between documents/sites

Mixed approach: full-text and links, e.g. Google


Web Data Management


Yet another approach is managing metadata

Metadata is data about other data, often semi-structured

On the web

Tag information items (everything that you can access via URL) in astructured mannerSocial Web 2.0 applications http://del.icio.us/ orhttp://www.flickr.com/

Microformats

⇒ Search inside metadata


http://del.icio.us/

http://www.flickr.com/

Web Data Management

Section

Questions?
