18Entwicklung verteilter Systeme

© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.

Wissen. Was praktisch zählt.

Stand: 14.05.13 Folie 18.1

Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik

18 Entwicklung verteilter Systeme

18.0 Einführung Lernziele Verteilte Systeme

18.1 Charakteristika verteilter Systeme Entwurfsfragen Kommunikationsmodelle Middleware

18.2 Client-Server-Systeme Prozesse in Client-Server-Systemen Schichtenarchitektur



Stand: 14.05.13 Folie 18.2


18 Entwicklung verteilter Systeme

18.3 Architekturmuster für verteilte Systeme Master-Slave-Architektur zweischichtige Client-Server Architektur mehrschichtige Client-Server Architektur verteilte Komponentenarchitektur Peer-to-Peer-Architektur

18.4 Software als Service



Stand: 14.05.13 Folie 18.3


18.0 Lernziele

die Hauptprobleme bei Entwurf und Implementation verteilter Softwaresysteme kennen

das Client-Server-Modell und die Schichtenarchitektur von Client-Server-Systemen verstehen

häufig genutzte Muster für verteilte Systemarchitekturen kennen und ihre Eignung für bestimmte Anwendungs-systeme beurteilen können

das Konzept der Software als Service verstehen



Stand: 14.05.13 Folie 18.4


18.0 Verteilte Systeme

mehrere voneinander unabhängige Computer, die dem Benutzer als ein einzelnes kohärentes System erscheinen

Ressourcenteilung gemeinsame Hardware-Nutzung: Massenspeicher, Drucker, etc. gemeinsame Software-Nutzung: Dateien, Compiler, etc.

Offenheit Standardprotokolle Hard- und Software verschiedener Hersteller

Nebenläufigkeit verschiedene Prozesse gleichzeitig auf verschiedenen Rechnern Kommunikation zwischen den Prozessen möglich



Stand: 14.05.13 Folie 18.5


18.0 Verteilte Systeme

Skalierbarkeit Kapazitätserweiterung durch neue Ressourcen begrenzt durch das Netzwerk

Fehlertoleranz Möglichkeit der Replizierung von Information bei Ausfällen oft eingeschränkter Dienst weiter möglich

komplexer als zentrale Systeme Entwicklung, Implementierung und Testen schwieriger Verhalten schwerer vorhersagbar Leistung von vielen verschiedenen Faktoren abhängig keine zentrale Steuerung



Stand: 14.05.13 Folie 18.6


18.1 Entwurfsfragen

Transparenz Was soll der Benutzer über die Verteilung wissen?

Offenheit Sollen nur Standardprotokolle verwendet werden?

Skalierbarkeit Kann die Systemkapazität leicht erweitert werden?

Informationssicherheit Gibt es gemeinsame Sicherheitsrichtlinien?

Dienstgüte (QoS – Quality of Service) Wie wird eine akzeptabele Dienstgüte spezifiziert?

Fehlermanagement Wie werden Fehler entdeckt, eingedämmt und behoben?



Stand: 14.05.13 Folie 18.7


18.1 Transparenz

Verteilung bleibt für Benutzer verborgen System wird als Einheit wahrgenommen Verhalten ist unabhängig von der Verteilung

Voraussetzungen Abstraktionen der Ressourcen Abbildung von logischen Ressourcen auf physikalische

Realisierungen durch Middleware

Beeinträchtigung durch fehlende zentrale Steuerung unterschiedliches Verhalten der einzelnen Rechner Verzögerungen im Netz

Information der Benutzer über Verteilung bessere Einstellung auf Folgewirkungen der Verteilung



Stand: 14.05.13 Folie 18.8


18.1 Offenheit

Offene verteilte Systeme erstellt nach allgemeingültigen Standards Zusammenarbeit von Komponenten aller Anbieter

Offenheit auf verschiedenen Layern auf Netzwerkebene üblich (Internetprotokolle) auf Komponentenebene seltener

Offene Standards CORBA (Common Object Request Broker Architecture):

in der Praxis nicht durchgesetzt Webservicestandards:

wegen Performanzproblemen stattdessen oft REST-Protokolle(Representational State Transfer)



Stand: 14.05.13 Folie 18.9


18.1 Skalierbarkeit

hohe Dienstgüte auch bei steigenden Anforderungen vertikale Skalierung durch stärkere Ressourcen horizontale Skalierung durch zusätzliche Ressourcen

Skalierungsdimensionen Umfang

• bei zunehmender Zahl von Benutzern weitere Ressourcen hinzufügen

Verteilung• geografische Verteilung der Komponenten ohne Leistungsverlust

Verwaltbarkeit• auch bei wachsendem System mit Verteilung der Komponenten

in unabhängigen Institutionen



Stand: 14.05.13 Folie 18.10


18.1 Sicherheit

