WWW Architecture I - KTIkti.tugraz.at/staff/rkern/courses/sa/2013/slides_ · non-technical...

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

Roman Kern

KTI, TU Graz

2013-12-04

Roman Kern (KTI, TU Graz) WWW Architecture I 2013-12-04 1 / 81

Web Development TutorialJava Web Development


Web App - Static Content

Java web application

Most basic way to create a Java web application

... using Servlet

... using JSPs (Java Server Pages)

Example: Maven project

For example using Maven and Tomcat


Web App - Static Content

Example Static Web Application1 mvn archetype:generate -DgroupId=at.tugraz.sa -DartifactId=webapp

-DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

2 mkdir -p src/main/java/at/tugraz/sa

3 kate pom.xml (add the servlet dependency)

4 kate src/main/webapp/WEB-INF/web.xml (add the Hello servlet)

5 kate src/main/java/at/tugraz/sa/HelloServlet.java (add the servlet code)

6 optional: kate src/main/webapp/index.jsp (add some code)

7 mvn package (build the .war file)

8 Copy the target/webapp.war into the webapps directory of Tomcat (or symlink)

9 Start Tomcat, e.g. bin/catalina.sh run

10 Point browser to localhost:8080/webapp/hello/ (for the servlet)

11 optional: Point browser to localhost:8080/webapp/ (for the jsp)


localhost:8080/webapp/hello/

localhost:8080/webapp/

Sample pom.xml (just the dependency part)

<dependency>

<groupId>javax.servlet</groupId>

<artifactId>servlet-api</artifactId>

<version>2.5</version>

<scope>provided</scope>

</dependency>


Sample web.xml

<?xml version="1.0" encoding="UTF-8"?>

<web-app

xmlns="http://java.sun.com/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"

version="2.5">

<servlet>

<servlet-name>Hello</servlet-name>

<servlet-class>at.tugraz.sa.HelloServlet</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>Hello</servlet-name>

<url-pattern>/hello/*</url-pattern>

</servlet-mapping>

</web-app>


Sample Servlet

package at.tugraz.sa;

import java.io.IOException;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

public class HelloServlet extends HttpServlet

{

protected void doGet(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException

{

response.setContentType("text/html");

response.setStatus(HttpServletResponse.SC_OK);

response.getWriter().println("<h1>Hello Servlet</h1>");

response.getWriter().println("session=" +

request.getSession(true).getId());

}

}


Sample JSP

<html>

<body>

<h2>Hello World!</h2>

The time is now <%= new java.util.Date() %>

</body>

</html>


Database Connection

Java database connection

The hard way: JDBC

The more convenient way: Object-Relational Mapping (ORM)

e.g. Hibernate, Java Persistence API (JPA)


Web App - Dynamic Content

Java based dynamic web application

There are many existing libraries to develop dynamic Java webapplications

e.g. Java Server Faces (JSF), Wicket, Struts, Google Web Toolkit(GWT), ...

Separate the client from the server

REST like services on the server

JavaScript application on the client


Web App - Dynamic Content

Example for a Java based dynamic web application

Server-side: REST API → Jersey

Client-side: JavaScript → AngularJS (functionality) + Bootstrap(layout)

The server and the client communicate by exchanging JSON objects.AngularJS supports the Model-View-Controller pattern on the client side.


RecapArchitecture Styles


Recap

Separation of Concerns

Layered Architectures

Client Server Architecture

Model-View-Controller

Decouple

Notification Architectures

Interceptor

Blackboard

Reusability

Pipes and Filters


Recap

Data Integrability

Data Centred Architectures

Client Server Architecture

Performance & Scalability

Data Flow Architectures

Peer to Peer Architecture

Service Architectures


Outline

1 Introduction

2 Quality Requirements

3 Web Protocols

4 Web Architecture

5 Web Systems

6 Web Applications

7 Web n-Tier Architecture

8 Web Data Management


Introduction

IntroductionBasic concepts


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

Quality RequirementsDesign goals of the Web.



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 Protocols

Web ProtocolsBasic Technological Building Blocks


Web Protocols

HTTP Protocol

The Hypertext Transfer Protocol (HTTP) builds the basiccommunication infrastructure

HTTP is a text based protocol between a client and a server

A HTTP request consists of a method and a number of headers

A HTTP response consists of a status code and a number of header

Both, request and response, may contain additional (binary) content


Web Protocols

HTTP Protocol

In the first (wildly used) version of HTTP (1.0):

... the connection between the client and the server is closed after theresponse

... therefore no need to specify the size of the content beingtransmitted

In version 1.1:

... the protocol supports keep-alive to reuse the same connection formultiple request/responses

... a header that specifies the content length is needed


Web Protocols

HTTP Protocol

There are a number of common headers

The cookie header allows the server to store a small piece of data onthe client

... used for session tracking

The content type header specifies the type of the payload andoptionally its encoding

The last change date, or specific hash values help to detect whethercontent has been changes on the server


Web Protocols

HTTP Protocol - Example

Example Request

GET /webapp/hello/ HTTP/1.1

Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86\_64; rv:19.0) Gecko/20100101 Firefox/19.0

Cookie: JSESSIONID=9C6694142332E65F0CB175BDF1758243;

Example Response

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Content-Type: text/html;charset=ISO-8859-1

Content-Length: 64

Date: Mon, 02 Dec 2013 14:46:05 GMT

<content>


Web Protocols

Early Web Applications

Initially Web applications just served static content

The first response to dynamic content has been the CommonGateway Interface (CGI)

... as it has been easy to transform a command line application to aweb application

The web server invokes the application and the standard output isused for the HTTP response

Disadvantage: For each request one needs to spawn a new process


Web Architecture

Web ArchitectureBasic Architecture Styles of the Web


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: CacheRoman Kern (KTI, TU Graz) WWW Architecture I 2013-12-04 40 / 81

Web Architecture

Cache

Information can be labeled (by servers) as cacheable

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

Web SystemsWeb as a Platform


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

Web ApplicationsDevelop Application for the Web


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

Web n-Tier ArchitectureLayered Architecture for the Web



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

Web Data ManagementArchitecture Styles for Data Handling


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

The EndNext: Web Architectures II


WWW Architecture I - KTIkti.tugraz.at/staff/rkern/courses/sa/2013/slides_ · non-technical...

Documents

Transcript of WWW Architecture I - KTIkti.tugraz.at/staff/rkern/courses/sa/2013/slides_ · non-technical...