1. Tutorium #1
01.03. bzw. 08.03.
Bei dieser Ausarbeitung handelt es sich um keine offizielle Lösung
des Lehrstuhls. Dies sind nur Lösungsansätze, welche keinen
Anspruch auf Korrektheit oder Vollständigkeit erheben.

2. Agenda
• Verteilte Systeme (Aufgabe 1,2)
• Architekturmodell (Aufgabe 3)
• 3 - Tier Architecture (Aufgabe 4)
• Schichtenmodelle (Aufgabe 5)

3. 1.a Verteilte Systeme
• Frage:
• Ist ein Rechnernetz ein Verteiltes System?
Betrachten Sie die in der Vorlesung gegeben
Definitionen und überlegen Sie sich, wie man die
zwei Begriffe abgrenzen kann.

4. 1.a Verteilte Systeme
• Definition 3:
• “A distributed system consists of a
collection of autonomous computers linked
by a computer network and equipped with
distributed system software”

5. 1.a Verteilte Systeme

6. 1.a Verteilte Systeme
• Im Vordergrund:Vernetzung der Rechner

7. 1.a Verteilte Systeme
• Im Vordergrund:Vernetzung der Rechner
• Im Hintergrund: Kooperation

8. 1.a Verteilte Systeme
• Im Vordergrund:Vernetzung der Rechner
• Im Hintergrund: Kooperation
• Systeme nutzen Rechnernetze

9. 1.b Verteilte Systeme
• Frage:
• Ist ein Parallelrechner ein Verteiltes System?
Betrachten Sie die in der Vorlesung gegeben
Definitionen und überlegen Sie sich, wie
man die zwei Begriffe abgrenzen kann.

10. 1.b Verteilte Systeme
• Definition 2:
• “A distributed system is a collection of
independent computers that appear to the
users of the system as a single computer.”

11. 1.b Verteilte Systeme

12. 1.b Verteilte Systeme
• Gemeinsam: physischer Speicher, andere
Resourcen
• “Verteilt”: CPU
• aber keine autonomen Rechner => Kein
distributed System
• z.T. ähnliche Probleme wie Synchronisation

13. 2.Verteilte Systeme
• Frage:
• Wählen Sie ein beliebiges Verteiltes System
aus und erstellen sie eine Skizze dazu. Was
sind in dem von Ihnen gewählten System
die Knoten (Nodes) und Kanten (Edges)?
Diskutieren Sie das System bezüglich der in
der Vorlesung vorgestellten
Charakteristiken von Verteilten Systemen.

14. 2.Verteilte Systeme

15. 2.Verteilte Systeme
• Beispiel: Web

16. 2.Verteilte Systeme
• Beispiel: Web

17. 2.Verteilte Systeme
• Beispiel: Web
• Knoten:

18. 2.Verteilte Systeme
• Beispiel: Web
• Knoten:
• Clients/Server

19. 2.Verteilte Systeme
• Beispiel: Web
• Knoten:
• Clients/Server
• Kanten:

20. 2.Verteilte Systeme
• Beispiel: Web
• Knoten:
• Clients/Server
• Kanten:
• Protokoll: HTTP usw.

21. 2.Verteilte Systeme
• Beispiel: Web
• Knoten:
• Clients/Server
• Kanten:
• Protokoll: HTTP usw.
• Medium: WLan, Ethernet

22. 3. Architekturmodell
Fehlertoleranz Vertraulichkeit Skalierbarkeit
Single Point of Failure: Bei Server sind normalerweise
Aufwand erscheint hoch.
Defekt des Servers funktioniert entsprechend gesichert.
Besteht jedoch hier ein ausgereiftes
Client/Server komplettes System nicht mehr.
System, so können auch einfach
Aber: Einbruch auf einen Server
weitere Server angehängt werden
Server laufen ermöglicht meist Zugriff auf
(Loadbalancing, Contentswitch)
(normalerweise) stabil. praktisch alle Daten.
Ausfall eines Peers nicht
tragisch. Nicht gerade für vertrauliche
Auf den ersten Blick sehr einfach
Daten geeignet, da die Daten
P2P-Systeme bestehen aus skalierbar. Es werden einfach
praktisch jedem Teilnehmer „durch
„normalen“ PCs. weitere Peers an das System
die Hände“ laufen können.
P2P Diese laufen oft nicht so stabil und
durchgehend wie „managed
Aber: Normalerweise werden nicht
alle Daten auf einem Peer
angehängt.
Allerdings kann dies sehr schnell zu
Server“. einem Zusammenbruch führen.
gespeichert. Einbruch auf einen
Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen
Peer genügt also nicht um an alle
nur auf einem Peer gespeichert anderen Peers kommuniziert)
Daten zu kommen.
sein.