Verteilte System leichter angreifbar als zentrale schwächste Komponente als Hintertür (Back door)

in andere Teile des Systems

Angriffsarten mithören (interception) unterbrechen (interruption) modifizieren (modification) Informationen einspielen (fabrication)

Sicherheitsrichtlinien meist nicht für alle Teile des Systems gleich untereinander nicht immer kompatibel



Stand: 14.05.13 Folie 18.11


18.1 Dienstgüte

Fähigkeit zur Dienstleistung verlässlich mit akzeptabler Antwortzeit und akzeptablem Durchsatz

Spezifizierung der Dienstgüte im Voraus nicht kosteneffizient,

wenn hohe Güte bei Spitzenbelastung verlangt wird schwierig bei unvereinbaren Parametern

wie Zuverlässigkeit und Durchsatz

wichtig bei zeitkritischen Daten Audio und Video ggf. Verhandlung der Dienstgüte



Stand: 14.05.13 Folie 18.12


18.1 Fehlermanagement

Robustheit gegen Ausfälle einzelner Teile “You know that you have a distributed system

when the crash of a system that you’ve never heard of stops you getting any work done.”

Mechanismen für Fehlertoleranz nötig Entdeckung von Ausfällen weitere Bereitstellung der noch möglichen Dienste möglichst automatische Fehlerbehebung



Stand: 14.05.13 Folie 18.13


18.1.1Prozedurale KommunikationKellner Gast

Was darf es sein?

Als Vorspeise bitte eine Spargelcremesuppe.

Und als Hauptgang?

Ein großes Steak, bitte.

Wie möchten Sie Ihr Steak?

Medium, bitte.

Mit Folienkartoffel oder Pommes frites?

Ach, bringen Sie mir doch einfach Menü 1!etc.



Stand: 14.05.13 Folie 18.14


18.1.1Nachrichtenbasierte Kommunikation

<vorspeise><gericht = "Suppe" typ = "Spargelcreme" /> <gericht = "Suppe" typ = "Kürbis" /><gericht = "Krabbencocktail" />

</vorspeise><hauptgericht>

<gericht = "Steak" typ = "Lende" garstufe = "medium"/> <gericht = "Steak" typ = "Filet" garstufe = "durch"/><gericht = "Zander" />

</hauptgericht><beilage>

<gericht = "Folienkartoffel" portionen = "2" /> <gericht = "Salat" typ = "Feld" />

</beilage>

Kellner an Küche



Stand: 14.05.13 Folie 18.15


18.1.1Prozedurale Kommunikation

Remote Procedure Calls (RPCs) Aufruf zwischen Komponenten wie bei lokalen Methoden Middleware fängt Aufruf ab und leitet ihn weiter entfernte Komponente führt Methode aus liefert Ergebnis über Middleware zurück

Nachteile des RPC-Ansatzes beide Komponenten müssen gleichzeitig verfügbar sein beide Komponenten müssen sich gegenseitig referenzieren

können



Stand: 14.05.13 Folie 18.16


18.1.1Nachrichtenbasierte Kommunikation

Senden von Nachrichten Komponenten sendet Nachricht über benötigten Service Middleware leitet die Nachricht an den Empfänger weiter Empfänger parst die Nachricht, führt Berechnung aus

und sendet Nachricht mit dem Ergebnis Middleware leitet die Nachricht an den ersten Sender

Vorteile des nachrichtenbasierten Ansatzes Komponenten müssen sich nicht gegenseitig kennen Komponenten müssen nicht gleichzeitig verfügbar sein



Stand: 14.05.13 Folie 18.17


System 2System 1

18.1.2Middleware

Anwendungskomponenten

Netzwerk

Betriebssystem

Middleware

Anwendungskomponenten

Middleware

Betriebssystem

Netzwerk

koordinierteOperation

Informationsaustausch undallgemeine Dienste

logischeInteraktion

physikalischeKonnektivität



Stand: 14.05.13 Folie 18.18


18.1.2Aufgaben der Middleware

Unterstützung für Interaktionen verbirgt physikalischen Standort von Komponenten wandelt Parameter um

Bereitstellung allgemeiner Dienste wiederverwendbare Implementierung von Diensten erleichtert Zusammenarbeit bietet konsistente Benutzerdienste => Kapitel 17



Stand: 14.05.13 Folie 18.19


18.2 Client-Server-Systeme

Verteilte Systeme im Internet meist Client-Server-Systeme

Benutzer arbeitet mit Programm auf lokalem Rechner Client, z.B. Webbrowser

Lokales Programm interagiert mit Programm auf entferntem Rechner Server, z.B. Webserver

Server bietet Dienste für viele Clients an Clients greifen auf Dienste zu Clients präsentieren die Ergebnisse dieser Dienste Clients müssen die Server kennen Clients brauchen andere Clients nicht zu kennen



