Rechnernetz-Technologie
OSI 7-Schichtenmodell
Verteilte Anwendungen,
allgemeines Client-Server-Modell
Softwareschnittstellen: Sockets, benannte Pipes und RPC Web:
HTTP-Protokoll in der Rechnernetz-Anwendungsschicht Architektur von Web-Applikationen:
Clientseitige Verarbeitung
Serverseitige Verarbeitung
Multi-Tier-Architekturen von Web-Applikationen
1. Internet-Grundlagen und Überblickswissen
OSI-Referenzmodell:
Open Systems Interconnection Reference Model Eingeführt 1983 von der ISO (Internationale
Normungsorganisation)
Zu dieser Zeit existierte TCP/IP bereits, das bis dahin durch ein 4-Schichtenmodell erklärt wurde.
Ein Schichtenmodell ordnet verschiedenen Netzwerk-
Techniken jeweils eine Schicht zu. Die oberen Schichten bauen auf der Funktionalität und den Schnittstellen der
OSI –Modell (1)
OSI –Modell (2)
1: Bitübertragungsschicht – umfasst mechanische und elektrische Elemente, das Übertragungsmedium und die übertragungstechnischen Verfahren
2: Sicherungsschicht - Techniken zum Zugriff auf das Übertragungsmedium, Datenflusskontrolle,
Fehlererkennung und Fehlerkorrektur
3: Vermittlungsschicht – Weiterleitung der
Datenübertragung über ein Kommunikationsnetz aus mehreren Leitungssegmenten und Schaltstellen (Router) 4: Transportschicht – Ende-zu-Ende-Steuerung für
OSI –Modell (3)
5: Sitzungsschicht – synchronisierter Datenaustausch, weitere Mechanismen wie z.B. RPC (Remote Procedure Call)
6: Darstellungsschicht – Herstellung einer
systemunabhängigen Darstellung der Daten,
ggf. Anpassung an verschiedene Darstellungsformate, Zusätzlich: Datenkompression und Verschlüsselung
7: Anwendungsschicht – verschiedene Anwendungen, wie z.B.
Dateitransfer (SCP,FTP), Email, Webserver/Webbrowser
OSI –Modell (4)
Angelehnt an TCP/IP mit Internetschicht und Transportschicht
Einfacheres 4-Schichten-Modell (1)
Rechner 1 4 Anwendungs-
schicht
http, ftp, smtp, pop, ....
3 Transport- schicht
TCP
2 Internet- schicht
IP 1 Netzzugangs-
schicht
Rechner 2 4 Anwendungs-
schicht
http, ftp, smtp, pop, ....
3 Transport- schicht
TCP 2 Internet-
schicht
IP 1 Netzzugangs-
schicht
realer Datenaustausch mit elektr.
logischer Datenaustausch
Die beiden entscheidenden Schnittstellen, die Internetschicht und die Transportschicht gut zu erkennen. Darüber liegt dann die Anwendungsschicht, die die bekannten Internetdienste
enthält.
Der Name Internettechnologien kommt natürlich von der Internetschicht. Man rechnet alles, was direkt auf diese Internetschicht aufsetzt oder darüber liegt zu den
Internettechnologien. In der Literatur ist oft der Begriff Web- Technologie zu finden.
Einfacheres 4-Schichten-Modell (2)
Wir betrachten zwei Rechner, die über das Netz verbunden sind.
Auf jedem Rechner läuft eine Anwendung, die beide miteinander kooperieren, d.h. Daten austauschen.
Eine Anwendung wird als Server bezeichnet, die andere als
Client. Der Server stellt einen Dienst bereit und der Client ist die Anwendung, die den Dienst in Anspruch nimmt.
Gefordert:
Ein Protokoll, das bestimmt wie der Datenaustausch zwischen Server und Client funktioniert.
Zeitliche Abfolge der Nachrichten und Regeln für Client und Server
Client-Server-Modell –
Grundlage für die Internettechnologien
Werden im Internet Dienste von allgemeinem Interesse zur Verfügung gestellt, müssen die Protokolle publiziert werden.
Oft werden dann auch Clients zur Verfügung gestellt, über die solche Dienste genutzt werden können.
Zugangspunkte für Dienste (Adressen) müssen bekannt sein:
Adresse des Servers (IP-Adresse)
Unterscheidung der Zugangspunkte, wenn ein Server mehr als einen Dienst bereit stellt (Port)
Die Adressierung ist Aufgabe der
Vermittlungsschicht (Schicht 3, Network Layer) im OSI-Modell
IP-Schicht (Internet Schicht) im TCP/IP-Schichtenmodell
Client-Server-Modell –
Grundlage für die Internettechnologien
Ein Dienst wird mit einer so genannten Portnummer versehen.
Portnummer und Rechner (IP-Nummer) bilden ein Socket und sind im Internet eindeutig definiert. Damit gelingt es beim
Datenversand im Internet durch TCP das Ziel der Daten, den Server, eindeutig zu adressieren.
Client-Server-Modell – Adressierung der Server
Server: www.htw-dresden.de IP-V4-Adr.: 141.56.16.49
WWW-Server an Port 80
FTP-Server an Ports 20,21
Ein Client wird durch seine IP-Adresse ausgewiesen.
Jede Verbindung wird clientseitig einem anderem Port zugeordnet.
Damit kann der Client mehrere Verbindungen gleichzeitig aufrecht erhalten.
Ports für Client-Prozesse werden durch Portmapper dynamisch vergeben. Der Client-Port wird dem Server beim Verbindungs- aufbau mitgeteilt.
Eine TCP-Verbindung (Socket-Verbindung) ist demnach durch das 4-Tupel
(Server-IP-Addr, Server_Port, Client-IP-Addr, Client-Port) gekennzeichnet.
Client-Server-Modell –
Adressierung der Clients
Ein Server, mehrere Clients:
Client-Server-Modell – Szenarien (1)
Server-IP-Adr, Server-Port C1-IP-Adr,
C1-Port
C2-IP-Adr, C2-Port
C3-IP-Adr, C3-Port
Clients Server
Wenn Clients auf unterschiedlichen Rechnern laufen, dann unterscheiden sich C1-IP-Adr, C2-IP-Adr und C3-IP-Adr.
Wenn Clients auf dem gleichen Rechner laufen (z.B. mehrere
Ein Client, mehrere Server:
Client-Server-Modell – Szenarien (2)
S1-IP-Adr, S1-Port Client-IP-Adr,
Client-Port
Client Server
Wenn Server auf unterschiedlichen Rechnern laufen, dann unterscheiden sich S1-IP-Adr und S2-IP-Adr.
Wenn verschiedene Server auf dem gleichen Rechner laufen, dann unterscheiden sich ihre Port-Nummern, z.B. S2-Port ≠ S1-Port.
→ Nachrichten unterschiedlicher Verbindungen sind immer unterscheidbar.
S2-IP-Adr, S2-Port
TCP (Transmission Control Protocol) –
Verbindungsorientiertes Protokoll aus OSI Schicht 4
setzt Adressierung und Paket-Vermittlung voraus (IP)
arbeitet intern wie dargestellte Socket- und Pipe- Kommunikation
TCP garantiert Reihenfolge der Daten und Fehlerfreiheit – bei verlorenen Paketen werden diese wiederholt übertragen
Auf TCP bauen viele Internetdienste auf, z.B. HTTP, FTP
TCP und UDP (1)
UDP (User Datagram Protocol) ist das verbindungslose Pendant zu TCP. Das verbindungslose UDP kann schneller sein.
setzt Adressierung und Paket-Vermittlung voraus (IP)
einzelne Pakete werden übertragen, ohne explizite Verbindung
keine Reihenfolgegarantie
Pakete können verloren gehen
einige Dienste, wie z.B. Audio-Streaming verwenden UDP
TCP und UDP (2)
Eine Socket-Verbindung ist eine verbindungsorientierte
Kopplung zwischen zwei Prozessen, typischerweise einem Server und einem Client.
Die Verbindung wird explizit aufgebaut, danach kann bidirektional kommuniziert werden. Die Verbindung wird geschlossen, wenn sie nicht mehr benötigt wird.
Vergleichbar mit Telefongespräch!
Client-Server-Kommunikation – per Socket-Verbindung (1)
Prozess-1 Prozess-2
Phasen einer Socket-Verbindung als Sequenz-Diagramm
Client-Server-Kommunikation – per Socket-Verbindung (2)
Server Client
bind (es, address) … Angabe des Ports listen(es)
s = accept(es)
connect(s, address)
… IP-Adresse und Port
write(s, …)
write(s, …) read(s, …) read(s, …)
write(s, …)
read(s, …) close(s)
close(s)
es = socket () s = socket ()
• Der Server bindet eine Dienst an einen bekannten Port (bind) und akzeptiert Verbindungen (accept).
• Ein Client verbindet sich mit einem Dienst an einem bekannten Port (connect).
• Beide Prozesse können Daten senden und empfangen.
Funktionen: write() / read() oder send() / recv()
• Welcher Prozess wann sendet und wann empfängt, muss durch das Protokoll zwischen Server und Client geklärt sein.
• Ein Server erzeugt typischerweise nach dem Annehmen einer Verbindung (accept) einen neuen Thread für die Verbindung.
Der verbleibende Thread nimmt wieder neue Verbindungen an (Multi-Client-Server).
Client-Server-Kommunikation –
per Socket-Verbindung (3)
Server source code (C language, important parts only):
int entry_sock;
entry_sock = socket(AF_INET,SOCK_STREAM,0);
/*connect sock_address with local address and a unique port */
sock_address.sin_port = htons( (unsigned short int)(port_base + process_id*proc_inc));
sock_address.sin_addr.s_addr = INADDR_ANY;
// everyone may connect sock_address.sin_family = AF_INET;
rc = bind(entry_sock, (void*)&sock_address, sizeof(sock_address));
C-Quellcode des Socket-Server-Programms (1)
Server source code (C language, important parts only) continued:
listen(entry_sock, BACKLOG);
do {
// wait for a new connection
addrlen = sizeof(client_sock_address);
new_sock = accept(entry_sock, (void*)&client_sock_address, &addrlen );
/* connection_fun starten */
params_not_copied=1;
pthread_create(&connection_thread,NULL,(void*)&connection_fun,NULL);
/* wait for thread until parameters got copied*/
do { } while(params_not_copied);
C-Quellcode des Socket-Server-Programms (2)
Server source code (C language, important parts only) continued:
void connection_fun(void *param){
selected = new_sock;
params_not_copied=0;
…
// communicate with client according a user-specified protocol read(selected,&pmessage, MSG_LEN);
write(selected,&pmessage, MSG_LEN);
close(selected);
}
C-Quellcode des Socket-Server-Programms (3)
Erklärung:
pmessage ist hier die Datenstruktur, die zum
Nachrichtenaustausch dient.
Sie ist MSG_LEN Bytes lang.
Client source code (C language, important parts only):
sock = socket(AF_INET,SOCK_STREAM,0);
serv_addr.sin_addr.s_addr = inet_addr(server_ipaddress);
serv_addr.sin_port = htons(server[i].port);
serv_addr.sin_family = AF_INET;
rc = connect(sock, (struct sockaddr *) &serv_addr, sizeof(serv_addr));
printf("client connected to %s:%d rc=%d \n", server_ipaddress, server[i].port, rc);
write(sock, &pmessage, MSG_LEN);
read(sock, &pmessage, MSG_LEN);
C-Quellcode des Socket-Client-Programms
Die „benannte Pipe“ (NamedPipe) ist ein alternativer Mechanismus, zwei Prozesse über das Netzwerk zu verbinden.
Eine „benannte Pipe“ kann wie eine Datei angesehen werden,
die auf der Seite des Server-Rechners eingerichtet ist und einen Kanal zwischen zwei verteilten, kooperierenden Prozessen darstellt. Einer schiebt Daten in den Kanal hinein (Schreiben) und der andere holt sich diese Daten auf der anderen Seite aus dem Kanal heraus (Lesen).
Auf der Clientseite wird über eine URL \\hostname\pipe\pipename der Eingang des Kanals als Datei-Equivalent bereitgestellt.
„Benannte Pipe“ als Kommunikationskanal (1)
Der Datenaustausch läuft danach wie eine normale Dateioperation auf einem lokalen Rechner ab. Auf der Serverseite wird nur der pipename als Handle zum lokalen Eingang des Kanals bereitgestellt. Damit wird der Kommunikationskanal als eine Art virtuelle Datei angesehen und der Datenaustausch über normale Dateioperationen realisiert.
Pipe als Kommunikationskanal (2)
Aktion Aktion
erzeugt Pipe
Wa rtet auf Pipe verfü gbar
Schließt Datei an Pipe an Wa rtet auf
ankomm end e
Verbi ndung
em pfängt Daten
Sendet D aten
se ndet Daten
em pfängt Daten
CreateNamedPipe() WaitNamedPipe()
ConnectNamedP ipe() CreateFile()
ReadFile() WriteFile()
WriteFile()
DisconnectNamedP ipe() Löst die
Verbi ndung
ReadFile()
CloseHandl e() Schließt
Handle
Schließt Handle CloseHandle()
Server Client
Pipe-Funktionen des Servers
Erzeugen von Pipes - CreateNamedPipe()
Der Server muss auf seinem Rechner die Pipe erzeugen und dabei die Funktionalität angeben. Bei der Erzeugung gibt er statt seinem eigenen Computernamen einen Punkt an und legt den Pipenamen fest,
z. B.: \\.\pipe\p1
Beim Server dient der Punkt (.) als Rechnername. Beim Client muss dann anstatt des Punkts der Rechnername angegeben werden.
Beispiel als C-Quelltext:
hPipe=CreateNamedPipe("\\\\.\\pipe\\p1", PIPE_ACCESS_INBOUND, PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, 256,256,1000,NULL);
Pufferlängen für Ein- und Ausgabe sind 256 Bytes, als Time-out Zeit gilt 1000 ms und es sind keine Sicherheitsattribute gesetzt.
Pipe als Kommunikationskanal (3)
Warten auf Client-Verbindungen - ConnectNamedPipe()
Mit der ConnectNamedPipe()-Funktion leitet der Server einen Warteprozess auf eine Clientanforderung ein. Der erste Parameter ist das Pipe-Handle, der zweite Parameter ist NULL oder enthält einen Pointer auf eine overlapped- Struktur.
Beispiel: ConnectNamedPipe(hPipe,NULL);
Aufheben der Client-Verbindungen - DisConnectNamedPipe() Mit der DisConnectNamedPipe()-Funktion beendet der Server eine
Verbindung zu einem Client. Der einzige Parameter ist das Pipe-Handle. Der Rückkehrwert ist bei Erfolg verschieden von 0.
Beispiel: DisConnectNamedPipe(hPipe);
Schließen des Pipe-Handles - CloseHandle()
Mit der CloseHandle ()-Funktion schließt der Server das Handle zu einer Pipe.
Pipe als Kommunikationskanal (4)
Pipe-Funktionen des Client
Warten auf die Verfügbarkeit der Pipe - WaitNamedPipe()
Mit der WaitNamedPipe()-Funktion wartet der Client auf die Pipe, die der Server erzeugen muss. Der erste Parameter enthält sowohl host- als auch pipe-Namen in der Form \\hostname\pipe\pipename. Der zweite Parameter enthält eine time-out-Angabe.
Anschluß an eine Pipe - CreateFile()
Mit der CreateFile()-Funktion realisiert der Client das Öffnen der Pipe als eine Datei. Der erste Parameter enthält das pipe-Handle in der Form
\\hostname\pipe\pipename.
Beispiel:
hPipe=Create(“\\\\iserver.informatik.htw-dresden.de\\pipe\\p1“,
GENERIC_WRITE, 0, NULL,OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL );
Pipe als Kommunikationskanal (5)
Datenaustausch mit der Pipe
Der Client bedient sich hier normaler Datei-Operationen der Windows- oder Unix-Plattform. Im Wesentlichen kommen dabei die ReadFile()- und WriteFile()-Funktionen zum Einsatz.
Beispiele:
WriteFile( hPipe, text, strlen(text)+1, &nBytesWritten, NULL );
ReadFile( pipe, buffer, 127, &numBytesRead, NULL );
Bemerkung: text ist hier die Adresse eines Speicherbereichs, der die zu übertragende Nachricht enthält!
In einigen Fällen ist es zweckmäßig, nach der Schreiboperationen die
Pipe als Kommunikationskanal (6)
Beenden der Verbindung mit der Pipe – CloseHandle()
Der Client beendet die Verbindung mit der Pipe durch Aufruf der CloseHandle()-Funktion.
Pipe als Kommunikationskanal (7)
A new paradigm hides message transfer: Birrell and Nelson, 1984
Remote procedure call (RPC):
• A program calls a subroutine or procedure in another address space
• RPC is initiated by a client: procedure call and wait for return
• request message to server (hidden)
• server calls procedure locally and transfers the parameters
• response message (hidden)
• client continues operation
• Sun RPC (UNIX), later Microsoft RPC,
Remote Procedure Call (1)
RPC:
Remote Procedure Call (2)
Client
rc=calculate(p1,p2,p3, &solution);
Server
wait … calculate
client- und server-Stub
server stub: receives messages, extracts parameters and calls corresponding procedures on the server side, results are sent back to the client
Remote Procedure Call (3/3)
client-stub: provides proximity procedures that collect
parameters and compose messages to server, receive
responses and copy back results
Verschiedene RPC-Infrastukturen:
Stub
int calc(int x, int y) OS and network stack
r = calc(a,b);
res = calc(par1,par2);
OS and network stack Stub: receive and call local procedure
Web – basierend auf dem Internet
Das Internet war bereits eher als das Web vorhanden, mit verteilten Anwendungen, Dateitransfer, Netzwerk-
Dateisystemen (NFS)
Web: entstanden durch Vorhandensein des HTTP-Protokolls, der HTML-Sprache, URLs und DNS (Domain Name Service)
Nutzung des Webs: ein klassisches Client/Server-Szenario
Mit dem Web erfolgte eine Kultur- und Wirtschaftsrevolution, da sich dadurch die Verhaltensweisen der Menschen, die
Organisation wirtschaftlicher Prozesse und auch politische Aspekte geändert haben.
Web 2.0: kollaboratives Web, inhaltlich kein serverzentriertes Web mehr
WWW - (World Wide) Web
Hypertext Transport Protocol, größtenteils zum Austausch von Hypertext (HTML, xHTML) benutzt
Herkunft:
• Das Protokoll wurde ab 1989 von Roy Fielding, Tim Berners- Lee und anderen am CERN entwickelt
• Zusammenspiel mit den Konzepten URL und HTML.
URL: Unified Ressource Locator
HTML: Sprache zum Aufschreiben von Hypertext-Dokumenten
→ Geburt des WWW, (bzw. Web)
• Zur Kommunikation ist HTTP auf ein zuverlässiges
Transportprotokoll angewiesen. Dafür wird in nahezu allen
HTTP Protokoll (1)
Über HTTPS kann die Übertragung aber verschlüsselt erfolgen.
HTTPS nutzt SSL aus Transportschicht (Secure Socket Layer) und TLS. Ein HTTPS-Dienst wird typischerweise auf Port 443 angeboten.
HTTP-Eigenschaften:
HTTP ist zustandslos
Anfrage, Antwort, Ende: keine komplexen Kommunikationsszenarien
Der Zustand eines Clients (Browsers) kann nur über s.g. Cookies verwaltet werden
Typischer Protokollablauf:
• Anfrage an Server: Zum Beispiel GET-Request mit Angabe des Dokumentennamen und des Servers
• Antwort: OK, Infos über Server und HTML-Dokument
HTTP Protokoll (2)
Typischer Protokollablauf:
• Anfrage an Server:
GET /~sobe/Ueb_Internet/anfang.html HTTP/1.1 Host: www2.htw-dresden.de
• Antwort:
HTTP/1.1 200 OK
Date: Sun, 20 Mar 2011 11:59:21 GMT
Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with
Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0 Vary: Accept-Encoding
Content-Length: 1538 Connection: close
Content-Type: text/html; charset=iso-8859-1
< !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN„
HTTP Protokoll (3)
HTTP-Operationen im Überblick:
GET – Anfordern einer Ressource mit Angabe einer URL POST – Senden von Daten zum Server (z.B. für Formulare) HEAD –Anfordern eines Headers zu einer Ressource
PUT – Hochladen einer Ressource,
bei Webservern oft nicht implementiert DELETE – Löschen einer Ressource,
bei Webservern oft nicht implementiert
TRACE – Empfangen und Zurücksenden der Anforderung OPTIONS – Server liefert eine Liste der unterstützten
Operationen zurück CONNECT – nur für Proxy-Server
Das Hochladen von Web-Inhalten und Löschen erfolgt meistens durch andere Protokolle (z.B. SFTP Secure File Transfer Prot.) oder SSH (Secure Shell)
HTTP-Protokoll (4)
Weiteres in Kapitel 2
Detailinformationen zum HTTP-Protokoll in RFCs (Request for Comments die De Facto-Standards darstellen)
RFC 1945 (HTTP/1.0) http://tools.ietf.org/html/rfc1945 RFC 2616 (HTTP/1.1) http://tools.ietf.org/html/rfc2616
HTTP-Protokoll (5)
HTML – Hypertext Markup Language Auszeichungssprache für Web-Seiten
xHTML - eXtensible Hypertext Markup Language
XML-konformes HTML, weitestgehend gleiche Elemente wie HTML, nun aber streng wohlgeformt
HTML und xHTML wurden inzwischen ersetzt durch HTML5
HTML und xHTML
In HTML lassen sich JavaScript-Programme einbetten, die auf der
Clientseite durch einen Interpreter ausgeführt werden. Damit lassen sich gewisse „dynamische Effekte“ bei der Anzeige eines HTML-Dokumentes erreichen. Das nennt man clientseitiges Scripting.
Es bleibt es bei einer Client-Server-Anwendung, d.h. einer 2-Schichten-Anwendung (2-Tier).
Effekte:
Anzeigen neuer Bilder
zeitgebergesteuerte Animationen
Reaktion auf Mausereignisse,
Änderung von Eigenschaften von Objekten (Farbe, Stil,…),
Architektur von Web-Anwendungen (1)
Client-seitiges Scripting (Fortsetzung):
Ein JavaScript kann auf Eigenschaften von Objekten der grafischen Oberfläche zugreifen und über Methoden Manipulationen
durchführen. Das wird durch ein Document Object Model (DOM) ermöglicht.
Architektur-Klassen:
2-Tier: Web-Anwendung ohne Scripting,
auch Webanwendungen mit clientseitigem Scripting 3-Tier: Webanwendungen mit serverseitigem Scripting
4-Tier: Webanwendungen mit serverseitigem Scripting und einer weiteren funktionalen Ebene (meistens eine Datenbank)
Architektur von Web-Anwendungen (2)
Im Webbrowser, JavaScript
• auf Client-Seite ausgeführt
• Script-Code wird innerhalb der HTML-Seite übertragen
• Script-Code ist typischerweise im Head eingebettet
• Das Script kann die Webseite dynamisch verändern, oder Nachrichtenboxen oder Dialoge initiieren
• Nachladen von Inhalten vorerst nicht möglich, ohne eine neue Webseite zu laden
Andere Programme können auch als HTTP-Client fungieren, um zum Beispiel Daten aus dem Web zu laden und zu verarbeiten.
Clientseitige Verarbeitung (1)
JavaScript – Beispiel:
…
<html>
<head>
<title>Die Seite mit dem Datum</title>
<script language=“JavaScript“>
function date() { var j,m,t;
var aktuellesdatum = new Date();
t = aktuellesdatum.getDate();
m = aktuellesdatum.getMonth()+1;
j = aktuellesdatum.getYear()+1900;
document.Formular.Datum.value=t+"."+m+"."+j;
}
</script>
</head>
Clientseitiges Verarbeitung (2)
<body … onload=“date()“>
<form name=“Formular“>
<input size=10 name=“Datum“/>
</form>
</html>
Andere Programme (Vielzahl von Programmiersprachen) können auch als HTTP-Client fungieren, um zum Beispiel Daten aus dem Web zu laden und zu verarbeiten.
Beispiel CURL-Bibliothek, Sprache C:
if( handle = url_fopen("http://deinedaten.org/daten.xml", "r") ) {
while(!url_feof(handle)) {
url_fgets(buffer, sizeof(buffer), handle);
// Weiterverarbeitung des Inhalts von buffer }
url_fclose(handle);
Clientseitige Verarbeitung (3)
Die Aufbereitung von Web-Inhalten erfolgt oft durch Programmverarbeitung auf dem Server.
Typische serverseitige Skript-Technologien:
CGI + „irgendetwas, das auf dem Server ausgeführt werden
kann und Hypertext zurückliefert“ , typisch ist CGI in Verbindung mit einem Perl-Skript
PHP – eine Sprache, die in HTML eingebettet ist und direkt im Webserver interpretiert wird
Anwendungen, die innerhalb Servlet-Containern ausgeführt
werden, die eine Verbindung zu Web-Servern herstellen (Java + Servlet Container, ASP.Net arbeitet ähnlich)
Anwendungen, die selbst einen Web-Server als Software- Komponente ausführen
Serverseitige Verarbeitung (1)
PHP - Hypertext Processor
auf Server-Seite ausgeführt
Die Ausgabe des Scrips erzeugt Seiteninhalt
nur die Ausgabe des Scripts wird per HTTP übertragen
PHP-Syntax ist an C und Perl angelehnt Beispiel:
<html>
…
<script language=“php“>
$i=1;
while($i<11) { echo “<br> \n“; $i=$i+1 }
</script>
Serverseitige Verarbeitung (2)
Active Server Pages (Microsoft ASP.NET)
Konzept: Mischung von Webseitencode in HTML mit Programmcode (Visual Basic oder C#)
Varianten:
eingebetteter Code (Inline, durch <% … %> eingefaßt)
Code-behind Modell: gesonderte Quelltextmodule mit Klassen, die Methoden für Web-Elemente bereitstellen
Durch ASP-Framework werden auch Elemente zur clientseitigen Interaktion mittels JavaScript bereitgestellt
Code wird übersetzt und innerhalb des IIS (Microsoft Webserver) ausgeführt.
Entwicklung: Microsoft Visual Studio
Test: Visual Web Developer (lokaler Webserver)
Serverseitiges Vearbeitung (3)
Beispiel für eine ASP.NET- Webseite:
<%@ Page Title="Beispiel" Language="vb" MasterPageFile="~/Site.Master"
AutoEventWireup="false“ CodeBehind="Default.aspx.vb„
Inherits="WebAppASPNET._Default" %>
<asp:Content ID="HeaderContent" runat="server„
ContentPlaceHolderID="HeadContent">
</asp:Content>
<asp:Content ID="BodyContent" runat="server"
ContentPlaceHolderID="MainContent">
<h2> Eine ASP.NET-Beispielanwendung </h2>
<% For i = 1 To 3 %>
<p> Hallo </p>
<% Response.Write(i) Next
%>
Serverseitige Verarbeitung (4)
HTML-, Head- und Body-Tags werden serverseitig
automatisch erzeugt. Inhalte können durch Code-behind Module programmiert werden.
gewöhnliche HTML- Elemente eingebetteter Code
(hier Visual Basic)
Serverseitige Verarbeitung (5)
Mehrere Welten:
PHP-basierte
Webanwendungen oft gekoppelt mit MySQL-Datenbank
ASP.NET-basierte Webanwendungen
Gekoppelt mit Microsoft- Plattform, z.B.
MS SQL-Server
Wir werden in der Vorlesung und im Praktikum vorrangig PHP benutzen.
Java Servlet, oder JSP im Tomcat Servlet
Container, oder JBoss Application Server
Multi-Tier-Anwendungen
Multi-tier Anwendungen
Netzwerke erlauben, Verbindungen zwischen Anwendungsprozessen auf verschiedenen Rechner herzustellen, z.B. durch Socket-
Verbindungen oder benannte Pipes
Client/Server – verbreitetes Paradigma für verteilte Systeme
Web: Webserver und Client(Browser)
Protokolle: Standards/Festschreibungen wie und mit welchen Nachrichtenformaten kommuniziert wird.
Web: HTTP-Protokoll,
transportiert wird: HTML, XML, eingebettete Inhalte, Dateien
Client und Serverseite sind programmierbar …
clientseitig und/oder serverseitig durch verschiedene Sprachen
Je nach Trennung in verschiedene Schichten (tiers):
2-tier, 3-tier, 4-tier -Web-Anwendungen (Multitier …)
