3 - J (suc2)

UDP-Sockets sind nicht verbindungsorientiert

Daten werden in Pakete geschrieben

Datenpakete könne maximal 8 KB gross sein (Header- und Nutzdaten zusammen)

Grössere Nachrichten müssen in der Anwendung segmentiert bzw. reassembliert werden

Die Ankunft von Datenpaketen wird nicht bestätigt

Es kann passieren, dass manche Datenpakete nicht ans Ziel kommen Folie

Multicast-Sockets

Vorteile

sehr gute Performance

Protokolle können frei nach Bedarf implementiert werden, wodurch Anpassungen bzw. Optimierungen möglich sind

Nachteile

Sockets eignen sich für reine Datenübertragung

Sockets sind nur die Schnittstelle zur Transportschicht

Bieten keine Unterstützung für Kommunikationssteuerung und Datendarstellung

Protokolle müssen auf der Anwendungsebene implementiert werden um Kommunikationspartner zu finden und Austausch von Nachrichten zu steuern

Eigenschaften der Transportschicht sind zu berücksichtigen (TCP/ UDP)

Programmierung relativ aufwendig und fehleranfällig

aufwendig und fehleranfällig

es müssen einige technische Aspekte berücksichtigt werden, die mit eigentlichem Anwendungsproblem nichts oder nur wenig zu tun haben  

Dies kann zu einem erheblichen Aufwand bei der Entwicklung einer Anwendung führen

Unter Middleware ist die Software zu verstehen, die zwischen der verteilten Anwendung und der darunterliegenden Schicht steht umd "vermittelt"

die Interaktion zwischen Anwendungskomponenten zu erleichtern, und  

die Komplexität der vernetzten Systemumgebung zu maskieren

wird für den Anwendungsentwickler die Umsetzung der Kommunikation einfacher, wobei

alle Aspekte der Netzwerkprogrammierung so weit wie möglich (und sinnvoll) von der verteilten Anwendung verborgen werden  

Der Anwendungsentwickler kann sich auf die Lösung des eigentlichen Anwendungsproblems konzentrieren

bild

abschirmung von netzwerksachen (protokollen, übertragungsfehler, ereignissen..)

Ortstranzparenz (server und client haben das gefühl lokal zu kommunizieren)

Kommunikationsprotokolle:(ist sache der middleware...)

Computer-Hardware (unterschiede neutralisieren)

Betriebssysteme (unabhängig)

Programmiersprachen (unabhängig)

Kommunikationsorientierte Middleware KOM

Anwendungsorientierte Middleware AOM

KOM konzentriert sich auf die Bereitstellung einer geeigneten Kommunikationsinfrastruktur für Komponenten einer verteilten Anwendung

Aufgaben: Kommunikation

Marshalling und Unmarshalling

Fehlerbehandlung bzw. Fehlerbehebung

Heterogenität in der Hardware:

Heterogenität der Programmiersprachen

Fehlerbehandlung bei der Übertragung

Das Programmiermodell ist die Sicht des Entwicklers auf die Architektur definiert, wie die Architektur zur Entwicklung der Anwendung zu verwenden ist

Es wird zwischen drei Programmiermodelle unterschieden:

Entfernte Prozeduraufrufe (RPC)

Entfernte Methodenaufrufe (CORBA, RMI)

Das nachrichtenorientierte Modell (MOM)

AOM stellt eine Erweiterung der KOM dar, die n eben reiner Kommunikation eine Reihe zusätzlicher Dienste der verteilten Anwendung zur Verfügung stellt

Das Ziel der Ressourcenverwaltung ist die Verbesserung von Performance, Skalierbarkeit und Verfügbarkeit von Anwendungen

In der Regel werden verteilte Anwendungen von mehreren Anwender parallel benutzt

Um diese Parallelität zu gewährleisten werden die Aufrufe isoliert in separaten, nebenläufigen Threads oder Prozessen abgearbeitet

Ein Lösungsansatz ist die Verwaltung einer Anzahl von Verbindungen (auf Vorrat) in einem Pool

Je nach Verfügbarkeitsanforderungen, sehen die Lösungen unterschiedlich aus (Redundanz)

Zugriffskontrolle (Authentifizierung), womit die Sicherstellung der Identität des Benutzers gemeint ist und

Vergabe von Zugriffsrechten (Autorisierung), womit die Benutzungsrechte für bestimmte Dienste an die Benutzer vergeben werden

Namensdienst

Sitzungsverwaltung (Sessionhandling)

Transaktionsverwaltung (Datenkonsistenz, ACID)

Persistenz

Object Request Broker (ORB)

 Application Server (AS)

Middleware-Plattformen

sind Objekte des Betriebssystems

ermöglichen einer Anwendung den sicheren Zugriff auf die Ressourcen des Betriebssystems

laufen in eigenem Speicherbereichen und sind dadurch voneinander isoliert

Für den Austausch von Daten zwischen Prozessen ist eine Interprozesskommunikation nötig

IPC basiert auf dem Austausch von Nachrichten und Daten zwischen Prozessen:

IPC kann unterschiedlich umgesetzt werden

über Dateien

über Pipes (nur lokal)

über Sockets (sowohl lokal als auch entfernt)

mit Hilfe einer Middleware  

Kommunikationsmodel legt das Protokoll für den Ablauf der Kommunikation zwischen Prozessen (IPC) fest

synchroner Kommunikation und

asynchroner Kommunikation

Vorteile

Eher einfacher zum Implementieren

Synchronisation beim Zugriff auf gemeinsame Ressourcen gleich erledigt

