WWW Architecture I. Software Architecture VO/KU ( / ) Roman Kern. KTI, TU Graz

Size: px

Start display at page:

Download "WWW Architecture I. Software Architecture VO/KU ( / ) Roman Kern. KTI, TU Graz"

Colin Lane
6 years ago
Views:

1 WWW Architecture I Software Architecture VO/KU ( / ) Roman Kern KTI, TU Graz Roman Kern (KTI, TU Graz) WWW Architecture I / 81

2 Web Development Tutorial Java Web Development Roman Kern (KTI, TU Graz) WWW Architecture I / 81

3 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

4 Web App - Static Content Example Static Web Application 1 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) Roman Kern (KTI, TU Graz) WWW Architecture I / 81

5 Sample pom.xml (just the dependency part) <dependency> <groupid>javax.servlet</groupid> <artifactid>servlet-api</artifactid> <version>2.5</version> <scope>provided</scope> </dependency> Roman Kern (KTI, TU Graz) WWW Architecture I / 81

6 Sample web.xml <?xml version="1.0" encoding="utf-8"?> <web-app xmlns=" xmlns:xsi=" xsi:schemalocation=" 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> Roman Kern (KTI, TU Graz) WWW Architecture I / 81

7 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()); } } Roman Kern (KTI, TU Graz) WWW Architecture I / 81

8 Sample JSP <html> <body> <h2>hello World!</h2> The time is now <%= new java.util.date() %> </body> </html> Roman Kern (KTI, TU Graz) WWW Architecture I / 81

9 Database Connection Java database connection The hard way: JDBC The more convenient way: Object-Relational Mapping (ORM) e.g. Hibernate, Java Persistence API (JPA) Roman Kern (KTI, TU Graz) WWW Architecture I / 81

10 Web App - Dynamic Content Java based dynamic web application There are many existing libraries to develop dynamic Java web applications 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

11 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. Roman Kern (KTI, TU Graz) WWW Architecture I / 81

12 Recap Architecture Styles Roman Kern (KTI, TU Graz) WWW Architecture I / 81

13 Recap Separation of Concerns Layered Architectures Client Server Architecture Model-View-Controller Decouple Notification Architectures Interceptor Blackboard Reusability Pipes and Filters Roman Kern (KTI, TU Graz) WWW Architecture I / 81

14 Recap Data Integrability Data Centred Architectures Client Server Architecture Performance & Scalability Data Flow Architectures Peer to Peer Architecture Service Architectures Roman Kern (KTI, TU Graz) WWW Architecture I / 81

15 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

16 Introduction Introduction Basic concepts Roman Kern (KTI, TU Graz) WWW Architecture I / 81

17 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

18 Systems Rate of Growth Introduction Time to reach 50 million people Telephone 75 years Radio 35 years TV 13 years The Web 4 years Roman Kern (KTI, TU Graz) WWW Architecture I / 81

19 Introduction Functional Requirements Berners-Lee: Web s major goal was to be a shared information space through 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

20 Quality Requirements Quality Requirements Design goals of the Web. Roman Kern (KTI, TU Graz) WWW Architecture I / 81

21 Quality Requirements 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 attract the users Very error forgiving in structuring and referencing because of non-technical background of users Roman Kern (KTI, TU Graz) WWW Architecture I / 81

22 Quality Requirements Quality attributes Technical simplicity: it must be very easy for developers to implement All components simple and text-based I.e the first version of HTTP: servers need to respond to the GET method HTML very simple: easy to write parsers and browsers URLs extremely simple Roman Kern (KTI, TU Graz) WWW Architecture I / 81

23 Quality Requirements Quality attributes Extensibility: it must be easy to add new features The first versions of components very simple - improvements were needed 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

24 Quality Requirements 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 is totally decentralized Need to continue operating when under an unanticipated load or malformed or maliciously constructed data Roman Kern (KTI, TU Graz) WWW Architecture I / 81

25 Quality Requirements Quality attributes Anarchic scalability: consequences Clients cannot be expected to maintain knowledge of all servers Servers cannot be expected to retain knowledge of state across requests Documents cannot have back-links: the number of references to a resource is proportional to the number of people interested in that information Roman Kern (KTI, TU Graz) WWW Architecture I / 81

26 Quality Requirements Development of The Web The original Web was not designed to meet all of the requirements and quality attributed defined above It lacked also an architectural vision at that time that would meet these ambitious requirements Web Consortium was founded to solve these problems A lot of researchers worked on defining an architecture to meet these needs Roman Kern (KTI, TU Graz) WWW Architecture I / 81