23. 3. Architekturmodell
Fehlertoleranz Vertraulichkeit Skalierbarkeit
Single Point of Failure: Bei Server sind normalerweise
Aufwand erscheint hoch.
Defekt des Servers funktioniert entsprechend gesichert.
Besteht jedoch hier ein ausgereiftes
Client/Server komplettes System nicht mehr.
System, so können auch einfach
Aber: Einbruch auf einen Server
weitere Server angehängt werden
Server laufen ermöglicht meist Zugriff auf
(Loadbalancing, Contentswitch)
(normalerweise) stabil. praktisch alle Daten.
Ausfall eines Peers nicht
tragisch. Nicht gerade für vertrauliche
Auf den ersten Blick sehr einfach
Daten geeignet, da die Daten
P2P-Systeme bestehen aus skalierbar. Es werden einfach
praktisch jedem Teilnehmer „durch
„normalen“ PCs. weitere Peers an das System
die Hände“ laufen können.
P2P Diese laufen oft nicht so stabil und
durchgehend wie „managed
Aber: Normalerweise werden nicht
alle Daten auf einem Peer
angehängt.
Allerdings kann dies sehr schnell zu
Server“. einem Zusammenbruch führen.
gespeichert. Einbruch auf einen
Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen
Peer genügt also nicht um an alle
nur auf einem Peer gespeichert anderen Peers kommuniziert)
Daten zu kommen.
sein.

24. 3. Architekturmodell
Fehlertoleranz Vertraulichkeit Skalierbarkeit
Single Point of Failure: Bei Server sind normalerweise
Aufwand erscheint hoch.
Defekt des Servers funktioniert entsprechend gesichert.
Besteht jedoch hier ein ausgereiftes
Client/Server komplettes System nicht mehr.
System, so können auch einfach
Aber: Einbruch auf einen Server
weitere Server angehängt werden
Server laufen ermöglicht meist Zugriff auf
(Loadbalancing, Contentswitch)
(normalerweise) stabil. praktisch alle Daten.
Ausfall eines Peers nicht
tragisch. Nicht gerade für vertrauliche
Auf den ersten Blick sehr einfach
Daten geeignet, da die Daten
P2P-Systeme bestehen aus skalierbar. Es werden einfach
praktisch jedem Teilnehmer „durch
„normalen“ PCs. weitere Peers an das System
die Hände“ laufen können.
P2P Diese laufen oft nicht so stabil und
durchgehend wie „managed
Aber: Normalerweise werden nicht
alle Daten auf einem Peer
angehängt.
Allerdings kann dies sehr schnell zu
Server“. einem Zusammenbruch führen.
gespeichert. Einbruch auf einen
Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen
Peer genügt also nicht um an alle
nur auf einem Peer gespeichert anderen Peers kommuniziert)
Daten zu kommen.
sein.

25. 3. Architekturmodell
Fehlertoleranz Vertraulichkeit Skalierbarkeit
Single Point of Failure: Bei Server sind normalerweise
Aufwand erscheint hoch.
Defekt des Servers funktioniert entsprechend gesichert.
Besteht jedoch hier ein ausgereiftes
Client/Server komplettes System nicht mehr.
System, so können auch einfach
Aber: Einbruch auf einen Server
weitere Server angehängt werden
Server laufen ermöglicht meist Zugriff auf
(Loadbalancing, Contentswitch)
(normalerweise) stabil. praktisch alle Daten.
Ausfall eines Peers nicht
tragisch. Nicht gerade für vertrauliche
Auf den ersten Blick sehr einfach
Daten geeignet, da die Daten
P2P-Systeme bestehen aus skalierbar. Es werden einfach
praktisch jedem Teilnehmer „durch
„normalen“ PCs. weitere Peers an das System
die Hände“ laufen können.
P2P Diese laufen oft nicht so stabil und
durchgehend wie „managed
Aber: Normalerweise werden nicht
alle Daten auf einem Peer
angehängt.
Allerdings kann dies sehr schnell zu
Server“. einem Zusammenbruch führen.
gespeichert. Einbruch auf einen
Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen
Peer genügt also nicht um an alle
nur auf einem Peer gespeichert anderen Peers kommuniziert)
Daten zu kommen.
sein.

