Webtechnologien
Wintersemester 2024
<!DOCTYPE HTML> <html lang="de"> <head> <meta charset="utf-8"> <title>Verteilte Systeme</title> <meta name="viewport" content="width=792, user-scalable=no"> <base target="_blank"> <link rel="stylesheet" href="/assets/styles/presentation.css"> </head> <body class="list"> <div class="notes"> <a href="text.html" target="_parent">♯</a> <a href="/notes/" target="_blank">♫</a> </div> <header class="caption"> <h1>Verteilte Systeme</h1> </header> <section bg="fb-relationships-full.png" id="verteilte-systeme" class="slide cover"><div><h2>Verteilte Systeme</h2> <footer> <ul> <li></li> </ul> </footer> </div></section> <section class="slide" id="einzelarbeit-vs-gruppenarbeit"><div><h2>Einzelarbeit vs. Gruppenarbeit</h2> <p>Viele Apskete verteilter Systeme finden sich ähnlich in sozialen Systemen, z.B. Gruppenarbeit. Im Kurs wurden folgende Apskete erarbeitet.</p> </div></section> <section class="slide" id="einzelarbeit"><div><h2>Einzelarbeit</h2> <h3 id="vorteile">Vorteile</h3> <ul> <li>Scheduling einfacher</li> <li>performant / keine Transaktionskosten/Overhead (kein Reden, keine Abstimmung, kein Warten)</li> <li>vollständiges Wissen</li> <li>Single Point of Truth</li> <li>Eigenverantwortung</li> <li>sicher (kein Abhören, keine Abhängigkeit)</li> </ul> </div></section> <section class="slide" id="gruppenarbeit--vorteile"><div><h2>Gruppenarbeit – Vorteile</h2> <ul> <li>Arbeitsteilung / Entlastung</li> <li>Parallelität</li> <li>performanter durch Spezialisierung</li> <li>Resilienz - Risikoverteilung</li> <li>Fehlererkennung</li> <li>Skalierbarkeit (ab 2 ist 3,4,5 leicht)</li> <li>Robustheit / Fehlertoleranz / Austauschbarkeit</li> <li>gemeinsame Nutzung von Ressourcen (Drucker, Papier, Räume)</li> <li>einige Aufgaben von Natur aus verteilt, z.B. geographische Trennung</li> </ul> </div></section> <section class="slide" id="gruppenarbeit--nachteile"><div><h2>Gruppenarbeit – Nachteile</h2> <ul> <li>erhöhte Komplexität durch Notwendigkeit von Kommunikation</li> <li>Fehleranfälligkeit und neue Fehlerklassen <ul> <li>Übertragungsfehler / Missverständnisse</li> <li>Timeout / Halteproblem</li> <li>Mehrarbeit wenn unsynchronisiert</li> </ul> </li> <li>Kompatibilität</li> <li>Unsicherheit</li> <li>Debugging / Fehlerfindung / unklare Schuldfrage (verschiedene kommunizierende Prozesse sind schwer kontrollierbar und teilweise auch schwer verständlich)</li> </ul> </div></section> <section class="slide shout" id="theoretische-kommunikations-grundlagen"><div><h2>Theoretische Kommunikations-grundlagen</h2> </div></section> <section class="slide" id="elemente-eines-kommunikationssystems"><div><h2>Elemente eines Kommunikationssystems</h2> <p><img src="comsys.png" alt="Elemente" /></p> <footer> <ol> <li>Generierung, Darstellung / Beschreibung <ul> <li>Die Quelle erzeugt die zu übertragenden Daten.</li> </ul> </li> <li>Kodierung <ul> <li>Der Sender transformiert/kodiert Daten und übergibt an ein Übertragungssystem</li> </ul> </li> <li>Übertragung / Übermittlung <ul> <li>Das Übertragungssystem/Kanal sogt für eine einwandfreie Weitergabe der Daten.</li> </ul> </li> <li>Dekodierung <ul> <li>Der Empfänger nimmt die Daten an, dekodiert sie und übergibt sie an das Datennutzer.</li> </ul> </li> <li>Zusammensetzung <ul> <li>Das Ziel/Nutzer nimmt die eingehenden Daten entgegen und verwertet sie</li> </ul> </li> </ol> <ul> <li>Shannons Kommunikationsmodell (1949): <ul> <li>Zwei Formen von Information: Meldung und Signal</li> <li>Zwei zentrale Aktivitäten: <ul> <li>Codierung der Meldung in ein Signal</li> <li>Decodierung des Signals, um die Meldung wieder herzustellen</li> </ul> </li> <li>Gemeinsamer Code-Vorrat nötig auf Sender- und Empfängerseite</li> </ul> </li> </ul> </footer> </div></section> <section class="slide" id="kommunikationsarten"><div><h2>Kommunikationsarten</h2> <div class="parts "> <div class="part"> <h3 id="richtung">Richtung</h3> <ul> <li>simplex / unidirektional</li> <li>(halbduplex)</li> <li>duplex / bidirektional</li> </ul> </div><div class="part"> <h3 id="übertragung">Übertragung</h3> <ul> <li>Unicast (1 zu 1)</li> <li>Multicasting (1 an einige)</li> <li>Bradocasting (1 an alle)</li> </ul> </div> </div> <footer> <ul> <li>simplex: eine straße, eine richtung</li> <li>halbduplex: eine straße, zwei richtungen (mit warten)</li> <li> <p>duplex: zwei straßen, zwei richtungen</p> </li> <li>später: <ul> <li>verbindungsorientiert / datenorientiert (TCP, UPD)</li> <li>sync / async</li> </ul> </li> </ul> </footer> <!-- ## Informationen - Informationen sind zielgerichtete Daten TODO: Grafik (Zeichen -> Daten -> Information -> Wissen) --> </div></section> <section class="slide" id="kommunikationsformen"><div><h2>Kommunikationsformen</h2> <ul> <li>Textkommunikation</li> <li>Datenkommunikation</li> <li>Sprachkommunikation (audio)</li> <li>Bild- und Videokommunikation</li> </ul> <footer> <ul> <li> <p>Unterscheidung nach der Form der zu übermittelnden Information</p> </li> <li>Textkommunikation <ul> <li>Austausch von Informationen (Symbole einer Sprache)</li> <li>Für das menschliche Verständnis bestimmt und verfügbar auf Papier oder Display</li> </ul> </li> <li>Datenkommunikation: <ul> <li>Austausch binärcodierter Informationen</li> <li>Komm.-Partner: Geräte zum Senden/Empfangen binärcodierter Daten</li> <li>Anwendungen, z.B. Teledienste, Büroanwendungen</li> </ul> </li> <li>Sprachkommunikation (audio) <ul> <li>Austausch auditiver Medien (Sprache, Musik, Geräusche)</li> <li>Analoge / digitale Übertragung</li> </ul> </li> <li>Bild- und Videokommunikation <ul> <li>Austausch visueller Medien</li> <li>Anwendungen, z.B Videokonferenz</li> </ul> </li> </ul> </footer> </div></section> <section class="slide" id="spezielles-kommunikationsmodell-für-computer--anpassungen"><div><h2>Spezielles Kommunikationsmodell für Computer – Anpassungen</h2> <ol> <li>Meldungen liegen in digitaler Form vor</li> <li>Es existiert ein zweiter Kommunikationskanal für Rückmeldungen</li> <li>Definition eines Protokolles, das festlegt, was für Meldungen in welcher Reihenfolge ausgetauscht werden</li> <li>Rekursive Struktur ein protokoll-erweiterter Kanal kann selbst als (virtueller) Kanal verwendet werden</li> </ol> <footer> <ul> <li>Damit können Abstraktionsebenen für Computerkommunikation gebildet werden</li> <li>z.B. elektrisches Signal -> bit -> Zeichen -> Datenblock -> Dokument</li> <li>Jede Ebene hat ihr eigenes Protokoll (Codierung etc)</li> </ul> </footer> </div></section> <section class="slide" id="verteiltes-system"><div><h2>Verteiltes System</h2> <p>Ein verteiltes System ist ein System,</p> <ul> <li>in dem sich Hardware und Softwarekomponenten auf vernetzten Computern befinden und</li> <li>nur über den Austausch von Nachrichten kommunizieren und ihre Aktionen koordinieren.</li> </ul> <footer> <ul> <li>Ein DS ist eine Sammlung von unabhängigen Computern das für seine Nutzer wie ein einziges, kohärentes System wirkt.</li> </ul> <p>Bekanntestes Beispiel: Das Internet</p> <ul> <li>Größtes zusammenhängendes verteiltes System</li> <li>Riesiger Zusammenschluss von heterogenen Computernetzwerken</li> <li>„Kleber<q> sind die standardisierten Internetprotokolle <ul> <li>IP (Schicht 3 Protokoll) mit IP Adressen</li> <li>TCP / UDP (Schicht 4 Protokoll)</li> </ul> </li> <li>Nutzer können die verschiedenen Dienste / Anwendungen nutzen, unabhängig davon wo sie sich gerade befinden</li> <li>Strukturierung durch Teilnetzwerke (Intranets) und Backbones</li> </ul> </footer> </div></section> <section class="slide" id="verteilte-anwendung"><div><h2>Verteilte Anwendung</h2> <p>Eine verteilte Anwendung ist eine Anwendung,</p> <ul> <li>die ein verteiltes System zur Lösung eines Anwendungsproblems nutzt und</li> <li>aus verschiedenen Komponenten besteht, die mit den Komponenten des verteilten Systems sowie mit den Anwendern kommunizieren.</li> </ul> <footer> <p>Beispiele:</p> <ul> <li>Einfache Internetanwendungen wie FTP, Telnet, Web</li> <li>Verteilte Informationssysteme wie <ul> <li>Flugbuchungssysteme</li> <li>Internetshops</li> </ul> </li> <li>Verteilte eingebettete Systeme wie <ul> <li>Steuerungssoftware Automobile</li> </ul> </li> <li>Verteilte mobile Anwendungen wie <ul> <li>verteilter Kalender im Handheld</li> </ul> </li> </ul> </footer> </div></section> <section class="slide" id="architekturmodelle"><div><h2>Architekturmodelle</h2> <p>Ein Architekturmodell beschreibt</p> <ul> <li>die Rollen einer Anwendungskomponente innerhalb der verteilten Anwendung</li> <li>die Beziehungen zwischen den Anwendungskomponenten</li> <li>Beispiele: <ul> <li>Client / Server</li> <li>Peer-to-Peer</li> </ul> </li> </ul> </div></section> <section class="slide" id="client--server"><div><h2>Client / Server</h2> <div class="parts "> <div class="part"> <h3 id="client-prozess">Client-Prozess</h3> <ul> <li>Kurzlebiger Prozess</li> <li>Lebt genau für die Dauer der Nutzung durch einen Anwender</li> <li>Agiert als Initiator einer IPC</li> </ul> </div><div class="part"> <h3 id="server-prozess">Server-Prozess</h3> <ul> <li>Langlebiger Prozess</li> <li>Lebt <q>unbegrenzt</q></li> <li>Agiert als Diensterbringer einer IPC</li> </ul> </div> </div> <footer> <ul> <li>Der Klassiker</li> <li>e.g. Bestellung in Restaurant (Kellner/in ist auch danach noch da)</li> </ul> </footer> </div></section> <section class="slide" id="client--server--varianten"><div><h2>Client / Server – Varianten</h2> <h3 id="mobiler-code">Mobiler Code</h3> <ul> <li>Servercode wandert auf Anfrage (in Form) zum Client.</li> <li>Die Ausführung des Codes erfolgt am Client</li> <li>Bekanntes Beispiel dieser Client / Server Variante sind Java Applets. <ul> <li>Applets als serverseitige Anwendungskomponenten wandern auf Anfrage zum Client.</li> <li>Der Browser als Client macht Aufrufe lokal auf dem Applet.</li> <li>Bei Bedarf reicht das Applet die Anfragen an den Server weiter.</li> </ul> </li> </ul> </div></section> <section class="slide" id="client--server--varianten-1"><div><h2>Client / Server – Varianten</h2> <h3 id="kooperierende-server">Kooperierende Server</h3> <ul> <li>Ein Verbund von Servern bearbeitet transparent einen Aufruf.</li> <li>Verwendung findet dieses Modell beispielsweise im Internet bei Domain-Name-Servern (DNS).</li> <li>DNS verwalten Abbildungstabellen von auf IP Adressen.</li> <li>Liegt lokal keine Abbildung vor, wird der Aufruf transparent an den DNS-Server weitergeleitet.</li> </ul> <footer> <ul> <li>Koop: Server arbeitet als Client</li> </ul> </footer> </div></section> <section class="slide" id="client--server--varianten-2"><div><h2>Client / Server – Varianten</h2> <h3 id="replizierte-server">Replizierte Server</h3> <ul> <li>Es werden Replikate von Serverprozesse zur Verfügung gestellt.</li> <li>Beispiele: <ul> <li>Transparente Replikate in Clustern zur Verbesserung der Performance und zur Ausfallsicherheit.</li> <li>öffentliche Replikate zur Lastverteilung (z.B. Mirror Server)</li> </ul> </li> </ul> </div></section> <section class="slide" id="client--server--varianten-3"><div><h2>Client / Server – Varianten</h2> <h3 id="proxy-modell">Proxy Modell</h3> <ul> <li>Ein Proxy dient als Zwischenspeicher für Aufrufergebnisse vom Server.</li> <li>Ziel ist die Verbesserung der Performance</li> <li>Beispiel: Proxy zum Zwischenspeichern von Webseiten</li> </ul> </div></section> <section class="slide" id="das-tier-modell"><div><h2>Das Tier-Modell</h2> <ul> <li>Tier: Prozessraum in einer verteilten Anwendung</li> <li>n-Tier-Architektur legt fest, wie viele unterschiedliche Client- und Server es innerhalb einer verteilten Anwendung gibt.</li> <li>Ein Prozessraum kann einem physikalischen Rechner entsprechen.</li> <li>Die Verwendung von n-Tier Architekturen ergibt vor allem für Informationssysteme Sinn: <ul> <li>Verteilung der Software zur Reduktion der</li> <li>Interaktive Mensch-Maschine Schnittstelle</li> <li>Datenzentriertes Vorgehen</li> </ul> </li> </ul> <footer> <ul> <li>Die Tier dient als Grundlage der n-Tier Architekturen.</li> <li>n-Tier-Architekturen sind eine Erweiterung / Verfeinerung des Client- Server Architekturmodells.</li> <li>Das <code class="language-plaintext highlighter-rouge">n</code> gibt an wie viele beteiligt sind.</li> <li><q>kann</q>: muss jedoch nicht!</li> <li>Mehrere Tiers können auf einem Rechner sein, aber später leichter, aufzuteilen</li> <li>Beispiele: {2,3,4}-Tier Architekturen</li> </ul> </footer> </div></section> <section class="slide" id="das-tier-modell-1"><div><h2>Das Tier-Modell</h2> <ul> <li>Typischen Aufgabenstellungen in einem Informationssystem: <ul> <li>Präsentation – Schnittstelle zum Anwender</li> <li>Anwendungslogik – Bearbeitung der Anfragen</li> <li>Datenhaltung – Speicherung der Daten in einer Datenbank</li> </ul> </li> <li>Im Tier-Modell wird jede dieser Aufgaben der Anwendungskomponente einer einzelnen Tiers zugeordnet.</li> <li>Die Art der Zuordnung macht den entscheidenden Unterschied der verschiedenen n-Tier Architekturen.</li> </ul> </div></section> <section class="slide" id="2-tier-architektur"><div><h2>2-Tier-Architektur</h2> <p><img src="2tier.png" alt="2 Tier" /></p> <footer> <ul> <li>Das Modell unterstützt 2 Tiers: Client- und Server-Tier</li> <li>Zuordnung von Aufgaben zu Tiers: <ul> <li>Präsentation – Client-Tier</li> <li>Anwendungslogik – Client-Tier und/oder Server-Tier</li> <li>Datenhaltung – Server-Tier</li> </ul> </li> <li>Die Verteilung der Anwendungslogik auf Client- und Server-Tier kann variieren.</li> </ul> </footer> </div></section> <section class="slide" id="thin--vs-fat-client-architekturen"><div><h2>Thin- vs Fat-Client-Architekturen</h2> <ul> <li>sind Verfeinerungsmodelle für die Zuordnung der Anwendungslogik</li> <li><strong>Ultra-Thin-Client</strong>: Die auf der Client-Tier sich auf reine Anzeige von Dialogen. der Anwendung ist ein Browser.</li> <li><strong>Thin-Client</strong>: Die auf der Client-Tier sich auf Anzeige von Dialogen und die Aufbereitung der Daten zur Anzeige.</li> <li><strong>Fat-Client</strong>: Teile der Anwendungslogik liegen zusammen mit der auf der Client-Tier.</li> </ul> <footer> <ul> <li>Ultra-Thin-Client-Architekturen sind ausschließlich bei 3- und mehr-Tier Architekturen möglich.</li> <li>Thin- und Fat-Client Architekturen sind bei allen n-Tier Architekturmodellen möglich.</li> <li> <p>In der Regel sind 2-Tier-Architekturen Fat-Client-Architekturen.</p> </li> <li>Pro Thin: Administration, Wartung, Support, Sicherheit (Virenschutz, Backup, Datendiebstahl), Ausfallsicherheit</li> <li>Pro Fat: Netzwerkunabhängigkeit, gegebenenfalls Performance</li> </ul> </footer> </div></section> <section class="slide" id="3-tier-architektur"><div><h2>3-Tier-Architektur</h2> <p><img src="3Tier.png" alt="3 Tier" /></p> <footer> <ul> <li>so war es Anfang der 2000er (und keiner sagt mehr Business Tier)</li> <li>konkrete Technologien z.B.: <ul> <li>Presentation: JSP</li> <li>Business: Java Server</li> <li>Data: Oracle Database</li> </ul> </li> <li>Mid 2000 kam dann mit Rails viel MVC</li> <li>heute <q>Rich Client</q> im Browser (Alternativen nennen)</li> </ul> </footer> </div></section> <section class="slide" id="peer-to-peer-p2p"><div><h2>Peer-to-Peer (P2P)</h2> <ul> <li>Gleichberechtigte Prozesse interagieren miteinander.</li> <li>Jeder Prozess kann sowohl als Client- als auch als Serverprozess auftreten.</li> <li>Peer Prozess <ul> <li>Kurzlebiger Prozess</li> <li>Lebt für die Dauer der Nutzung durch einen Anwender</li> <li>Agiert als Initiator und als Diensterbringer.</li> </ul> </li> <li>Ziel: von einem zentralen Server.</li> <li>Einsatz beispielsweise bei Tauschbörsen.</li> </ul> <footer> <ul> <li>Zwischen den Teilnehmern eines Netzwerks wertet ein peer-to-peer (P2P) (Computer)- Netzwerk unterschiedliche Verbindungen sowie die kumulativen Bandbreite aus; mehr als es konventionelle zentralisierte Ressourcen tun, in denen eine geringe Anzahl von Servern den Dienst oder die Applikation im Kern anbieten</li> <li>Ein reines P2P-Netzwerk nutzt gleichwertige Knoten, die parallel Server- und Client- für andere Netzwerkknoten bieten.</li> </ul> </footer> </div></section> <section class="slide" id="vergleich-clientserver-und-p2p"><div><h2>Vergleich Client/Server und P2P</h2> <ul> <li>Server werden zentral betrieben und administriert</li> <li>Ein Client besitzt geringere Ressourcen als der Server</li> <li>Die Ressourcen eines Peer sind zu denen anderer Teilnehmer</li> <li>P2P – Peers kommunizieren direkt mit anderen Peers und teilen Ressourcen</li> </ul> </div></section> <section class="slide" id="eigenschaften-p2p"><div><h2>Eigenschaften P2P</h2> <ul> <li>Skalierbarkeit – Teilen von Ressourcen</li> <li>Keine Notwendigkeit zur Einrichtung und Skalierung von Servern</li> <li>Jeder Nutzer bring eigene Ressourcen ein</li> <li>Zum Beispiel resistent gegen spikes (eine Menge von Nutzern, die alle zur gleichen Zeit eintreffen)</li> <li><q>Preiswert</q> – Keine Infrastruktur erforderlich</li> <li>Hohe Verfügbarkeit – Inhalt nahezu permanent verfügbar</li> <li>Jeder kann seinen eigenen Inhalt einbringen (kostenfrei)</li> <li>Selbstgemachter (home-made) Inhalt</li> <li>Illegaler Inhalt (P2P = Pirate-to-Pirate)</li> </ul> <footer> <ul> <li>1999: Napster</li> <li>2002: eMule, BitTorrent</li> <li>2003: Skype (nach Microsoft-Übernahme Wechsel zu Client-Server)</li> <li>bis 2014: Spotify</li> <li>heute verschwunden bzw. eher im Hintergrund, z.B. Cassandra (Datenbank)</li> </ul> </footer> </div></section> <section class="slide shout" id="technische-kommunikations-grundlagen"><div><h2>Technische Kommunikations-grundlagen</h2> </div></section> <section class="slide" id="iso-osi-referenzmodell"><div><h2>ISO OSI-Referenzmodell</h2> <p><img src="OSI.svg" alt="ISO OSI" /></p> <footer> <ol> <li>Schicht / Anwendung: Funktionen für Anwendungen sowie die Dateneingabe und -ausgabe.</li> <li>Schicht / Darstellung: Umwandlung der systemabhängigen Daten in ein unabhängiges Format.</li> <li>Schicht / Sitzung: Steuerung der Verbindungen und des Datenaustauschs.</li> <li>Schicht / Transport: Zuordnung der Datenpakete zu einer Anwendung.</li> <li>Schicht / Vermittlung: Routing der Datenpakete zum nächsten Knoten.</li> <li>Schicht / Sicherung: Segmentierung der Pakete in Frames und Hinzufügen von Prüfsummen.</li> <li>Schicht / Bitübertragung: Umwandlung der Bits in ein zum Medium passendes Signal und physikalische Übertragung.</li> </ol> <ul> <li>7/6/5: HTTP (Daten)</li> <li>4: TCP (Segmente), UDP (Datagramme) (Port)</li> <li>3: IP (Pakete) (IP-Adresse)</li> <li> <p>2: Ethernet (Frames)</p> </li> <li> <p>pro Schicht eigene Meta-Infos / Header / Overhead</p> </li> <li>viel Fehlerpotential, darum wird häufig eine Abstraktionseben eingezogen…</li> </ul> </footer> </div></section> <section class="slide" id="middleware"><div><h2>Middleware</h2> <p><img src="Middleware.svg" alt="Middleware" /></p> <footer> <ul> <li><q>Zwischenanwendung</q></li> <li>anwendungsneutrales Programm, das zwischen Anwendungen vermittelt, so dass die darunter liegende Komplexität verborgen wird (Transparenz)</li> </ul> </footer> </div></section> <section class="slide" id="middleware-1"><div><h2>Middleware</h2> <ul> <li>Ziel: Verbergen der Verteilungsaspekte vor der Anwendung</li> <li>Anwendungsaufrufe gehen an Middleware, diese kümmert sich um Weiterreichung über das Netzwerk (meist TCP/IP)</li> <li>Wir unterscheiden zwischen: <ul> <li>Kommunikationsorientierte Middleware</li> <li>Anwendungsorientierte Middleware</li> <li>Nachrichtenorientierte Middleware</li> </ul> </li> </ul> <footer> <ul> <li> <p>die verschiedenen Arten schauen wir uns später genauer an</p> </li> <li> <p>und was habe ich als EntwicklerIn nun davon? IPC!</p> </li> </ul> </footer> </div></section> <section class="slide" id="interprozesskommunikation-ipc"><div><h2>Interprozesskommunikation (IPC)</h2> <ul> <li>Komponenten einer verteilten Anwendung laufen in unterschiedlichen Prozessen</li> <li>Kommunikation basiert auf Nachrichtenaustausch in Form von Bitfolgen</li> <li>IPC ist ein Mechanismus zum Nachrichtenaustausch zwischen Prozessen</li> <li>Kommunikationsmodelle legen das Protokoll für den Ablauf der IPC fest</li> <li>Unterscheidung zwischen synchroner und asynchroner Kommunikation</li> </ul> <footer> <ul> <li>IPC bietet: <ul> <li>bietet Anwendungen sicheren Zugriff auf die Ressourcen des Rechners.</li> <li>Prozesse laufen gegeneinander isoliert.</li> <li>Damit zwei Prozesse Informationen austauschen können, müssen sie Interprozesskommunikation einsetzen.</li> <li>verschiedene technische Umsetzungen, z.B. Dateien und Pipes (lokal) oder Sockets (lokal und entfernt)</li> </ul> </li> </ul> </footer> </div></section> <section class="slide" id="synchrone-kommunikation"><div><h2>Synchrone Kommunikation</h2> <p><img src="sync.png" alt="Sync" class="right" /></p> <ul> <li>Sender-Prozess blockiert während Anfrageverarbeitung</li> <li>Eigenschaften: <ul> <li>Enge Kopplung zwischen Sender und Empfänger mit allen Vor- und Nachteilen</li> <li>Hohe Abhängigkeit besonders im Fehlerfall</li> </ul> </li> <li>Voraussetzung: <ul> <li>sichere und schnelle Netzverbindungen</li> <li>empfangender Prozess ist verfügbar</li> </ul> </li> </ul> </div></section> <section class="slide" id="asynchrone-kommunikation"><div><h2>Asynchrone Kommunikation</h2> <p><img src="async.png" alt="Async" class="right" /></p> <ul> <li>Sender ist nicht blockiert; Prozess kann nach dem Senden sofort weiterarbeiten</li> <li>Antworten sind optional (push / pull)</li> <li>Realisierung über Queues: <ul> <li>komplizierter zu implementieren, dafür effizienter</li> <li>lose Koppelung von Prozessen</li> <li>geringere Fehlerabhängigkeit</li> <li>Empfänger muss nicht empfangsbereit sein</li> </ul> </li> </ul> <footer> <ul> <li>Push: Empfänger sendet Ergebnis</li> <li>Pull: Sender holt sich Ergebnis</li> <li> <p>Queues = Warteschlangen</p> </li> <li>Beispiel: Bestellung in Restaurant</li> <li>Vergleich: Sync = Telefon, Async = E-Mail</li> </ul> </footer> </div></section> <section class="slide" id="kommunikationsorientierte-middleware"><div><h2>Kommunikationsorientierte Middleware</h2> <ul> <li>Schwerpunkt liegt in der Abstraktion von der Netzwerkprogrammierung</li> <li>Dienst als Kommunikationsinfrastruktur</li> <li>Konzentriert sich auf reine Kommunikationsaspekte</li> <li>Beispiele sind RPC, RMI, Web Service</li> </ul> </div></section> <section class="slide" id="anwendungsorientierte-middleware"><div><h2>Anwendungsorientierte Middleware</h2> <ul> <li>Setzt auf der kommunikationsorientierten Middleware auf</li> <li>Erweitert diese um Laufzeitumgebung + Dienste + Komponentenmodell</li> <li>Beispiele: CORBA, J2EE, .Net</li> </ul> </div></section> <section class="slide" id="nachrichtenorientierte-middleware"><div><h2>Nachrichtenorientierte Middleware</h2> <ul> <li>englisch <q>Message Oriented Middleware</q> (MOM)</li> <li>arbeitet nicht mit Methoden- oder Funktionsaufrufen, sondern über den Austausch von Nachrichten</li> <li>verschiedene Kommunikationsprotokolle: <ul> <li>Message Passing</li> <li>Message Queueing</li> <li>Publish & Subscribe</li> </ul> </li> </ul> <footer> <ul> <li>Nachrichten häufig in XML (oder JSON)</li> <li>Kommunikationsprotokolle: <ul> <li>Message Passing: Direkte Kommunikation zwischen Anwendungen</li> <li>Message Queueing: Indirekte Kommunikation über eine Warteschlange</li> <li>Publish & Subscribe: Herausgeber stellt dem Abonnenten Nachrichten zur Verfügung</li> </ul> </li> <li>Vorteile <ul> <li>Asynchrone/synchrone Kommunikation</li> <li>Server/Dienst muss nicht sofort verfügbar sein</li> <li>Message-Warteschlangen</li> <li>Meist schnellere Ausführung als Funktionsaufruf-basierte Programme</li> <li>Lose Kopplung von Server/Clients</li> <li>Mehr Toleranz für Änderungen der bestehenden Funktionen</li> <li>Verbesserte Verfügbarkeit der Systeme</li> <li>Parallele Verarbeitung von Nachrichten möglich</li> </ul> </li> <li>Nachteile <ul> <li>Ausfall der MOM legt alle angeschlossenen Systeme lahm</li> <li>Designen, Testen, Debuggen und Entwicklung der Bauteile sind für Synchron-Programmierer ungewohnt</li> </ul> </li> </ul> </footer> </div></section> <section class="slide" id="probleme"><div><h2>Probleme</h2> <ul> <li>Heterogenität: Hardware, Betriebssysteme, Programmiersprachen, Protokolle, Darstellung von Datentypen, Zeichenkodierungen</li> <li>Lösung <ul> <li>Installationen für verschiedenen Betriebssysteme</li> <li>SDKs für verschiedene Programmiersprachen</li> <li>Einigung auf einheitliche Datenformate</li> </ul> </li> </ul> </div></section> <section class="slide" id="datentransformation-marshalling--unmarshalling"><div><h2>Datentransformation (Marshalling / Unmarshalling)</h2> <ul> <li>Unter Marshalling versteht man die Transformation von Daten in ein Übertragungsformat.</li> <li>Unter Unmarshalling versteht man die Rücktransformation eines Zeichen- oder Bytestroms in Daten einer konkreten Programmiersprache.</li> </ul> <footer> <ul> <li><q>Umwandeln von strukturierten oder elementaren Daten in ein Format, das die Übermittlung an andere Prozesse oder Programme ermöglicht</q></li> <li>wir erinnern, <q>Elemente eines Kommunikationssystems</q>: Darstellung → Kodierung → Übertragung → Dekodierung → Zusammensetzung</li> <li>Verantwortlich für die Aufgabe sind Stubs und Skeletons einer Middleware.</li> </ul> </footer> <!-- ## Fehlerbehandlung --> </div></section> <section class="slide shout" id="technische-umsetzung"><div><h2>Technische Umsetzung</h2> </div></section> <section class="slide" id="sockets"><div><h2>Sockets</h2> <ul> <li>vom Betriebssystem bereitgestelltes Objekt, das als Kommunikationsendpunkt dient</li> <li>Ein Socket setzt sich aus IP und Port zusammen., z.B. 141.45.146.226:443 oder 127.0.0.1:3000</li> <li>Über diese Programmier-Schnittstelle (API) können Applikationen verteilt über das Netz programmiert werden</li> </ul> <footer> <ul> <li>OS verwaltet Sockets, Programm fragt Socket von OS an</li> <li>3 Phasen: <ul> <li>Initialisierungsphase: Verbindungsaufbau</li> <li>Lese- und Schreibphase: Symmetrische Kommunikation</li> <li>Aufräumphase: Freigabe von Ressourcen</li> </ul> </li> </ul> </footer> </div></section> <section class="slide" id="remote-procedure-call-rpc"><div><h2>Remote Procedure Call (RPC)</h2> <ul> <li>Technik zum Aufruf von Funktionen (mit Parametern) auf anderen Prozessen</li> <li>Entkopplung von Client und Server durch Schnittstellendefinition</li> <li>Einführung von Stub und Skeleton als Zugriffsschnittstelle auf Client- und Serverseite <ul> <li>werden aus der Schnittstellenspezifikation generiert</li> <li>sind verantwortlich für Marshalling und Unmarshalling</li> <li>ermöglichen die Zusicherung von Zugriffs- und Ortstransparenz</li> </ul> </li> <li>Fehleranfällig</li> </ul> <footer> <ul> <li>Im Fehlerfall (z.B. Server-Crash) kann der Client nicht wissen, wann der Fehler auftrat</li> <li>Wenn RPC über UDP, dann folgende Fehlersemantiken: <ul> <li><code class="language-plaintext highlighter-rouge">maybe</code>: ¯_(ツ)_/¯</li> <li><code class="language-plaintext highlighter-rouge">at-least-once</code>: Wiederholung bei Fehler (nur gut wenn idempotent)</li> <li><code class="language-plaintext highlighter-rouge">at-most-once</code>: Höchstens einmal, Aufruf-Duplikate werden gefiltert, entweder klappt oder Fehler</li> <li><code class="language-plaintext highlighter-rouge">exactly-once</code>: Aufruf-Duplikate werden gefiltert</li> </ul> </li> </ul> </footer> </div></section> <section class="slide" id="remote-method-invocation-rmi"><div><h2>Remote Method Invocation (RMI)</h2> <ul> <li>Java-eigene Art des Remote Procedure Call</li> <li>Aufruf von Methoden auf entferntem Objekt</li> </ul> <footer> <ul> <li><q>entfernt</q> = andere JVM</li> </ul> </footer> </div></section> <section class="slide" id="links-und-props"><div><h2>Links und Props</h2> <ul> <li>Viele Folieninhalte von <a href="http://wi.f4.htw-berlin.de/users/hemling/Vorlesungen/SS2008/315_DL_GKT_SS2008.htm">Prof. Hemling</a></li> </ul> </div></section> <div class="progress"><div></div></div> <script src="/assets/scripts/shower.js"></script> <script src="/assets/scripts/shower-notes.js"></script> <script src="/assets/scripts/editor.js"></script> <script> document.querySelectorAll('[bg]').forEach(el => el.style.backgroundImage = `url(${el.attributes.bg.value})`); </script> </body> </html>