Stand: 14.05.13 Folie 18.20


18.2 Client-Server-Interaktion

s1

s2 s3

s4

c1c2

c3

c4

c5

c6

c7 c8

c9

c10

c12

c11



Stand: 14.05.13 Folie 18.21


CC6CC5CC4

CC3CC2CC1

SC2

SC1

18.2 Clients und Server auf Computern

s1 s2

s3 s4

c3 c4c2c1

c5 c6 c7 c8 c9c10

c11

c12

Netzwerk



Stand: 14.05.13 Folie 18.22


C

S1

S2

C

S

C

S

18.2 Schichtenarchitektur bei Client-Server-Anw.

Präsentationsschicht

Datenverwaltungsschicht

Anwendungsverarbeitungsschicht

Datenbankschicht



Stand: 14.05.13 Folie 18.23


18.3 Architekturmuster für verteilte Systeme Master-Slave-Architektur

garantierte Antwortzeiten in Echtzeitsystemen Zweischichtige Client-Server-Architektur

einfache Client-Server-Systeme Zentralisierung aus Sicherheitsgründen

Mehrschichtige Client-Server-Architektur bei großen Mengen von Transaktionen

Verteilte Komponentenarchitektur Kombination von Ressourcen aus verschiedenen Systemen Implementierungsmodell für mehrschichtige Client-Server-Syst.

Peer-to-Peer-Architektur (P2P) direkter Austausch lokaler Information Server nur zur Bekanntmachung der Clients untereinander



Stand: 14.05.13 Folie 18.24


18.3.1Master-Slave-Architekturen

Echtzeitsysteme Prozesse zur Datenerfassung von Sensoren Prozesse zur Datenverarbeitung und Berechnung Prozesse zur Steuerung von Aktuatoren

Master-Prozess MCI (Darstellung und Interaktion) Berechnung Koordination und Kommunikation der Slave-Prozesse

Slave-Prozesse aufgabenspezifisch z.B. Messwerterfassung aus einer Sensoren-Gruppe z.B. Steuerung einer Aktuatoren-Gruppe



Stand: 14.05.13 Folie 18.25


18.3.1Master-Slave-Architekturen

Slave

Sensordaten-prozessor

Sensor-steuerungs-

prozess

Slave

Ampelsteuerungs-prozessor

Ampel-steuerungs-

prozess

Master

Leitwarten-prozessor

Koordinations- und Anzeige-prozess

Sensoren und Kamerasder Verkehrsüberwachung

Ampeln (WLZA) undWechselzeichen

Operator-Terminals



Stand: 14.05.13 Folie 18.26


Server

Client

18.3.2Zweischichtige Client-Server-Architekturen ein einziger logischer Server und beliebig viele Clients Thin Clients: nur Präsentationsschicht Fat Clients: auch weitere Schichten der Anwendung

-> Schichtenmodell 18.2 (inkonsistent zu 18.3.2)

Präsentationsschicht

Datenverwaltungsschicht

Anwendungsverarbeitungsschicht

Datenbankschicht

Thin Fat



Stand: 14.05.13 Folie 18.27


18.3.2Zweischichtige Client-Server-Architekturen Thin Clients

einfache Verwaltung der Clients Nutzung von Standard-Clients (z.B. Webbrowser) oft als GUI für Altsysteme hohe Belastung von Netz und Server

Fat Clients mehr Verarbeitung auf dem Client-Prozessor senkt Belastung von Netz und Server kann Fähigkeiten der Clients optimal nutzen aufwendigere Verwaltung z.B. bei neuer Funktionalität Beispiel: Geldautomaten



Stand: 14.05.13 Folie 18.28


18.3.3Mehrschichtige Client-Server-Architekturen Verteilung der Schichten auf verschiedene

Prozessoren oft dreischichtig:

Client, Webanwendungsserver, Datenbankserver

bessere Skalierbarkeit z.B. zusätzliche Webanwendungsserver

leichtere Verwaltung Anwendungslogik zentriert in einer Schicht

Beispiel: Kontoführung im Web



Stand: 14.05.13 Folie 18.29


18.3.3Client-Server-ArchitekturenArchitektur Anwendungen

zweischichtigThin Clients

• Anwendungen mit Altsystemen (Clients rufen Services auf)• Rechenintensive Anwendungen mit geringer Datenverwaltung

(z.B. Compiler)• Datenintensive Anwendungen ohne aufwendige Logik

(z.B. Browser)

zweischichtigFat Clients

• Anwendungen mit Standardprogrammen auf dem Client (z.B. Tabellenkalkulation)

• Anwendungen mit hohem Rechenaufwand (z.B. Visualisierung)

• mobile Anwendungen ohne garantierte Konnektivität (lokale Verarbeitung zwischengespeicherter Daten)

mehrschichtig

