VL 5

Middleware ist eine Software-Schicht, die die Kommunikation und Datenverwaltung zwischen verschiedenen Anwendungen oder Systemen ermöglicht.

Sie stellt Funktionen wie Sicherheit, Nachrichtenvermittlung und Transaktionsmanagement bereit, um die Integration und Interoperabilität zu erleichtern.

Middleware stellt Bausteine für den Aufbau von SoftwareKomponenten bereit, die in einem verteilten System zusammenarbeiten können

- Sun RPC: entfernter Prozedurablauf

- DCE (Distributed Computing Environment): Dienste und Werkzeuge für verteilte Datenverarbeitung

- Java RMI (Remote Method Invocation)

Beim RPC werden zwei Stummel-Prozeduren (Stubs) erzeugt, eine für das Ein-/Auspacken und eine für das Senden und Empfangen.

1. Der Klient findet den Server nicht.

2. Die Auftragsnachricht Klient/Server geht verloren.

3. Die Antwortnachricht Server/Klient geht verloren.

4. Der Server stürzt nach Auftragserhalt ab.

5. Der Klient stürzt nach Auftragsvergabe ab.

1.Client ruft Client-stub auf, der den Namen der fernen Prozedur trägt

2. Client-stub benachrichtigt Server-stub (und blockiert)

3. Server-stub ruft eigentliche Prozedur auf und schickt Ergebnis zurück

4. Client-stub wird deblockiert, Ergebnis wird ausgepackt und der Client stub terminiert mit fernem Ergebnis als Ergebnis seines Aufrufs

Prozesse oder Aufträge, die nach einem Systemfehler, einem Serverabsturz oder einem Client-Reboot "verwaist" sind, also nicht mehr korrekt abgeschlossen oder zu Ende geführt werden können.

1. Löschung (Extermination): Nach reboot werden alle offenen Aufträge gelöscht -> jedoch nicht verlässlich, deshalb keine relevante Methode

2. Reinkarnation (Reincarnation): Durch Epocheneinteilung startet jeder Clientreboot in einer neuen Epoche, wobei Prozesse alter Epochen beendet werden oder deren Resultate veraltete Epochenstempel tragen

3. Freundliche Reinkarnation (gentle Reincarnation): Bei Epochenstart frägt Server, ob “Eltern” des Auftrags noch leben, und beendet diese nur, falls dies nicht der Fall ist

4. Verfall (Expiration): Aufträge werden mit Timern versehen, die nur durch Meldung der Eltern verlängert werden können. Laufen diese ab, so wird der Auftrag(vorzeitig) beendet. Problem: Man muss einen sinnvollen Wert für diesen Timer finden

1.At least once semantics. Das RPC-System wiederholt den Auftrag so lange, bis er quittiert wurde

2.At most once semantics. Das RPC-System bricht nach Timeout ab mit Fehlermeldung

3.Keine Garantie. Das RPC-System gibt irgendwann auf. Der Auftrag kann nicht oder auch mehrmals bearbeitet worden sein

Ideal wäre natürlich exactly one semantics, was jedoch nicht realistisch realisierbar ist. (Semantics ist quasi eine volle Anfrage-+Antwortschleife)

1. Der Klient findet den Server nicht -> No Server

2. Die Auftragsnachricht Klient/Server geht verloren -> Lost Request Nach Ablauf eines Timers wird der Auftrag erneut Versand, wobei durch Kennzeichnung der Aufträge als Original und Kopie eine mehrfache Bearbeitung des Auftrags verhindert werden kann

3. Die Antwortnachricht Server/Klient geht verloren -> Lost Reply Erneut müssen Buchungsaufträge als Originale und Kopien gekennzeichnet werden. Manche Aufträge, wie etwa Datumsauslesung können beliebig oft wiederholt werden, eine z.B. Geldtransaktion jedoch nicht

4. Der Server stürzt nach Auftragserhalt ab -> Server crashes Serverabstürze fallen in Kategorie 1, wobei der Serverabsturz vor Auftragsbearbeitung durch reboot den Auftrag wiederholen kann, jedoch nicht mehr unbedingt, wenn er nach Auftragsbearbeitung abgestürzt ist

5. Der Klient stürzt nach Auftragsvergabe ab -> Client crashes

Dabei ist es egal, ob der Client vor Auftragsvergabe oder nach Auftragsbestätigung abstürzt, jedoch entstehen bei Absturz während der Auftragsverarbeitung Waisen