26. 3. Architekturmodell
Fehlertoleranz Vertraulichkeit Skalierbarkeit
Single Point of Failure: Bei Server sind normalerweise
Aufwand erscheint hoch.
Defekt des Servers funktioniert entsprechend gesichert.
Besteht jedoch hier ein ausgereiftes
Client/Server komplettes System nicht mehr.
System, so können auch einfach
Aber: Einbruch auf einen Server
weitere Server angehängt werden
Server laufen ermöglicht meist Zugriff auf
(Loadbalancing, Contentswitch)
(normalerweise) stabil. praktisch alle Daten.
Ausfall eines Peers nicht
tragisch. Nicht gerade für vertrauliche
Auf den ersten Blick sehr einfach
Daten geeignet, da die Daten
P2P-Systeme bestehen aus skalierbar. Es werden einfach
praktisch jedem Teilnehmer „durch
„normalen“ PCs. weitere Peers an das System
die Hände“ laufen können.
P2P Diese laufen oft nicht so stabil und
durchgehend wie „managed
Aber: Normalerweise werden nicht
alle Daten auf einem Peer
angehängt.
Allerdings kann dies sehr schnell zu
Server“. einem Zusammenbruch führen.
gespeichert. Einbruch auf einen
Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen
Peer genügt also nicht um an alle
nur auf einem Peer gespeichert anderen Peers kommuniziert)
Daten zu kommen.
sein.

27. 3. Architekturmodell
Fehlertoleranz Vertraulichkeit Skalierbarkeit
Single Point of Failure: Bei Server sind normalerweise
Aufwand erscheint hoch.
Defekt des Servers funktioniert entsprechend gesichert.
Besteht jedoch hier ein ausgereiftes
Client/Server komplettes System nicht mehr.
System, so können auch einfach
Aber: Einbruch auf einen Server
weitere Server angehängt werden
Server laufen ermöglicht meist Zugriff auf
(Loadbalancing, Contentswitch)
(normalerweise) stabil. praktisch alle Daten.
Ausfall eines Peers nicht
tragisch. Nicht gerade für vertrauliche
Auf den ersten Blick sehr einfach
Daten geeignet, da die Daten
P2P-Systeme bestehen aus skalierbar. Es werden einfach
praktisch jedem Teilnehmer „durch
„normalen“ PCs. weitere Peers an das System
die Hände“ laufen können.
P2P Diese laufen oft nicht so stabil und
durchgehend wie „managed
Aber: Normalerweise werden nicht
alle Daten auf einem Peer
angehängt.
Allerdings kann dies sehr schnell zu
Server“. einem Zusammenbruch führen.
gespeichert. Einbruch auf einen
Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen
Peer genügt also nicht um an alle
nur auf einem Peer gespeichert anderen Peers kommuniziert)
Daten zu kommen.
sein.

28. 3. Architekturmodell
Fehlertoleranz Vertraulichkeit Skalierbarkeit
Single Point of Failure: Bei Server sind normalerweise
Aufwand erscheint hoch.
Defekt des Servers funktioniert entsprechend gesichert.
Besteht jedoch hier ein ausgereiftes
Client/Server komplettes System nicht mehr.
System, so können auch einfach
Aber: Einbruch auf einen Server
weitere Server angehängt werden
Server laufen ermöglicht meist Zugriff auf
(Loadbalancing, Contentswitch)
(normalerweise) stabil. praktisch alle Daten.
Ausfall eines Peers nicht
tragisch. Nicht gerade für vertrauliche
Auf den ersten Blick sehr einfach
Daten geeignet, da die Daten
P2P-Systeme bestehen aus skalierbar. Es werden einfach
praktisch jedem Teilnehmer „durch
„normalen“ PCs. weitere Peers an das System
die Hände“ laufen können.
P2P Diese laufen oft nicht so stabil und
durchgehend wie „managed
Aber: Normalerweise werden nicht
alle Daten auf einem Peer
angehängt.
Allerdings kann dies sehr schnell zu
Server“. einem Zusammenbruch führen.
gespeichert. Einbruch auf einen
Wichtige Daten sollten also nicht (z.B. wenn jeder Peer mit allen
Peer genügt also nicht um an alle
nur auf einem Peer gespeichert anderen Peers kommuniziert)
Daten zu kommen.
sein.