27 Web Protocols Web Protocols Basic Technological Building Blocks Roman Kern (KTI, TU Graz) WWW Architecture I / 81

28 Web Protocols HTTP Protocol The Hypertext Transfer Protocol (HTTP) builds the basic communication 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

29 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 the response... therefore no need to specify the size of the content being transmitted In version 1.1:... the protocol supports keep-alive to reuse the same connection for multiple request/responses... a header that specifies the content length is needed Roman Kern (KTI, TU Graz) WWW Architecture I / 81

30 Web Protocols HTTP Protocol There are a number of common headers The cookie header allows the server to store a small piece of data on the client... used for session tracking The content type header specifies the type of the payload and optionally its encoding The last change date, or specific hash values help to detect whether content has been changes on the server Roman Kern (KTI, TU Graz) WWW Architecture I / 81

31 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/ Firefox Cookie: JSESSIONID=9C E65F0CB175BDF ; Example Response HTTP/ OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=iso Content-Length: 64 Date: Mon, 02 Dec :46:05 GMT <content> Roman Kern (KTI, TU Graz) WWW Architecture I / 81

32 Web Protocols Early Web Applications Initially Web applications just served static content The first response to dynamic content has been the Common Gateway Interface (CGI)... as it has been easy to transform a command line application to a web application The web server invokes the application and the standard output is used for the HTTP response Disadvantage: For each request one needs to spawn a new process Roman Kern (KTI, TU Graz) WWW Architecture I / 81

33 Web Architecture Web Architecture Basic Architecture Styles of the Web Roman Kern (KTI, TU Graz) WWW Architecture I / 81

34 Web Architecture Deriving the Web architecture Introducing constraints on the Web architecture to obtain an optimal solution 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

35 Client-server Web Architecture Figure: Client-server style Roman Kern (KTI, TU Graz) WWW Architecture I / 81

36 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 across organizational boundaries Supports Internet-scale attribute Roman Kern (KTI, TU Graz) WWW Architecture I / 81

37 Stateless Web Architecture Figure: Stateless server Roman Kern (KTI, TU Graz) WWW Architecture I / 81

38 Web Architecture Stateless Communication must be stateless in nature Each request from client must contain all the information needed to process that request I.e. it can not take advantage of session information stored on the server Session state is completely on the client Roman Kern (KTI, TU Graz) WWW Architecture I / 81

39 Web Architecture Stateless Supports visibility, reliability and scalability Visibility: only look at a single request to determine the full nature of the request Reliability: it eases the task of recovering from partial failures Scalability: not having to store state between requests allows the server component to quickly free resources Scalability: simplifies implementation because servers do not need to manage information across multiple requests Roman Kern (KTI, TU Graz) WWW Architecture I / 81

40 Web Architecture Cache Figure: Cache Roman Kern (KTI, TU Graz) WWW Architecture I / 81

41 Web Architecture Cache Information can be labeled (by servers) as cacheable If a response is cacheable, then a client cache is given the right to reuse 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

42 Uniform interface Web Architecture Roman Kern (KTI, TU Graz) WWW Architecture I / 81

43 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

44 Web Architecture Uniform interface Uniform interface degrades efficiency Information is accessed and transferred in a standardized form rather than in an application specific form To define a uniform interface we need: Identification of resources (URL) Manipulation of resources through representations (HTML, recently XML) Self-descriptive messages (GET, POST, PUT, DELETE in HTTP) Roman Kern (KTI, TU Graz) WWW Architecture I / 81

45 Layered system Web Architecture Figure: Layered system Roman Kern (KTI, TU Graz) WWW Architecture I / 81

46 Web Architecture Layered system Improves Internet-scale Application composed of layers that are only aware of the neighbouring 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 processing overhead Roman Kern (KTI, TU Graz) WWW Architecture I / 81

47 Code on demand Web Architecture Figure: Code on demand Roman Kern (KTI, TU Graz) WWW Architecture I / 81

48 Web Architecture Code on demand Client functionality can be extended by downloading code E.g. Java applets, Flash, JavaScript Improves extensibility Independent development Roman Kern (KTI, TU Graz) WWW Architecture I / 81

49 Web Systems Web Systems Web as a Platform Roman Kern (KTI, TU Graz) WWW Architecture I / 81

50 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

51 Types of Web Systems Web Systems Roman Kern (KTI, TU Graz) WWW Architecture I / 81

52 Web Systems The Web Two faces of the Web The Web as an application platform The Web as a huge distributed database Roman Kern (KTI, TU Graz) WWW Architecture I / 81

