Systemarchitekturen für verteilte Anwendungen
Modul CS4151/CS4151T (Teilmodul des Vertiefungsblocks Internettechnologien/ Parallele und verteilte Systeme), Universität zu Lübeck
Modul CS4151/CS4151T (Teilmodul des Vertiefungsblocks Internettechnologien/ Parallele und verteilte Systeme), Universität zu Lübeck
Set of flashcards Details
| Flashcards | 41 |
|---|---|
| Language | Deutsch |
| Category | Computer Science |
| Level | University |
| Created / Updated | 22.07.2016 / 22.07.2016 |
| Weblink |
https://card2brain.ch/box/systemarchitekturen_fuer_verteilte_anwendungen
|
| Embed |
<iframe src="https://card2brain.ch/box/systemarchitekturen_fuer_verteilte_anwendungen/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
Softwarearchitektur
- strukturierte oder hierarchische Anordnung der Systemkomponenten eines Softwaresystems
- Beschreibung der Beziehungen der Softwarekomponenten
starke Kohärenz
Teilsystem ist für zusammenhängende, klar umrissene Aufgaben verarntwortlich
starke Kohärenz
Vorteile
- Einfachheit
- Verständlichkeit
- Redundanzfreiheit
- bessere Teambildung
lose Kupplung
- schmale Schnittstellen zwischen Teilsystemen
- kleine Menge von Methoden (API)
- Teilsysteme kennen nur wenige andere Teilsysteme
Drei-Schichten-Architektur
Schichten
- Präsentationsschicht
- Anwendungsschicht
- Persistenzschicht
Drei-Schichten-Architektur
Präsentationsschicht
- Präsentation fachlicher Daten
- Dialogkontrolle
- weiß wenig von Applikationsschicht
- implementiert keine fachlichen Abläufe
Drei-Schichten-Architektur
Anwendungsschicht
- Entitätsklassen für fachliche Daten
- Geschäftsprozess-Klassen für fachliche Abläufe
Drei-Schichten-Architektur
Persistenzschicht
- verwaltet fachliche Objekte in DB
- kennt das Datenbank-Schema
- enthält z.B. SQL-Befehle im Fall von RDBMS
Bewertung von Softwarearchitekturen
Kriterien für gute Architekturen
- System kann Anforderungen erfüllen
- Verhalten
- Qualität
- Lebenszyklus
Bewertung von Softwarearchitekturen
Kriterien für schlechte Architekturen
Architektur hindert System daran Anforderungen zu erfüllen
Bewertung von Softwarearchitekturen
Architektur ist für bestimmtes Problem immer mehr oder weniger geeignet
Bewertung von Softwarearchitekturen
allgemeine Ziele und Anforderungen
- Entscheidungen
- bewusst treffen
- explizit machen
- wohl definierte Abstraktionsschichten mit schmalen Schnittstellen
- starke Köhärenz
- lose Kopplung
- Redundanzfreiheit
- leichte Wartbarkeit
- gute Erweiterbarkeit
- Wiederverwendbarkeit von Teilen des Systems
- gute, zielgerichtete Dokumentation aus Sicht des potentiellen Lesers
Aspekte verteiler Systeme
- mindestens 3 Dimensionen
- Dimensionen voneinander unabhängig
- orthogonal
- dekorreliert
Aspekte verteilter Systeme
Mindestdimensionen
- Nebenläufigkeit
- Verteilung
- Persistenz
Aspekte verteilter Systeme
weitere mögliche Dimensionen
- Heterogenität
- Quality of Service
Verteilung
- Kommunikation von Prozessen auf verschiedenen Rechnern
- Interprozess-Kommunikation auf verschiedenen Abstraktionsebenen
Verteilung
Kommunikation von Prozessen auf verschiedenen Rechnern
Austausch von Daten und Anstoßen von Diensten
Verteilung
Interprozess-Kommunikation auf verschiedenen Abstraktionsebenen
- Datenaustausch
- Call Level-Interface-Aufruf von Diensten
- Service-orientierte Architekturen
Verteilung
Interprozess-Kommunikation auf verschiedenen Abstraktionsebenen
Datenaustausch
- Socket
- Java-API
- HTTP-Request
- Servlets
- JSB
- Nachrichtenaustausch
- MOM
- JMS
Verteilung
Interprozess-Kommunikation auf verschiedenen Abstraktionsebenen
Call Level-Interface-Aufruf von Diensten
- Remote Procedure Call
- RMI in Java
- (OO)-RPC in heterogenen Systemen
- CORBA
- SOAP
Verteilung
Interprozess-Kommunikation auf verschiedenen Abstraktionsebenen
Service-orientierte Architekturen
- Web Services
Nebenläufigkeit
Designkonzepte
- Server/Handler-Muster
- Synchrone/Asynchrone Aufrufe
Nebenläufigkeit
typisch
- Methodenaufrufe synchron
- Asynchronität selbst implementieren (Threads)
Nebenläufigkeit
typisch
Idee
Thread erzeugen, der Methode nebenläufig zu Hauptthread ausführt
Nebenläufigkeit
typisch
Problem
wie bekommt Hauptthread Rückgabewert
Nebenläufigkeit
Server/Handler-Muster
Problem
- Server bietet Dienste an
- Clients fordern Dienste an, die vom Server ausgeführt werden
- Server kann neue Anforderungen nicht annehmen, da er beschäftigt ist
Nebenläufigkeit
Server/Handler-Muster
Ziel
Server soll mehrere Aufgaben gleichzeitig annehmen können und erreichbar bleiben
Nebenläufigkeit
Server/Handler-Muster
Lösung
Server delegiert Aufgabe an Handler
- Server erzeugt Handler-Objekt
- Handler läuft in eigenem Thread und bearbeitet eigentliche Anfrage
- Server benötigt nur kurze Zeit zum Erzeugen des Handlers und steht sofort wieder zur Verfügung
Nebenläufigkeit
Synchrone/Asynchrone Aufrufe
synchrone Aufrufe
Client ruft Dienst auf und wartet, bis dieser beendet ist
- blockiert
Nebenläufigkeit
Synchrone/Asynchrone Aufrufe
Asynchrone Aufrufe
Client setzt nach Dienstaufruf seine Aufgaben unmittlebar fort
- ermöglicht parallele Ausführung in verteilten Systemen
- bessere Performance
- keine Verzögerungen wegen hoher Übertragungszeiten
Nebenläufigkeit
Synchrone/Asynchrone Aufrufe
Asynchrone Aufrufe
Muster
- Callback-Verfahren
- Polling
Nebenläufigkeit
Synchrone/Asynchrone Aufrufe
Asynchrone Aufrufe
Muster
Callback-Verfahren
Caller ruft callback-Methode des Client auf, sobald Ergebnis vorliegt
Welches Muster für asynchrone Aufrufe ist das?
Callback-Verfahren
Nebenläufigkeit
Synchrone/Asynchrone Aufrufe
Asynchrone Aufrufe
Muster
Polling
- Client fragt laufend Caller ob Ergebnis vorliegt
- ohne Ergebnis bearbeitet Client andere Aufgaben
Welches Muster für asynchrone Aufrufe ist das?
Polling
Persistenz
- Daten werden an zentraler Stelle persistent verwaltet
- API zum netzweiten Zugriff auf Datenbanken
Persistenz
Varianten
- Framework mit Persistenzdiensten
- Persistenz-Container
Persistenz
Varianten
Framework mit Persistenzdiensten
Persistenz
Varianten
Persistenz-Container
z.B. EJB
Welche Variante von Persistenz ist das?
Framework mit Persistenzdiensten