29. 4. 3-Tier Architecture
• Frage:
• Sie möchten ein Online-Portal für sich und ihre Freunde entwickeln. Das
Portal soll als ein Adressbuch dienen, auf welches alle angemeldeten Nutzer
über das Web zugreifen können und jederzeit Informationen über ihre
Freunde abrufen können. Ferner kann jeder Nutzer seine Daten ändern und
zum Beispiel neue Fotos einstellen. Damit ihre Freunde das Portal nutzen
können, haben Sie bereits vorab Nutzer angelegt und entsprechende
Zugangspasswörter an ihre Freunde verteilt.
• Ordnen Sie die verschiedenen Elemente ihrer webbasierten Adressbuch-
Anwendung den drei Stufen (Tiers) der 3-Tier Architektur zu.

30. 4. 3-Tier Architecture

31. 4. 3-Tier Architecture
• Presentation:

32. 4. 3-Tier Architecture
• Presentation:
• GUI im Webbrowser

33. 4. 3-Tier Architecture
• Presentation:
• GUI im Webbrowser
• Eingabemasken

34. 4. 3-Tier Architecture
• Presentation:
• GUI im Webbrowser
• Eingabemasken
• Anzeige von Daten

35. 4. 3-Tier Architecture
• Presentation:
• GUI im Webbrowser
• Eingabemasken
• Anzeige von Daten
• Processing:

36. 4. 3-Tier Architecture
• Presentation:
• GUI im Webbrowser
• Eingabemasken
• Anzeige von Daten
• Processing:
• Prüfen von Daten auf Fehler,
Konsistenz, etc

37. 4. 3-Tier Architecture
• Presentation:
• GUI im Webbrowser
• Eingabemasken
• Anzeige von Daten
• Processing:
• Prüfen von Daten auf Fehler,
Konsistenz, etc
• Generation von Queries für
die Datenbank

38. 4. 3-Tier Architecture
• Presentation: • Database:
• GUI im Webbrowser
• Eingabemasken
• Anzeige von Daten
• Processing:
• Prüfen von Daten auf Fehler,
Konsistenz, etc
• Generation von Queries für
die Datenbank

39. 4. 3-Tier Architecture
• Presentation: • Database:
• GUI im Webbrowser • Speichern der Adress und
Login-Daten in Database
• Eingabemasken
• Anzeige von Daten
• Processing:
• Prüfen von Daten auf Fehler,
Konsistenz, etc
• Generation von Queries für
die Datenbank

40. 5. Schichtenmodelle
• Entwickeln Sie ein Schichtmodell für die
Kommunikation zwischen zwei Marineoffizieren
der Navy im zweiten Weltkrieg. (Beachten Sie, die
Offiziere können weder Navajo sprechen noch
verstehen.)
• Ordnen Sie die verschiedenen Schichten ihres
Modells in das ISO-OSI Modell ein, das Sie in der
Vorlesung kennengelernt haben.

41. 5. Schichtenmodelle
O1

42. 5. Schichtenmodelle
O1
N1

43. 5. Schichtenmodelle
O1
N1
F1

44. 5. Schichtenmodelle
O1
N1
F1
Funkgerät

45. 5. Schichtenmodelle
O1
N1
F1
Funkgerät

46. 5. Schichtenmodelle
O1 O2
N1 N2
F1 F2
Funkgerät Funkgerät

47. 5. Schichtenmodelle
O1
N1
F1
Funkgerät

48. 5. Schichtenmodelle
O1
N1
F1
Funkgerät
1. Physical

49. 5. Schichtenmodelle
O1
N1
F1
2. Data
Funkgerät
1. Physical

50. 5. Schichtenmodelle
O1
N1
F1
3. Network
2. Data
Funkgerät
1. Physical

51. 5. Schichtenmodelle
O1
N1
4. Transport
F1
3. Network
2. Data
Funkgerät
1. Physical

52. 5. Schichtenmodelle
O1
N1 5. Session
4. Transport
F1
3. Network
2. Data
Funkgerät
1. Physical

53. 5. Schichtenmodelle
O1
6. Presentation
N1 5. Session
4. Transport
F1
3. Network
2. Data
Funkgerät
1. Physical

54. 5. Schichtenmodelle
7. Application
O1
6. Presentation
N1 5. Session
4. Transport
F1
3. Network
2. Data
Funkgerät
1. Physical