2 Folien/Seite

Transcrição

2 Folien/Seite
4. Architekturen und
Systemmodelle
• Überblick
4.1
4.2
4.3
4.4
4.5
Grundlegende Architektur- und Systemmodelle
Client/Server-Modell
Erweiterte Client/Server-Systeme
Gleichrangige Prozesse (Peer Processes)
Ereignisse und Benachrichtigungen
O. Kao
Webbasierte Informationssysteme
4-1
4.1 Grundlegende Architekturund Systemmodelle
• Architekturmodell eines webbasierten Systems
Aus welchen Bestandteilen besteht das System?
Wie sehen die Beziehungen zwischen den Bestandteilen aus?
Variationen entstehend beispielsweise durch Replikation, Caching,
Verwendung mobiler Codes, Ad-hoc-Kommunikation, …
• Grundlegende Systemmodelle liefern eine formale Beschreibung
der Eigenschaften, die allen Architekturmodellen gemeinsam sind
Interaktionsmodell
Fehlermodell
Sicherheitsmodell
• Jedes Modell (Interaktionsmodell, Fehlermodell,
Sicherheitsmodell) liefert eine abstrakte, vereinfachte und
konsistente Beschreibung des Systems
O. Kao
Webbasierte Informationssysteme
4-2
Übersicht über
Architekturmodelle
• Aufteilung der Verantwortlichkeiten zwischen Systemkomponenten (Anwendungen, Server, andere Prozesse) ist ein
offensichtlicher Aspekt beim Entwurf webbasierter Systeme
• Klassifikation bzgl. Platzierung von Prozessen
Client/Server-Modell: asymmetrisch, einfach, am häufigsten eingesetzt
Dienste, die von mehreren Servern bereitgestellt werden
Partitionierung oder Replikation eines Dienstes auf mehreren
Servern
Erweiterte Elemente eines Client/Server-Systems, z.B. Proxy-Server
und Caches
Peer-Prozesse (Gleichrangige Prozesse)
Symmetrisches Modell, da keine Unterscheidung zwischen Client
und Server
Alle Prozesse haben ähnliche Rollen und arbeiten zusammen zur
verteilten Lösung eines Problems
O. Kao
Webbasierte Informationssysteme
4-3
4.2 Client/Server-Modell
• Gliederung in zwei logische Teile
Ein oder mehrere Clients: Nehmen Dienste oder Daten des Servers
nach einer Anforderung in Anspruch
Server: stellt Dienste oder Daten zur Verfügung
⇒ Client und Server sind zwei Ausführungspfade oder –einheiten mit
Interaktion nach dem Muster Erzeuger/Verbraucher
• Clients sind auslösende Elemente, d.h. sie können zu jedem
beliebigen Zeitpunkt eine Anfrage starten
• Server sind reagierende Elemente
Client
Aufruf
Ergebnis
Client
Aufruf
Server
Ergebnis
Prozess:
O. Kao
Server
Webbasierte Informationssysteme
Rechner:
4-4
Zwei- und DreischichtenModelle
• Grundkomponenten einer verteilten Anwendung
Benutzungsoberfläche
Benutzungsinterface
Verarbeitung oder Anwendungslogik
Datenmanagement
Persistente Datenspeicherung
• Einfache Verteilung dieser Komponenten in Server und Client, d.h.
in zwei Stufen (Two Tier Model)
• Abhängig von der Position der Trennlinie ergibt sich folgende
Klassifikation von Clients
Null Client: Trennung zwischen Benutzungsoberfläche und –interface ⇒
Client übergibt nur Tastaturschläge und Mausbewegungen
Thin Client: zuständig für Ergebnispräsentation ⇒ Trennlinie zwischen
Benutzungsinterface und Verarbeitung
O. Kao
Webbasierte Informationssysteme
4-5
Zwei- und DreischichtenModelle (2)
• … Klassifikation von Clients
Applet Client: Einige Prozesse werden vom Server herunter geladen
und lokal ausgeführt
Fat Client: Trennung innerhalb der Anwendungslogik ⇒ Client und
Server kooperieren bei der Verarbeitung
• Mehrschichtige Anwendungen haben Vorteile bezüglich
Skalierbarkeit der Server
Erweiterbarkeit
• Dreischichtenmodell (Three Tier Model)
Clients (Präsentationsschicht)
Anwendungs- und Verarbeitungsserver
Datenbankserver
O. Kao
Webbasierte Informationssysteme
4-6
Schicht 1
Schicht 2
Grafische Darstellung:
Two Tier vs. Three Tier
Schicht 3
Präsentation: Web Browser
Verarbeitung: Web Server+Datenbank
Schicht 2
Schicht 1
Präsentation: Web Browser
Verarbeitung: Web Server
O. Kao
Speicherung:
Datenbank
Webbasierte Informationssysteme
4-7
Nachteile konventioneller
Client/Server-Konstrukte
•
•
•
•
Ausfallsicherheit: Serverausfall nicht zu kompensieren
Leistungsprobleme: Server als Engpass bei steigendem Volumen
Mögliche Lösung 1: Leistungsfähigkeit des Servers erhöhen
Mögliche Lösung 2: Erweiterte Client/Server-Systeme, d.h.
Implementierung von Diensten als mehrere Server-Prozesse in
separaten Rechnern
Partitionierung: Jeder Server verwaltet einen Teil der Information
Beispiel: Web-Server mit unterschiedlichen Websites
Replikation: Verteilung von konsistenten Datenmengen auf mehreren
unabhängigen Rechnern
Beispiel: Abbildung des Suchindexes auf mehreren Webservern, die
unter der gleichen Adresse erreichbar sind
Bei Bedarf ⇒ Zusammenarbeit zur Bereitstellung von Diensten, z.B.
Client-Server-Server-Systeme
O. Kao
Webbasierte Informationssysteme
4-8
4.3 Erweiterte Client/ServerSysteme
• Aufbau von Client/Server-Ketten
Rekursiv: Der aktuelle Server reicht einen Teil der Anforderung an
einen weiteren Server und bekommt dann die Ergebnisse zurück
Transitiv: Der Client bekommt die Antwort von dem letzten Server in
der Kette, nicht von dem, an den die Anforderung gerichtet war
• Klassifikation bzgl. der Funktionalität der dazwischen liegenden
Elemente bei Client-Server-Server-Systemen
Proxy: Stellvertreter für mehrere Server
Broker: Vermittlung zwischen mehreren Clients und mehreren Servern
Trader: Sucht aus einer Menge ihm bekannter Server denjenigen
heraus, der für die gestellte Anforderung am besten geeignet ist
Balancer: Verteilung der Arbeitslast verursacht durch die aktuellen
Clientanforderungen gleichmäßig über die vorhandenen Server
Agent: Koordiniert mehrere Serveranfragen für den steuernden Client
O. Kao
Webbasierte Informationssysteme
4-9
Balancer und Proxy
• Balancer
Mehrere identische – in der Regel replizierte – Server stehen zur
Verfügung
Balancer überprüft laufend die Auslastung der Teilelemente und
wertet die Last durch die ankommenden Anfragen aus
Die Anforderungen werden so verteilt, dass die Antwortzeit minimiert
wird und alle Server im Verbund etwa gleichzeitig ausgelastet sind
• Proxy: Häufigste Ausprägung als gemeinsamer Cacheverwalter
für mehrere Clients
Proxy fängt die Clientanforderungen an und versucht diese sofort –
z.B. aus dem Cache – zu bedienen
Falls nicht möglich, leitet er die Anfragen an den Server weiter und
leitet die Rückantwort zurück
Serverantworten werden zwischengespeichert und stehen den
anderen Clients zur Verfügung
O. Kao
Webbasierte Informationssysteme
4-10
Proxy-Server und Caches
• Proxy-Konzept bei Webbrowsern
Inhalte, auf denen eine Gruppe von Benutzern / Anwendungen
zugegriffen hat
Mit spezieller HTTP-Anforderung und Mitarbeit des Originalservers
wird die Aktualität des Caches überprüft
Installation von Proxies reduziert die Anfragelast auf die Webserver
und verringert unnötige Netzwerkkommunikation
Web
server
Client
Proxy
server
Web
server
Client
O. Kao
Webbasierte Informationssysteme
4-11
Broker
• Ermöglicht den Clients Zugriff auf geeignete Dienste ohne dass
diese die Adresse der entsprechenden Dienste kennen müssen
Alle Server im Verbund registrieren ihre angebotenen Dienste beim
Broker
Broker ermittelt den passenden Server und liefert die Clientanfragen an
den Server
Übermittelt die Servereigenschaften an die Clients
Vorteile: Orts- und Migrationstransparenz
Nachteile eines zentralen Brokers: Engpass, mangelnde Ausfallsicherheit
Replikation – im Extremfall ein Broker pro Client – führt zu aufwendigen
Prozessen zur Erhaltung der Datenkonsistenz
arded
2. Forw
1. Client Request
Client
Broker
4. Forwarded Reply
Request
Reply
3. Server
Server
Server
Server
Server
O. Kao
Webbasierte Informationssysteme
4-12
Klassifikation von Brokern,
Trader und Agenten
• Klassifikation von Brokern
Forwarding Broker: Übermittelt sowohl die Anforderung als auch die
Antwort
Separater oder handle-driven Broker: Übermittelt dem Client alle
notwendigen Informationen (Name, Adresse, Anforderungsformat) des
gewünschten Servers, so dass der Client direkt mit dem Server in
Kontakt treten kann
• Trader
Stehen mehrere Server in unterschiedlicher Qualitäten für ein und
denselben Dienst zur Verfügung, dann sucht der Trader aufgrund der
Clientspezifikation den passenden Dienst heraus
• Agenten
Ablaufplaner und –abwickler für komplexe Serviceleistungen
Anforderung wird in mehrere Teile zerlegt, an unterschiedliche Server
übermittelt und die Antworten zu einer Rückantwort zusammengefasst
O. Kao
Webbasierte Informationssysteme
4-13
Variationen des
Client/Server-Modells
• Zusätzliche Anforderungen durch Verwendung mobiler Codes
und mobiler Agenten und durch mobile Kommunikation
• Mobiler Code und mobile Agenten
Beim Client/Server sind die Programme ortsfest und Daten zu den
Programmen versendet
Versendung eines Datums oft zeitaufwendiger als seine Verarbeitung,
insbesondere bei multimedialen Daten
Grundsatzfrage: Sollen die Daten oder das Programm verschickt
werden? (Function shipping vs. Data shipping)
Antwort hängt von konkreter Anwendung ab
Verschicken von Programmcode, um eine große Datenmenge vor
Ort zu verarbeiten, kann kostengünstiger sein
Realisierung einfacher, wenn Daten versendet werden
O. Kao
Webbasierte Informationssysteme
4-14
Mobiler Code
• Ablauf
1. Client fordert Code vom Server an
2. Code wird von einem Server zum Client übertragen
3. Code wird auf dem Client ausgeführt
• Vorteil der lokalen Ausführung
Kurze Antwortzeiten bei Interaktion, da keine Netzwerkkommunikation
mehr notwendig
• Nachteile
Der Appletcode wird üblicherweise auf unterschiedlichen Architekturen
interpretiert ⇒ geringe Leistungsausnutzung, langsame Ausführung
Sicherheitsprobleme
3
2
Service
1
z we
t
e
N
rk
Server
Applet
Client
Desktop
Server
O. Kao
Webbasierte Informationssysteme
4-15
Mobiler Code (2)
• Standardisierung von Diensten führt dazu, dass die Funktionalität eines
mobilen Codes in den Client eingefügt wird (Beispiel: Webbrowser)
• Zusatzfeatures von Websites existieren, z.B. Push-Modell (Server initiiert
Interaktion)
Server-Veränderungen werden dem Client (sofort) mitgeteilt
• Erweiterung: Mobile Agenten
Einheit aus Code und Daten, die durch selbständig oder geführt durch das
Netz reist, sucht passende Stationen aus, führt Aufgaben aus, sammelt
Ergebnisse und meldet diese irgendwann zurück
Beispiel: Vergleiche die Preise für Festplatte XY in allen Webshops
Beispiel: Verbindung mehrerer unabhängiger Informationsquellen (Hotel +
Golfplatz in der Nähe + Hafen für eine Kreuzfahrt in der Nähe+…)
Zusätzliche Probleme
Eindeutige Identifizierung des Agenten anhand der Identität des
Benutzers, in dessen Auftrag der Agent arbeitet
Wie reagieren Agenten auf Änderungen der Stationen, z.B. Websites?
O. Kao
Webbasierte Informationssysteme
4-16
4.4 Gleichrangige Prozesse
(Peer Processes)
• Gleichrangige Prozesse sind verantwortlich für die
Konsistenz der Ressourcen auf Anwendungsebene
Synchronisation der Aktivitäten auf Anwendungsebene
• Verzicht auf Server-Prozesse reduziert die Kommunikationsverzögerungen zwischen Prozessen beim Zugriff auf lokale Objekte
• Beispiele
File-Sharing-Systeme: Jedes
System teilt den anderen
Peer-Prozessen, welche
Dateien zur Verfügung
stehen
Whiteboards: Ein Bild ist für
alle Teilnehmer sichtbar,
Änderungen werden durch
Gruppenkommunikation allen
mitgeteilt
O. Kao
Anw.
2
Anw.
1
Anw.
3
Webbasierte Informationssysteme
4-17
Peer-to-Peer-Systeme
• Häufige Nutzung: File-Sharing. Notwendige Schlüsselaufgaben
Lookup Mechanismus: Wo befinden sich passende Daten?
Dezentralisierte Speicherung und Übertragung der geforderten Daten
• Erstes Beispiel eines solchen Systems: NAPSTER
Lookup durch zentralen Server
Transfer durch direkte Verbindung (Peer-to-Peer)
Allgemeine Napster Eigenschaften
Einfaches Protokoll mit ca. 30 Befehlen, das auf TCP/IP aufsetzt
Kontrolle durch zentrale Server
Ursprünglich Beschränkung auf mp3-Files
NAPSTER-Server
Verwaltung der Metadaten (z.B. Username, Passwort)
Indizierung aller verfügbaren Dateien (shared files)
Verarbeitung der Suchanfragen von Benutzern
NAPSTER-Clients
Download direkt von Client zu Client (Peer-to-Peer)
O. Kao
Webbasierte Informationssysteme
4-18
Napster - Prinzip
Transfer
Client
Suche
Client
Registrierung
NAPSTERServer
Login
Client
O. Kao
NAPSTERMetaserver
Webbasierte Informationssysteme
4-19
Beispiel für Peer-to-Peer:
Gnutella
• Wichtiger Architekturnachteil von Napster: Zentraler Server
• Auswirkungen
Single point of failure
Verlangsamung des Diensts
Anfällig für DoS-Angriffe
• Modifizierte Architektur beim Konzept Gnutella
Knoten sind Servents (sowohl SERVer als auch cliENT)
Lookup und Transfer nur über Servents (echtes Peer-to-Peer)
Gnutella ist ein Protokoll mit folgenden Eigenschaften
Setzt auf TCP/IP auf
Benötigt keinen zentralen Server
Diverse Clients (Gnutella-Client, LimeWire, … ) für verschiedene
Plattformen
⇒ Dezentralisiertes Peer-to-Peer File-Sharing-System
O. Kao
Webbasierte Informationssysteme
4-20
Gnutella - Prinzip
Servent
Transfer
Ping, Pong, Query, …
Servent
Servent
Servent
Servent
Servent
Servent
O. Kao
Webbasierte Informationssysteme
4-21
Gnutella - Protokoll
•
•
Verbindung: CONNECT Paket wird mit OK Paket bestätigt
Kommunikation mittels eigener Pakete (Deskriptoren)
Feld
Bedeutung
Bytes
ID
16
Zufällige Zahl zur Unterscheidung der Pakete
Deskriptor
1
Art des Pakets: Ping, Pong, Query, Query_Hit, Push
TTL
1
Time To Live (Zahl der max. Weiterleitungen)
Hops
1
Zahl der bereits erfolgten Weiterleitungen
Länge
3
Länge des „Payloads“
•
Gnutella-Regeln
1. Weiterleitung eines Deskriptors ⇒ Erhöhung der Hopszahl um 1
2. Ist Hops=TTL (Time To Live) so wird der Deskriptor verworfen
(Standard für TTL ist 7)
3. Hat ein Deskriptor identische IDs und identische Payloads zu einem
vorherigen, so wird dieser verworfen
O. Kao
Webbasierte Informationssysteme
4-22
Gnutella Elemente: PING, PONG,
QUERY, QUERY_HIT, PUSH
• PING
Durchsucht das Netzwerk nach Servents, erstellt neue Verbindungen
Versendung mittels Broadcast mit maximal 4 Verbindungen pro Servent
• PONG (PING_RESPONSE)
Wegermittlung mittels Deskriptor-ID und Verbindungs-ID
Versendung nur zum direkten Vorgänger
• QUERY
Anonyme Dateisuche, überträgt Suchstring und Mindestgeschwindigkeit
Weiterleitung durch Broadcast bei Nichtbeantwortung
• QUERY_HIT: Antwort auf QUERY
Wird verschickt, falls die gesuchte Datei lokal vorhanden
• PUSH
Einsatz, wenn HTTP_REQUEST des Dateitransfers fehlschlägt (TimeOut)
Rollentausch von Sender und Empfänger bei Dateitransfers via HTTP
Nutzlos wenn beide Transferteilnehmer Firewalls benutzen
O. Kao
Webbasierte Informationssysteme
4-23
Gnutella - Ablauf
QUERY
user
QUERY_HIT
TRANSFER
user
user
user
user
user
us
er
er
us
user
er
us
Webbasierte Informationssysteme
us
er
us
er
er
us
O. Kao
4-24
Zusammenfassung Gnutella
• Unstrukturierte Datenverteilung
Nachteilig bei Suchanfragen
Gut für Stabilität und Netzwerkbelastung
• Probleme bei Herstellung der ersten Verbindung
• Skalierungsproblem
Schneeballprinzip/Flooding verursacht zu viel Verkehr
Begrenzter Suchraum durch maximale Anzahl der Hops Auf eine Anfrage
kommen noch 3
Überflüssige Nachrichten durch mögliche Zyklen
Datenpakete
Hoher Traffic überlastet Teilnehmer mit niedriger Bandbreite
Durchschnittlich 3 Verbindungen pro Servent
30 Bytes pro Nachricht, wegen TCP/IP Nutzung 70 Bytes
NAQR = 10 Pakete/s Queryanteil ca. ¼ des Gesamtaufwandes
⇒3 x 70 x 10 x 4 = 8400 Bytes/s bzw. 67,2 KBit/s > 56KBit/s
O. Kao
Webbasierte Informationssysteme
4-25
4.5 Ereignisse und
Benachrichtigung
• Ereignisse: Eine Veränderung in dem Objekt ist aufgetreten
Beispiel: Anklicken einer Schaltfläche, Eingabe von Text, …
• Benachrichtigungen
Ein Objekt bekommt die Meldung, dass ein Ereignis in einem anderen
Objekt passiert ist ⇒ Entsprechende Reaktion möglich
In der Regel asynchroner Ablauf
Beispiel: Benachrichtigung der Komponenten zur
Anzeigenaktualisierung
• Paradigma Veröffentlichung-Abonnement (Publisher-Subscriber)
Ereignis-erzeugende Objekte veröffentlichen die möglichen
Ereignistypen
Ereignis-wahrnehmende Objekte abonnieren die zu
berücksichtigenden Ereignistypen
Tritt bei einem Publisher ein Ereignis auf, so werden alle für diesen
Typ registrierten Abonnenten benachrichtigt
O. Kao
Webbasierte Informationssysteme
4-26
Eigenschaften
ereignisgesteuerter Systeme
• Heterogenität
Ereignisbenachrichtigung ermöglichen Kooperation von Objekten eines
VS, für die keine Kommunikation vorgesehen war, z.B. in Internet
Bedingung: Veröffentlichung/Registrierung der Ereignisse über
geeignete Schnittstellen
• Asynchronität: Entkopplung von Veröffentlichung/Abonnement
• Eine Ereignisquelle kann mehrere Ereignistypen veröffentlichen
Typ legt die Ereignisklasse fest
Attribute eines Ereignisses: Name des erzeugenden Objekts,
zugehörige Operation samt Parametern, Zeit, …
Der Typ und die Attribute werden zur Auswahl der interessierten
Empfänger bzw. für Festlegung des Abonnements benötigt
O. Kao
Webbasierte Informationssysteme
4-27
Beispiel 1: Zusammenarbeit
mehrerer Benutzer
• Zusammenarbeit mehrerer Benutzer mit unterschiedlichen
Dokumenten
Zustand eines jeden Arbeitsplatzes (Netzwerkplatz) wird auf dem
lokalen Rechner verwaltet und – beim Einloggen des Benutzers – auf
die lokalen Rechner der interessierten Benutzer repliziert
Ereignisse melden Änderungen an Objekten bzw. An- und Abmelden
von Benutzern
Jede Replik abonniert und enthält alle Benachrichtigungen
Entkopplung Abonnent von Objekt, da unterschiedliche Benutzer zu
unterschiedlichen Zeiten aktiv sein können
O. Kao
Webbasierte Informationssysteme
4-28
Hauptkomponenten für
Ereignisbenachrichtigungen
• Ereignisdienst: Datenbank veröffentlichter Ergebnisse und
Interessen der Abonnementen
• Relevantes Objekt: Objekt, dessen Zustand geändert wird
• Beobachterobjekt: Entkopplung relevanter Objekte von
Abonnenten
Übernahme der Verarbeitung von Benachrichtigung, um die
Verarbeitungslogik in den veröffentlichenden Objekten zu reduzieren
Rolle Weitergabe: Wickelt den gesamten Sendevorgang ab, bekommt
alle Informationen über relevante Abonnenten
Rolle Benachrichtigungsfilter: Reduktion der empfangenen
Benachrichtigungen abhängig von a-priori definierten
Abonnentenfiltern
Rolle Ereignismuster: Beschreibung einer Beziehung zwischen
mehreren Ereignissen, auf die ein Abonnent reagieren will
Rolle Benachrichtungsmailboxen: Verzögerung der Auslieferung von
Benachrichtigungen ⇒ der Beobachter speichert diese temporär, bis
der Abonnent aktiv ist und diese annehmen kann
O. Kao
Webbasierte Informationssysteme
4-29
Aktionen bei
Ereignisbenachrichtigungen
• Betrachtung von drei ausgewählten Fällen
1. Relevantes Objekt innerhalb des Ereignisdienstes ohne Beobachter
sendet Benachrichtigung direkt an die Abonnenten
2. Relevantes Objekt innerhalb des Ereignisdienstes sendet
Benachrichtigung an die Abonnenten über den Beobachter
3. Relevantes Objekt außerhalb des Ereignisdienstes ⇒ ein Beobachter
fragt das relevante Objekt nach aufgetretenen Ereignissen und sendet
ggf. die Benachrichtigung an die Abonnenten
Relevantes Objekt
Abonnent
1.
Relevantes Objekt
2.
Relevantes Objekt
Beobachter
Benachrichtigung
Beobachter
3.
Ereignisdienst
O. Kao
Benachrichtigung
Abonnent
Benachrichtigung
Abonnent
Benachrichtigung
Webbasierte Informationssysteme
4-30

Documentos relacionados