• große Anwendungen mit vielen Hunderten Clients• Anwendungen mit häufigen Veränderungen

bei Daten und bei Prozessen• Anwendungen mit Daten aus mehreren Quellen



Stand: 14.05.13 Folie 18.30


18.3.4Verteilte Komponentenarchitekturen

Keine Differenzierung nach Schichten / Clients / Servern Komponenten nutzen Dienste und stellen Dienste bereit Kommunikation erfolgt über Middleware

(remote procedure calls) komplexer als Client-Server-Architektur

Kommunikations-Middleware

Komp. 1

verfügbare

Dienste

Komp. 2

verfügbare

Dienste

Komp. 3

verfügbare

Dienste

Komp. 4

verfügbare

Dienste

Client

Client

Client

Client



Stand: 14.05.13 Folie 18.31


18.3.4Verteilte Komponentenarchitekturen

Anwendungen mit starker Verteilung(z.B. Data Mining mit mehreren Datenbanken)

in der Praxis selten wegen zwei Hauptnachteilen: hohe Komplexität

=> Verständnis-, Darstellungs- und Designprobleme Middleware-Standards nicht durchgesetzt

=> unterschiedliche Middleware unterschiedlicher Anbieter

Ablösung durch serviceorientierte Architektur vgl. Kapitel 19



Stand: 14.05.13 Folie 18.32


18.3.5Peer-to-Peer-Architekturen gleichberechtigte Teilnehmer

keine Unterscheidung zwischen Client und Server bessere Verteilung der Rechenlast

jeder Knoten im Netzwerk kann benutzt werden bessere Verteilung der Netzlast

keine Umwege erforderlich dezentralisiert

hoher Aufwand bei Suche über viele Peers halbzentralisiert

„Super-Peer“ als Vermittlung und zur Aufgabenverteilung Anwendung meist im PC-Bereich

Informationsaustausch: Filesharing, VoIP, ... Verteiltes Rechnen: SETI@home, ...



Stand: 14.05.13 Folie 18.33


18.4 Software als Service (SaaS)

Software bereitgestellt auf Server(n) Zugriff über Web-Browser keine lokale Installation keine Bindung an bestimmte Rechner / Mobilgeräte

Software verwaltet durch Anbieter keine Kosten beim Anwender kein Einfluss des Anwenders mögliche Probleme mit Datenschutz und Datensicherheit

Verschiedene Finanzierungsmodelle Werbung Abonnement pay per use



Stand: 14.05.13 Folie 18.34


18.4 SaaS und SOA

SaaS: Bereitstellung von Funktionalität auf Servern Zugriff über das Web Server verwaltet Benutzerdaten Server verwaltet Sitzungsdaten lange Transaktionen (z.B. Dokumentbearbeitung)

SOA: Struktur für Softwaresysteme Menge zustandsloser Dienste mehrere Anbieter möglich Verteilung möglich kurze Transaktionen (z.B. Aufruf und Rückgabe eines Dienstes)

SaaS kann mit SOA implementiert werden, muss aber nicht



Stand: 14.05.13 Folie 18.35


18.4 Implementationsfaktoren für SaaS

Konfigurierbarkeit Berücksichtigung spezifischer Bedürfnisse der Anwender

Mandantenfähigkeit virtuelle eigene Software für Anwender saubere Trennung der Daten effiziente Nutzung der Ressourcen

Skalierbarkeit Anpassung an schwer vorhersagbare Anzahl von Nutzern

Änderbarkeit Annahmen über Benutzerbedürfnisse möglicherweise falsch agile Entwicklungsmethoden sinnvoll



Stand: 14.05.13 Folie 18.36


18.4 Konfigurierung von Services

Corporate Design des Anwenders im UI und bei Dokumentausgabe (Branding)

Geschäftsregeln und Arbeitsabläufe bezüglich der Daten (z.B. Validierung) bezüglich der Nutzung (z.B. Reihenfolge der Bearbeitung)

Datenbanken Erweiterung des generischen Datenmodells des Service

um unternehmensspezifische Anteile

Berechtigungen individuelle Konten für Mitarbeiter / Mitarbeitergruppen des

Anwenders Regelungen für Zugriff auf Funktionen und Ressourcen



Stand: 14.05.13 Folie 18.37


18.4 Unterstützung der Skalierbarkeit bei SaaS

jede Komponente als einfacher zustandsloser Service kann auf jedem Server laufen Benutzer kann mit mehreren Instanzen arbeiten

asynchrone Kommunikation kein Warten auf Ergebnisse einer Interaktion Benutzer kann weiterarbeiten

Poolbildung für Ressourcen kein Ausfall von Servern wegen fehlender Ressourcen

detailliertes Sperren in der Datenbank unterhalb Datensatzebene

18Entwicklung verteilter Systeme

Documents

Transcript of 18Entwicklung verteilter Systeme