Nachteile

zum Teil ineffizient (das Warten)

braucht sichere und schnelle Netzwerkverbindung

Empfängerprozess muss verfügbar sein

enge Kopplung zwischen Sender und Empfänger

Vorteile

lose Kopplung von Prozessen geringere Fehlerabhängigkeit der Empfänger muss nicht empfangsbereit sein effizienter (kein Warten)

Nachteile

aufwendiger bzw. komplizierter in der Implementierung (Warteschlangen) komplizierte Protokolle nicht immer sinnvoll

unterschiedliche Hardwarearchitekturen

unterschiedliche Betriebssysteme (Plattformen)

unterschiedliche Programmiersprachen

Damit die Komponenten des verteilten Systems miteinander kommunizieren können, müssen sie alle ein gemeinsames Format für Daten benutzen

Unter marshalling versteht man die Transformation einer beliebigen Nachricht in eine übertragbare Nachricht, wobei

die Datenstruktur in eine zusammenhängende Nachricht "planiert" wird und

die zu sendenden Daten aus dem lokalen in das gemeinsame Format übersetzt werden

Daraus resultiert ein Strom von bytes, welcher übertragen werden kann: eine übertragbare Nachricht

Auf der Seite des Empfängers müssen die empfangenen Daten aus dem gemeinsamen Format in das lokale Format des Empfängers übersetzt werden

Dieser Prozess wird unmarshalling genannt

Unmarshalling wird immer auf der Seite des Empfängers ausgeführt

Vorteile:

direkte Kontrolle aller Transportparameter grössere Flexibilität bei der Entwicklung neuer Protokolle bessere Performance

Nachteile

die Datenrepräsentation wenig komfortable Entwicklung von Anwendungen

Middleware ist eine zusätzliche Schicht, die sich zwischen Transportschicht (TCP/UDP) und Anwendung befindet

Vorteile

Bequeme Entwicklung von Anwendungen Lösung des Datenrepräsentationsproblems Evtl. weitere Dienste „von Haus aus“ verfügbar

Nachteile

Ein (unter Umständen grosser) Overhead muss in Kauf genommen werden Schlechtere Performance im Vergleich zu Socket-Programmierung

Aufruf einer Prozedur, welche sich im gleichen Speicherraum (Prozess) befindet

Keine Interprozesskommunikation mit LPC möglich

Vorteile:

Bessere Performance, da alle Prozeduren im gleichen Prozess bzw. Speicherraum

Zuverlässige Kommunikation

Einfachere Parameterübergabe, da lokaler Stack für alle Prozeduren gemeinsam und verfügbar

Einfacher Zugriff auf gemeinsame Daten, da alle Prozessdaten gemeinsam

Nachteile:

Keine Interprozesskommunikation möglich Folie

RPC steht für den "entfernten Aufruf von Prozeduren„

Mit "entfernt" ist eine Prozedur gemeint, welche

in einem anderen Prozess ausgeführt wird bzw.

sich in einem anderen Speicherraum befindet

Stellt eine Art der Interprozesskommunikation

Die kommunikationswillige Prozesse können

auf dem gleichen System oder

auf unterschiedlichen Systemen ausgeführt werden 

LPC ist einfacher zu implementieren, da sich die ganze Kommunikation (Nachrichtenaustausch) in einem gleichen Speicherraum (gleicher Prozess) abspielt

RPC ist weniger performant Kommunikation erfolgt in Form von Nachrichten, welche von einem zu anderem Prozess übertragen werden Parameter, welche übergeben werden müssen, müssen in die Nachricht passend verpackt werden

RPC ist komplexer in der Implementierung, da zusätzliche Protokolle für das Senden von Nachrichten benötigt

Wie wird eine entfernte Prozedur aufgerufen (mit allem, was dazu gehört: Parameterliste, Rückgabewert)?

Wie werden Fehlersituationen (Exceptions) behandelt?

Die Struktur der Anfrage- bzw. Anwort-Nachricht muss "abgesprochen" werden und darf danach nicht ohne Rücksprache mit der "Gegenseite" geändert werden

Damit soll sichergestellt werden, dass die Kommunikation zwischen beteiligten Komponenten exakt und ohne Missverständnisse realisiert werden kann.

Die Rede ist von Request- und Reply-Protokoll

definiert, wie die Anfrage-Nachricht aufgebaut werden muss

enthält alle für den Aufruf der entferenten Operation relevanten Informationen (den Namen der Methode und die Parmeterliste) in einer passenden Form

hängt im Aufbau (Struktur) von der Operation ab, die aufgerufen werden soll

definiert, wie die Antwort-Nachricht aufgebaut werden soll

enthält alle für die Antwort relevanten Informationen in einer passenden Form:

den Rückgabewert, der von der aufgerufenen Operation retourniert wird

die Informationen über die Ausnahme, die evtl. geworfen werden könnte

ist im Aufbau vom Rückgabewert und Ausnahme, die geworfen werden könnte, abhängig

Pro Operation, die als entfernte Operation aufgerufen werden soll, muss je ein Request- und Reply-Protokoll definiert werden

Erst nach dem die Request- und Reply-Protokoll definiert sind, kann mit der Implementierung der Kommunikation gestartet werden

eine Art der Interprozesskommunikation gemeint, mit der Aufruf von Operationen (Prozeduren) realisiert wird, die sich in einem anderen Prozess befinden

da die aufgerufene Prozeduren nicht im eigenen Prozess (Speicherraum) ausgeführt werden, reden wir von einem entfernten Prozeduraufruf