53 Web Applications Web Applications Develop Application for the Web Roman Kern (KTI, TU Graz) WWW Architecture I / 81

54 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

55 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 have direct 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

56 Web Applications Typical Stack of Web-Applications Roman Kern (KTI, TU Graz) WWW Architecture I / 81

57 Web Applications Application state on the Web: Hypertext 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

58 Web Applications Application state on the Web: Hypertext 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 have typically single URLs? How to recover previous state, i.e. browser back button problem? Roman Kern (KTI, TU Graz) WWW Architecture I / 81

59 Web Applications Application state on the Web: Hypertext 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

60 Web Applications Application state on the Web: Hypertext 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

61 Web Applications Example: Google Maps Permalink Roman Kern (KTI, TU Graz) WWW Architecture I / 81

62 Web Applications Application state on the Web: Hypertext A little bit of extra DOM/JavaScript work keeps the Permalink up to date as you navigate Every point on the map is a separate application state that has its own URL Application states were destroyed by AJAX but was put back by application design It allowed communities to grow around the Google Maps application Only because of proper management of application states with URLs Roman Kern (KTI, TU Graz) WWW Architecture I / 81

63 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

64 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

65 Web n-tier Architecture Web n-tier Architecture Layered Architecture for the Web Roman Kern (KTI, TU Graz) WWW Architecture I / 81

66 Web n-tier Architecture Architecture: User-oriented database applications In traditional software engineering UODA are built with an N-tier architecture They started as 2-layer applications Data management layer and application/presentation layer Roman Kern (KTI, TU Graz) WWW Architecture I / 81

67 Web n-tier Architecture 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 the presentation (e.g. generating of HTML) Everything runs on the server Roman Kern (KTI, TU Graz) WWW Architecture I / 81

68 Web n-tier Architecture Architecture: Problems of 2-layer applications Mixture of application and presentation related functionality Changes in application logic lead to changes in presentation functionality and vice versa E.g. changing a table that present some application data leads to changes 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

69 Web n-tier Architecture Architecture: 3-layer applications 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

70 Web n-tier Architecture Architecture: 3-layer applications Roman Kern (KTI, TU Graz) WWW Architecture I / 81

71 Web n-tier Architecture Architecture: 3-layer applications Roman Kern (KTI, TU Graz) WWW Architecture I / 81

72 Web n-tier Architecture Architecture: 3-layer applications 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

73 Web n-tier Architecture Architecture: 3-layer applications 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 + (presentation and application) JavaScript, data access on server Note: May require additional considerations in regard to security (if the application logic is done on the client) Roman Kern (KTI, TU Graz) WWW Architecture I / 81

74 Web n-tier Architecture Architecture: 3-layer applications Roman Kern (KTI, TU Graz) WWW Architecture I / 81

75 Web n-tier Architecture Architecture: 3-layer applications There are numerous architecture variants built on the top of N-tier architectures The most important for Web applications: Model-View-Controller architecture It was invented in the early days of GUIs To decouple the graphical interface from the application data and logic Very useful also for Web applications Roman Kern (KTI, TU Graz) WWW Architecture I / 81

76 Web Data Management Web Data Management Architecture Styles for Data Handling Roman Kern (KTI, TU Graz) WWW Architecture I / 81

77 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 or JPA Roman Kern (KTI, TU Graz) WWW Architecture I / 81

78 Web Data Management Architecture: 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 a representation Representation formats are e.g. HTML, PDF,... for humans, or e.g XML, JSON for programs Nodes can be interlinked using their unique addresses Roman Kern (KTI, TU Graz) WWW Architecture I / 81

79 Web Data Management Architecture: 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 Roman Kern (KTI, TU Graz) WWW Architecture I / 81

80 Web Data Management Architecture: 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 a structured manner Social Web 2.0 applications or Microformats Search inside metadata Roman Kern (KTI, TU Graz) WWW Architecture I / 81

81 Web Data Management The End Next: Web Architectures II Roman Kern (KTI, TU Graz) WWW Architecture I / 81

WWW Architecture. Software Architecture VO/KU ( / ) Denis Helic. KMI, TU Graz. Dec 7, 2011

WWW Architecture. Software Architecture VO/KU ( / ) Denis Helic. KMI, TU Graz. Dec 7, 2011 WWW Architecture Software Architecture VO/KU (707.023/707.024) Denis Helic KMI, TU Graz Dec 7, 2011 Denis Helic (KMI, TU Graz) WWW Architecture Dec 7, 2011 1 / 118 Outline 1 Introduction 2 Quality requirements