###### tags: `fh` `VS`
# Verteilte Systeme 1
[TOC]
## GRUN: Grundlagen und Konzepte
Unterlagen:
* Kapitel 1 und 2 bis incl 2.2
* Studienbrief
### 1. Geben Sie eine charakterisierende Definition für "Verteiltes System" an. Nennen Sie die wichtigsten Design-Ziele bzw. charakteristischen Eigenschaften von Verteilten Systemen.
Ein Verteiltes System ist ein **Verbund von unabhängigen Computern**, welche als ein einziges **zusammengehöriges System erscheinen** und **irgendwie untereinander kommunizieren und koordinieren**.

Ohne Koordinierung -> vernetztes System.

+ Verteiltes System besteht aus mehreren autonomen Komponenten
+ Komponenten sind miteinander verbunden
+ kompnenten arbeiten zusammen
+ durch die Zusammenarbeit wirkt das Distributed System wie ein einzelnes System
+ einfache Erweiterbarkeit/Skalierbarkeit

Zusammenarbeit untersch. Komponenten
Um heterogene Comp & NW zu unterstützen und trotzdem wie 1 System zu wirken wird eine Middleware (Softwareschicht) verwendet:
+ zw. OS und User

**Design Ziele**
+ **Performange**
+ eg durch Load Balancing od. Aufgabenvertelung auf mehrere Rechner
+ Transparancy
+ user bekommt nicht mit dass Ressourcen über ein NW verteilt sind
+ **Availablity/Dependability**
+ bei Ausfall od. Reperatur einzelner Komponenten funktioniert das System trotzdem unverändert. Hand in Hand mit fault tolerance
+ Fault Tolerance
+ Security
+ Openness
+ Ein VS wird als "open distributed system" bezeichnet wenn es seine Services nach einem Standard anbietet welches **Syntax** und **Semantik** vom Service beschreibt.
+ Resource Sharing
+ Gleichzeitiges Nutzen von Ressourcen (mehrere Nutzer) soll möglich sein.

**Charakteristische Eigenschaften**
* **Resource sharing:** Verteilte Systeme erlauben optimale und gemeinsame Nutzung von Daten
* **Transparency:** Das System soll möglichst uneinsichtig sein
* **Openness:** Betrifft die Möglichkeit der Erweiterung
* **Scalability:** Das System muss wachsen können
* **Fault tolerance/Availability:** Steigern der Verfügbarkeit mittels Redundanz oder Replikation.
* **Concurrency:** Trotz Parallälität, muss die Serialisierbarkeit von Transaktionen garantiert sein, um ein konsistentes Verhalten zu gewährleisten.

**Zusammenarbeit unterschiedlicher Komponenten**
Um heterogene Computer & NW zu unterstützen und trotzdem wie 1 System zu wirken wird eine Middleware verwendet:
* zw. OS Layer und User Application Layer
* Durch die Middleware hat jede Application das selbe Interface zur Kommunikation
* Hardware und OS Unterschiede werden vor den Applikationen verborgen


WWW ist aus sicht des ENDUSERS ein VS.

### 2. Erläutern Sie die typischen Fallstricke beim Entwurf verteilter Systeme.
**Annahmen die man NICHT treffen darf:**
* ein Netzwerk ist **ZUVERLÄSSIG** (Keine Systemausfülle und immer erreichbar)
* ein Netzwerk ist **SICHER** (Keiner wird jemals unbefugt in mein Netzwerk eindringen)
* ein Netzwerk ist **HOMOGEN** (Überall die selben Voraussetzungen, z.B. überall die selbe Bandbreite)
* die **TOPOLOGIE ÄNDERT SICH NICHT** (Es kommen keine Geräte hinzu)
* **LATENZ IST NULL**
* **UNENDLICH BANDBREITE**
* **ÜBERTRAGUNGSKOSTEN SIND 0** router und administartoren kosten etwas
* es gibt **NUR EINEN ADMINISTRATOR**

Allgemeiner Natur
* components which are interacting ofthen with each other should be next to each other
* some components only run on specific systems
* smaller components give higher flexibilty
### 3. Beschreiben Sie die standardisierten Arten von Transparenz und erklären Sie den Zusammenhang zischen den einzelnen Transparenz-Definitionen.
+ charakteristische Eigenschaft verteilter System (oder auch "generisches Design Req.")
+ Verbergen der Verteilung der Komponenten verteilter Systeme

Def.: Die **VERTEILUNG** der Prozesse oder Resourcen eines Systems soll vom Benutzer **VERBORGEN** werden. Ein VS, das für den Benutzer **WIE EIN EINZIGER COMPUTER** aussieht, nennt man transparent.

Arten von Transparenzen:
+ Migration Transparency
+ Relocation Transparency
+ Relocation Transparency
+ Replication Transparency
+ Concurrency Transparency
+ Scaling Transparency
+ Performance Transparency
+ Failure Transparency

**Zugriffstransparenz(access)**
Unterschiede der Computerarchitekturen sollen verborgen sein. Dies sieht vor, dass die Schnittstellen zur Anforderung eines Dienstes für die Kommunikation zwischen Komponenten eines Rechners dieselbe wie zwischen verschiedenen Rechnern ist.

**Ortstransparenz(Location)**
Die Benutzer sollen nicht feststellen können, wo sich eine Ressource phyisch im System befindet. Die Namensgebung spielt eine wichtige Rolle fün die Ortstransparenz. Insbesondere lässt sie sich erreichen, wenn Ressourcen nur logische Namen zugewiesen werden, also Namen in denen der Ort einer Ressource nicht insgeheim verschlüsselt ist. z.B in einer URL. Welche uns keinen Hinweis über den ort des Hauptservers gibt oder ob die Datei index.html immer an ihrem aktuellen Port war oder ob sie erst kürzlich dorthin verschoben wurde. Fehlersuche wird schwierig, wenn ich nicht weiß wo die Dinge liegen.

**Migrationstransparenz**
Verteilte Systeme, in denen das Verschieben einer Ressource keinen Einfluss darauf hat, wie auf diese Reccource zugegriffen werden kann.

**Relokationstranzparenz**
Ressourcen können an einen neuen Ort verschoben werde, während ein Zugriff darauf erfolgt, ohne dass der Benutzer oder die Anwendung etwas davon bemerkt. In diesen Fälle unterstützt das System die sogenannte Relokationstransparenz. Bsp.: Benutzer können ihren Laptop ungestört benutzen, während sie sich zwischen verschiedenen Ort hin und her bewegen ohne dabei jemals (temporär) die Verbindung zu verlieren.

**Replikationstransparenz**
Spielt eine sehr wichtige Rolle in VS. Beispielsweise kann die Verfügbarkeit oder die Leistung einer Reccource verbessert werden, indem eine Kopie dort angelegt wird, wo im weiteren Vrlauf darauf zugegriffen wird. Die Replikationstransparenz verbirgt die Tatsache, dass es mehrere Kopien einer Ressource gibt, um dies zu ermöglichen müssen alle Replikate den selbsen namen tragen. Folglich sollte ein System, welches Replikationstransparenz unterstützt auch die Ortstransparenz unterstützen, da es ansonsten nicht möglich ist auf Replikate an verschiedenen Orten zu verweisen.

**Nebenläufigkeitstransparenz**
Die gemeinsame Nutzung von Ressourcen ist ein wichtiges Ziel in einem verteilten System. In vielen Fällen erfolgt die Nutzung kooperativ, wie beispielsweise die Kommunikation. Es gibt aber auch konkurrierende gemeinsame Nutzung von Ressourcen, dies erfolgt wenn zwei voneinander unabhängige Benutzer auf die selbe Tabelle einer gemeinsam genutzten Datenbank zugreifen. In solchen Fällen ist es wichtig, dass die Benutzer/Anwendungen nicht merken, dass der jeweils andere die selbe Ressource verwendet. Wichtig ist, dass die gemeinsame Nutzung einer Ressource, diese in einem konsistenten Zustand hinterlässt, dies lässt sich durch Sperrmechanismen realisieren, welche dem Benutzer nur einen exklusiven nacheinander ausgeführten Zugriff ermöglichen.

**Fehlertransparenz**
Der Benutzter merkt nicht, dass eine Ressource nicht mehr korrekt arbeitet und dass das System den Fehler anschließend behebt. Die Schwierigkeit bei dieser Art von transparenz besteht darin, dass es schwer ist zwischen einer angestürzten und einer quälend langsamen Ressource zu unterscheiden. Bsp.: wir kontaktrieren einen beschäftigten Webserver, irgendwann wird der Browser ein Timeout auslösen und melden, dass die Website nicht verfügbar ist. Hier kann der Benutzer nicht unterscheiden ob der Servern nicht läugt oder überlastet ist.

** Scaling Transparency**
Bedeutet die Erweiterung des Systems, um steigendem Bedarf zu genügen, ohne dass es für den Benutzer und Designer notwendig ist zu wissen, wie die Skalierung erfolgt. Scaling Transparency wird unterstützt durch Migration Transparency und Replication Transparency.


### 4. Was versteht man unter "Openness"?
Ein verteiltes System ist eine offenes verteiltes Systen, wenn **neue Dienste zu den bereits existierenden Diensten hinzugefügt werden können**, ohne letztere zu Unterbrechen bzw. Dienste zu duplizieren. Am wichtigsten sind dabei natürlich die Interfaces und ein einheitliches Kommunikationsmodell zwischen den Interfaces.

Ein "offenes verteiltes System" bietet **Dienste nach Standardregeln** an, ide die Syntax und die Semantik dieser Dienste beschreiben. In Computernetzwerken steuern diese Standardregeln das Format, den Inhalt und die Bedeutung gesendeter und empfangener Nachrichten. **Diese Regeln werden in Protokollen formalisiert**. Diese **Dienste werden generell durch Schnittstellen (Interfaces) spezifiziert**, die of **in einer Interface Definition Language (IDL) beschrieben** sind (erfassen fast immer nur die Syntax von Diensten). Spezifiziert wird Name der verfügbaren Funktionen zusammen mit den Typen der Parameter, Rückgabewerten, mögliche Ausnahmen, die gelöscht werden können usw.

Wenn eine **Schnittstellendefinition** richtig spezifiziert ist, erlaubt sie beliebigen Prozessen, die einen bestimmte Schnittstelle benötigen, die Kommunikation mit einem anderen Prozess, der diese Schnittstelle bereitstellt. Außerdem erlaubt sie es zwei voneinander unabhängigen Gruppen, völlig unterschiedliche Implementierungen dieser Schnittstelle vorzunehmen, was zu zwei getrennten verteilten Systemen führt, die auf genau die selbe Weise funktionieren.

**Gute Spezifikationen sind vollständig**(alles, was für eine Imlementierung erforderlich ist, wurde spezifiziert)**und neutral**(Spezifikationen schreiben nicht vor, wie eine Implementierung aussehen soll).

**Vollständigkeit** ist wichtig für **Interoperabilität** (beschreibt den Grad bis zu dem zwei Implementierungen von Systemen/Komponenten verschiedener Hersteller zusammenarbeiten können, indem sie sich lediglich auf die Dienste der anderen verlasse, die nach einem gemeinsamen Standard spezifiziert sind).

**Neutralität** ist wichtig für **Portabilität** (beschreibt, in welchem Ausmaß eine Anwendung, die für VS A entwicklet wurde, ohne Veränderungen auf VS B ausgeführt werden kann, das dieselben Schnittstellen wie A implementiert).

Außerdem sollte ein offenes VS auch **erweiterbar**sein (Hinzufügen/Ersetzen von Komponenten, ohne dass die vorhandenen beeinträchtigt werden) was zu einer gewissen **Flexibilität** führt.

Um in einem offenen VS **Flexibilität** zu erziehlen, sollte es aus kleinen einfach austauschbaren/anpassbaren Komponenten angeordnet sein, so dass nicht nur Definitionen der Schnittstellen der obersten Ebene die von Benutzern/Anwendungen gesehen werden, sondern auch für Schnittstellen zu den internen Bestandteilen des Systems bereitgestellt werden sollten, und außerdem beschrieben wird, wie diese Bestandteile zusammenarbeiten.

Nötig ist Trennung von **Policy** und **Mechanismus**! Beim Web-Caching sollte ein Browser im Idealfall beispielsweise nur Funktionen zum Speichern von Dokus bereitstellen, und es gleichzeitig den Benutzern gestatten, selbst zu entscheiden welche Dokus wie lange gespeichert werden sollen.

### 5. Erläutern Sie Probleme und Lösungsansätze für "Scalability".
**Definition** Fähighkeit des Systems bei **wachsenden Anforderungen** noch **einsatzfähig** zu sein. Kann in mind. 3 **unterschielich definitionen gemessen** werden:
* **Größe/Ausmaß** (Zusätzliche Benutzer oder Ressourcen könne hinzugefügt werden)
* **Geographisch** (Benutzer und Ressourcen dürfen topologisch weit auseinander liegen)
* **Administrativ** (Einfach verwaltbar selbst über unabhängige domains erstreckt)

**Probleme**
**1.Größe** Werden mehrer Benutzer oder Ressourcen unterstützt, werden wir häufig mit den Einschränkungen zentralisierter Dienste, Daten und Algorithmen konfrontiert:
* **Zentrale Services**, z.B. ein einziger Server für alle Benutzer (oft auch für die Sicherheit erforderlich!)
* **Zentral verwaltete Daten**, z.B. ein einziges Online-Telefonbuch
* **Zentral ablaufende Algorithmen**, z.B. Routing durchführen

**Geographisch**
Verteilte Systeme die für LANs entwickelt wurde, basieren auf synchroner Kommunikation. Ein Client blockiert bis Antwort zurück gesehndet wird, was problematisch in **WANs** ist (zu **langsam**).Kommunikation in WANs ist inhärent **unzuverlässig** und so gut wie immer Point-to-Point, LANs hingegen bieten hoch zuverlässige Kommunikation und unterstützen Broadcasting. Geographische Skalierbarkeit hängt start mit den Problemen zentralisierter Lösungen zusammen, die auch die Größenskalierbarkeit behindern.

**Administrativ**
Schwierige Frage wie ein verteiltes System über mehrere voneinander unabhängige administrative Domänen skalierbar werden kann. Ein Problem sind die **widersprüchliche Strategien zur Benutztun** (und Bezahlung) von **Ressourcen, Verwaltung und Sicherheit.**

**Lösungsansätze**
1. Verbergen der Latenzzeiten: (wichtig für geographische Skalierbarkeit)
* **Asynchrone Kommunikation** ( Abarbeiten von Aufgaben, während man auf eine Antwort wartet)
* **Kommunikation reduzieren** (z.B. überprüfen von forms schon beim Client anstelle am Server)
2. **Verteilung von Komponenten**: Komponenten **in kleiner Teile zerlegen** und **über gesamtes System verteilen**.(z.B. DNS welcher hierarchisch in Domains organisiert welche wiederum in sich nicht überschneidende Zonen aufgeteilt werden. Namen in jeder Zone werden von einem einzigen Name-Server behandelt)
3. **Replikation**: Erhöht **Verfügbarkeit, Balanciert die Last** zwischen Komponenten aus (Bessere Performance) und kann mittels eine nahe gelegene Kopie **Kommunikations-Latenz-Probleme ins WANs verbergen.**

### 6. Was versteht man unter der vertikalen Verteilung bzw. N-Schichten-Systemen? Diskutieren Sie dabei alle Grundvarianten von Client/Server-Systemen. Ist folglich ein Java Applet eher ein Thick Client oder ein Thin Client?
***Definition Vertikale Verteilung***
Das charakteristische Merkmal einer vertikalen Verteilung ist, dass sie erzielt wird, indem logische *unterschiedliche Komponenten* auf (physisch) *unterschiedliche Maschinen* angeordnet werden. Jede Maschine ist auf eine bestimmte Gruppe von Funktionen zugeschnitten.

***Definition N-Schichten-Modell***
*Komponenten* (d.h. modulare Einheiten mit wohldefinierten Schnittstellen) *schichtweise angeordnet*, wobei Komponenten der Schicht Li, Komponenten der *darunterliegenden* Schicht Li-1, *aufrugen darf, aber nicht umgekehrt.* Steueeung fließt von Schicht zu Schicht: Anforderungen durchlaufen die Hierarchie nach unten, wogegen die Ergebnisse nach oben gereicht werden.

***1.Grundlegendes Client-Server-Modell:***
* Ein **Server** ist ein Prozess, der einen bestimmten Dienst implementiert.
* Ein **Client** ist ein Prozess, der einen Dienst von einem Server anfordert, indem er eine Anfrage sendet und dann auf Antwort des Servers wartet.

**PROBLEM** Keine eindeutige Unterscheidung zwischen Server und Client möglich (z.B. bei verteilten Datenbanken, wo Server Anfragen an andere Server weiterleiten)

**Client/Server Modell** wird grundsätzlich in **3 verschiedene Anwendungsschichten** unterteilt:
* **Benutzeroberfläche:** Enthält alles, was erforderlich ist um direkt mit dem Benutzer zu interagieren
* **Verarbeitungsebene (Business Logic):** Enthält die Kernfunktionalität / Application
* **Datenebene:** Hier werden die Daten unabhängig von der Applikation persistent gespeichert

***2.Two-Tier-Architektur***
Unterscheidung in verschiedenen **logische Ebenen**, wie bisher, legt mehrere Möglichkeiten der **physischen Verteilung** einer Client-Server-Anwendung über mehrere Computer nahe. Die einfachste Anordnung ist die Two-Tier-Architektur welche nur zwei Arten von Computern verwendet:
* **Client:** enthält nur Programme, die die Benutzerschnittstelle (oder Teile davon) implementieren.
* **Server:** der Rest, enthält also Programme, die die Verarbeitungs- und die Datenebene implenentieren. (Übernimmt die ganze Arbeit, Client nur simples Terminal.)

Bei einer Unterscheidung von Client- und Serverseite spricht man von einer **two-tier Architektur**. Folgende Aufteilungen sind denkbar:
* **Dumb Terminal:** Zeichen basiertes User-Interface bei dem im Echo-Modus jeder Tastendruck vom Server abgearbeitet wird. Ein reines HTML-Interface unterscheidet sich davon nur nicht wesentlich. Dumb Terminals können aber auch in Form einer GUI umgesetzt werden, wobei vereinfacht ausgedrückt der gesamte Bildschirm des Servers an den Client übermittelt wirde (zB VNC)
* Vorteile:
* zuverlässig
* einfach in Wartung und Erweiterung
* Nachteil:
* intensive Nutzung der Server und Netzwerkressourcen.
* **Thin Client**(a,b): viel einfacher, möglicherweise auf Kosten weniger anspruchsvoller Benutzerschnittstellen und auf dem Client spürbarer Leistung. Diese Verteilung nimmt einige Last vom Server und vom Netzwerk, aber sie bedeutet auch eine größere Komplexität wegen der heterogenen Gesamtstruktur.
* **Partitionated System**: Lastverteilung zwischen Client und Server.
* **Thick Client**(d,e): Client-SW wird auf Computer der Endanwender gebracht, größter Teil der Verarbeitung und Datenspeicherung auf Server ausgeführt. Client-Computer anfälliger für Fehler, je mehr Funktionalität drauf liegt.


***3. Three-Tier-Architecture***:
Server-seitige Lösungen werden zuhnehmend verteilt, sobald ein einzelner Server druch mehrer Server ersetzt wird, die auf unterschiedlichen Rechnern ausgeführt werden. Wenn wir nur Clients und Server unterscheiden, berücksichtigen wir nicht die Tatsache, dass ein Server manchmal auch als Client fungieren muss, was zu einer (physischen) Drei-Tier-Architektur fürht.

**Java-Applets**: zur **Laufzeit thick-client,** zur **Wartezeit thin-client**. Ein Applet wird mitgeschickt, auf dem Client runtergeladen und wird dort mit Hilf einer VM ausgeführt. Keine kommunikation mit dem Server nötig.
Java hat die Rahmenbedingungen von Client/Server-Architektur verändert: Java-Applets bringen di Vorteile eines Dumb-Terminal, Wartbarkeit und Erweiterbarkeit, und sogar bei Thick Clients mit reichhaltigen GUIs, denn ein Java-Applet ist hardwareunabhängig und primär am Server gespeichert. Ausgeführt wird es aber am Client. Um eine solche Applikation anzupassen, muss nur das eine Applet für eine einzige Plattform am Server erneuert werden. Bietet aber auch alle Vorteile eines Thick Client zur Laufzeit. Dies ist auch der Grundgedanke des "Network Computing". Ansatz, die Vorteile eines Thick Client ohne dessen Nachteile auszunutzen. Erkauft wird dieser Vorteil mit dem Bandbreitenbedarf währeend des Applet-Downloads und der geringeren Performance aufgrund des plattformunabhängigen Formates des Bytecodes.
### 7. Was ist horizontale Verteilung? Mit welchen grundlegenden Design-Fragen müssen Sie sich beim Entwurf der horizontalen Verteilung eines Systems beschäftigen? Gibt es einen Zusammenhang zur vertikalen Verteilung?
***Definition Horizontale Verteilung:***
Die **logisch getrennte Komponenten** der vertikalen Verteilng werden hoizontal **auf mehrere Clients / Server verteilt.**. Ein Client oder ein Server können physisch in logisch gleichwertige Teile gegliedert sein, wobei aber jeder Teil mit einem eigenen Anteil der vollständigen Datenmenge arbeitet, sodass die Gesamtlast verteilt wird.

***Zusammenhand:*** Vertikale Verteilung **setzt** eine horizontale Verteilung **voraus**. Die verschiedenen Varianten der **vertikalen Verteilung bilden die Grundlage für die horizontale Verteilung** im Netzwerk: Durch die vertikale Aufteilung entstehen jene Komponenten, die danach horizontal über der Netzwerktopologie unter Berücksichtigung der verschiedenen beteiligten Protokolle verteilt werden können. Wenn wir von einem verteilten System sprechen ist es die horizontale Verteilung die wir betrachten. Die vertikale Verteilung betrifft die Softwarearchitektur. **Die einzelnen Schichten der vertikalen Verteilung werden horizontal auf mehrere physikalische Systeme verteilt**.

***Design-Fragen:***
* **Clustering:** Komponenten die oft kommunizieren sollten nahe beieinander ligen
* **Physiche Einschränkungen:** einige Komponenten können nur auf spezifischen Rechnern oder an speziellen Orten laufen
* **Granularität** Kleinere Komponenten erhöhen die Flexibilität, aber ebenso den Netzwerkverkehr. Umgekehrt reduzieren größere Komponenten die Netzwerkbelastung, aber ebenso wird die Flexibilität und Widerverwendbarkeit reduziert.
* **Protokolle:** entscheidend für Interoperabilität und Last
* **End to End Eigenschaften:** CAP - Consistency, Availability, Performance
* **Full distribution:** distributed architecture

***Grundkonzepte der horizontalen Verteilung:**
* **Keine Verteilung:** Das gesamte System befindet sich auf einem physischen Knoten.
* **Verteilte Darstellung** Dies ist die mindestens notwendige Verteilung, wenn über mehrere User-Interfaces auf das System zugegriffen werden soll. Nur die Darstellung selbst befindet sich am jeweiligen Device, bereits das Device-abhängige "Rendering" liegt zentral am Server.
* **Verteilter Client** Auch das Rendering, die Zustandsverwaltung des User-Interfaces sowie ggf. ein Datencenter sind auf die physischen Clients verteilt. Bei einem Web-Service ergibt sich hier die Frage nach einem zentralen oder verteilten Web-Server.
* **Verteilte Geschäftslogik**
* **Verteilte Datenbanken**
* **Voll verteiltes System:** Es gibt keine einzige zentrale Komponente. Solche Systeme zeichnen sich i.Allg. durch potenziell günstiges Ausfallverhalten aus, welches aber durch komplexe Algorithmen erkauft werden muss, die durch das Fehlen zentraler Services verursacht werden.

**WICHTIG:** Jede vertikale Schicht kann Komp. unabhängig von den anderen Schichten horizontal verteilen.
### 8. Welche Eigenschaften erwartet man heute von Software? Warum steht die Erwartungshaltung an den Software-Entwicklungszyklus dazu im Widerspruch?
**Eigenschaften** Die erwartet werden:
* Complex
* Distributed
* High Quality
* Inexpensive
* Easy to use
* mission/safety critical
* Availability, Continous access
* heterogeneous, legacy integration /wrapping
* less time between versions with new features
* stability reliabilty and robustness throughout the entire life cycle

**Agile:** Make it GOOD, FAST, CHEAP, pick 2
**Folge:** Wenig Flexibilität in der (Weiter-)Entwicklung

**Erwartuzngshaltung** an Entwicklungszyklus
* Niedriger Aufwand bei der Erstellung (niedrige Kosten)
* Einhaltung der Projektlaufzeiten
* Prozess und Qualitätsorientiert
* Nur ide gestellten Anforderungen sollen die SW bestimmen
* Test ausgerichtet an den Use-Case
**Widerspruch:** Es ist nicht möglich die Punkte miteinander zu vereinen:
* **Testing** kostet ZEIT und GELD, investiert man dies nicht, enthält die SQ von Anfang an viele Fehler und es sind wenige Anwendungsszenarien bekannt, die getestet werden sollten. Fehler in der SW sind im NACHHINNEIN schwer zu finden und durchaus PROBLEMATISCH und TEUER zu beheben.
* SQ-Entwicklung läuft nicht ohne Veränderungen, neue Ideen und Problemstellungen ab. Soll die PROJEKTLAUFZEIT dennoch EINGEHALTEN werden, geht dies nur auf Kosten der QUALITÄT
* Der Anwender AKZEPTIERT FEHLER im System. SQ kommt SCHNELL und FEHLERHAFT auf den Markt
**Lösung**
* Grundlage ist die OBJEKTORIENTIERTE programmierung
* BAUKASTENPRINZIP: es existieren wiederverwendbare SW-Komponenten
* Nur jene KOMPONENTEN müssen entwickelt werden, für deren FUNKTIONEN es noch keine IMPLEMENTIERUNG gibt.
* VORTEILE: Zeitersparnis & erhöhte Qualität (die wiederverwendeten Komponenten haben eine hohe Nutzerzahl, was vielen Testszenarien gleichkommt.)
## COMM1: Communication (1)
Unterlagen:
* Buch 2.1, 2.3, 2.4, 4.1, 4.2
* Studienbrief
### 1.Beschreiben Sie das ISO-OSI Modell der geschichteten Protokolle (Grundprinzip). Stellen Sie den Bezug zu den Internet-Protokollen (TCP/IP) her. Warum sind Transport-Layer Protokolle für Verteilte Systeme oft nicht ausreichend?
Das ISO-OSI Modell besteht aus 7 Layern. Jeder layer erfüllt eine andere Aufgabe.
Es wurde von der ISO (International Organization of Standardization) standardisiert. Es stellt den WEG einer NACHRICHT von einem zum anderen Computer über ein Netzwerk dar. Es gibt 7 SCHICHTEN. Jede einzelne Schicht hat ihre Aufgabe. Die Daten werden nur ZWISCHEN ZWEI BENACHBARTEN SCHICHTEN AUSGETAUSCHT. TCP und IP PROTOCOLL SUIT wird am häufigsten verwendet.

1. Physical layer
Die Bitübertragungsschicht ist für das übertragen der Einsen und Nullen zuständig. Das Protocoll der Bitübertragungsschicht kümmert sich um die Standardisierung der Elektrischen-, Mechanischen und Signalschnittellen. Die Bitübertragungsschicht sendet lediglich Bits
2. Data Link Layer
Fehler entdecken und korrigieren. Gruppieren von Bits in Frames und berechnen der Prüfsumme. Der Empfänger berechnet die Prüfsumme ernaut. Simmen beide überein wird der Frame als korrekt anerkannt und angenommen, wenn nicht bittet der Sender den Empfänger um die erneute übertragung
3. Network Layer
Damit eine Nachricht vom Sender zum Empfänger gelangen kann können (in WANs) wo mehrere Teilstrecken (Hops) erforderlich sein. Die Auswahl des besten Weges (ROUTING) ist Aufgabe des Network Layer. Momentan ist das am weitesten verbeitete Netzwerkprotokoll das verbindungslose Internet Protocol(IP)
4. Transport Layer
Die Transportschicht bildet den letzten Teil des grundlegenen Netzwerkprotokollstacks. Die Anwendungsschicht kann somit einen Nachricht an die Transportschicht in der Erwartung übermitteln, dass sie ohne Verluste ihr Ziel erreicht. Wenn die Transportschicht eine Nachricht von der Anwendungsschicht erhält, zerteilt sie sie in kleine Stücke weist jedem eine "sequence number" zu und sendet dann alle. Transportverbindungen können auf "connectionless" oder "connectionoriented" Netzwerkdienste aufsetzen (TCP/UDP)
5. Session Layer
Erweiterte Version des "transport layer". Bietet eine Dialogkontrolle, um zu verfolgen welcher Teilnehmer gerade spricht, sowie Funktionen zur Synchronisierung. In der Praxis sind nur wenige Anwendungen am "Session Layer" interessiert. In der Internetprotokollsuite (TCP/IP) ist sie nicht vorhanden (5,6,7 gruppuiiert zu "application Layer")
6. Presentation Layer
7. Access Layer

#### Stellen Sie den Bezug zu den Internet-Protokollen (TCP/IP) her.
Heute kommt das TCP/IP modell zum Einsatz. Es ist eine Weiterentwicklung des OSI-Modells. Dieses besteht nur mehr aus 4 Schichten.

#### Warum sind Transport-Layer Protokolle für Verteilte Systeme oft nicht ausreichend?
Nachdem die verschiedenen Servieces die auf einem verteilten System zum Einsatz kommen kann es sein, dass unterschiedliche Services miteinander kommunizieren wollen.

Beispiesweise ich teile meine DatenBank auf mehrere Standorte auf (Standort A -> UserData, Standort B -> VerwaltungsDaten), so brauche einen Software-Abschnitt der mit mehreren Instanzen gleichzeitg kommunizeiren kann und die Informationen zusammen bringen kann (Konzept der "business logic").

### 2.Was ist Middleware? Welche Anforderungen stellt man an Middleware? Welche Services soll Middleware bieten? Erläutern Sie den Zusammenhang zwischen Middleware und Architectural styles.
Beginnt man Systeme aufzuteilen so wächst die Komplexität des Gesamten Systems dramatisch. Sie dient formt eine Schicht zwischen Applikationen und verteilten Systemen.

> Middleware soll die Komplexität die verteile Systeme mit sich bringen **vereinfachen**.

Außerdem erfüllt die Middleware die Aufgabe, verteilie Systeme für den Benutzer unsichtbar zu machen. Dem User soll nicht bewusst sein, dass im Hintergrund mehrere Systeme miteinander agieren.
#### Welche Anforderungen stellt man an Middleware?
+ Middleware-Systeme müssen auf einem Komponentenmodell basieren
+ Es muss die Möglichkeit bestehen, Interfaces definieren zu können
+ Weiter ist es notwendig, dass alle Komponenten systemweit eindeutig identifiziert werden können
+ „Communication primitives“ müssen zur synchronen und/oder asynchronen Kommunikation der einzelnen Komponenten bereitgestellt werden
+ Middleware-Systeme müssen auch Interoperabilitäts-Protokolle implementieren, um Komponenten verschiedener Hersteller (Hardware, Betriebssysteme, Netzwerkprotokolle, Programmiersprachen) zu integrieren
+ Aktivierungs- und Deaktivierungsstrategien zum Ansprechen von transienten und persistenten Komponenten sind von Nöten
#### Welche Services soll Middleware bieten?
+ Life-cycle Service
+ Naming Service
+ Trading Service
+ Persistence Service
+ Concurrency control Service
+ Transaction Service
+ Security Service
#### Erläutern Sie den Zusammenhang zwischen Middleware und Architectural styles.
Moddleware wird oft in einem bestimmten architectual style eingesetzt: dem object-based architectural style. Einen angepassten "architectural style" zu verwenden kann die Entwicklung von Applikationen erleichtern.

***AUSARBEITUNG POL***
**Definition**
Middleware ist eine ANWENDUNG/LAYER, die logisch ZWISCHEN APPLICATION- UND TRANSPORTLAYER / VS EINZUORDNEN, aber VIELE ALLGEMEINE PROTOKOLLE ENTHÄLT, die ihre EIGENEN SCHICHTEN UNABHÄNGIG VON ANDEREN, spezifischen Anwendungen gewährleisten. Benötigte SERVICES werden in parametrisierbarere Form ZUSAMMENGEFASST und ANGEBOTEN

**Services:**
* Communication facilities (ACESS Transparency)
* Naming (LOCATION & MIGRATION Transparency)
* Persistence services or frameworks (PERSISTENCE transparancy)
* Distributed transactions (CONCURRENCY Transparancy)
* Replication (FAILURE Transparancy)
* Security (AUTHENTICATION/AUTHORIZATION)

Man kann annehmen, dass sich die Entwicklung von Middleware für VS weitgehend mit der BEHANDLUNG ZUSÄTZLICHER FUNKTIONALITÄT UNABHÄNGIG VON ANWENDUNGEN beschäftigt. Die Middleware bildet eine SCHICHT ZWISCHEN ANWENDUNGEN UND VERTEILTEN PLATTFORMEN. Ein wichtiger Zweck besteht darin einen Grad von VERTEILUNGSTRANSPARENZ zu bieten, der in einem gewissen Maß die Verteilung von Daten, die Vararbeitung und die Steuerung vor den Anwendungen verbirgt. Wenn Middleware nach einem bestimmten Architekturstil geformt ist, hat das den Vorteil, dass der Entwurf von Anwendungen einfacher werden kann, eventuell ist die Middleware dann jedoch nicht mehr optimal für das geeignet was der Anwendungsentwickler im Sinn hat.

**Anforderungen:**
* Transparancy
* Openness
* Maintainability
* Supports Interface Definition
* Scalable
* Life-Cycle Management für die Komponenten
* Offers communication basis (a-/synchron)
* Offers concurrency (Thread library)

Middleware ist die Softwareschicht in einem VS, die zwischen den Anwendungen und den Betriebssystemen bzw. der grundlegenden Kommunikation liegt. Dadurch soll ein Erscheinungsbild wie eines einzigen Systems ermöglicht werden. Die Komplexität eines VS sollte durch die Middleware so gut wie möglich vor dem Endbenutzer oder dem Komponenten-Entwickler verborgen werden.

**Architectural styles for Middleware**
* Layered architecture (OSI)
* Object-based architecture (And components)
* Data-centered architecture (file based, database, resourceful WS, ...)
* Event-based architectures

Middleware die sich ausschließlich auf einen Architekturstil stützt hat den Vorteil, dass es die Applikationsentwicklung erleichtert.
Nachteil: Applikcationen können womöglich nicht/nicht optimal für dessen Anwendungsfall implementiert werden, da es für die gewünschte Funktionalität in der zugrundeliegenden Architektur der Middleware keinen passenden Mechanismus gibt. Daraus ergibt sich das die Granzen der Architekturstile für Middleware eher schwimmend sind und Funktionalitäten mehrerer Architekturstilen vereint werden.
### 3. Wie kann man die Flexibilität der Middleware erhöhen sowie die Zusammenarbeit von Middleware und Anwendung effizienter gestalten? Erläutern Sie dabei die Grundprinzipien von Interceptoren, Adaptivität und Self-Management.
Spezifische Lösungen welche an die Anforderungen der ANWENDUNG ANGEPASST sind, indem man MEHRERE VERSIONEN eines Middleware-Systems erstellt und auf eine bestimmte Anwendung zuschneidet.
Ein Ansatz´, der im Allgemeinen als BESSER angesehen wird, besteht darin, MIDDLEWARESYSTEME so zu gestalten, dass sie EINFACH KONFIGURIERT und an die Anforderungen einer ANWENDUNG ANGEPASST werden können. Infolgedessen werden derzeit Systeme entwickelt, in denen eine strengere TRENNUNG ZWISCHEN RICHTLINIEN UND MECHANISMEN vorgenommen wird. Dies hat zu mehreren MECHANISMEN geführt, durch die das VERHALTEN VON MIDDLEWARE MODIFIZIERT werden kann.

**INCREASE FLEXIBILITY BY:**
* Interceptors
* Adaptivität:
* Serparation of concerns (Modularisierung)
* Computational reflection (Anpassen der Parameter zur Laufzeit)
* Component-based design (Automatic adaptation through composition)
* Autonomic computing, Self* (Selbstregulierung, Selbstwiederherstellung, ...)
* Middleware-Application interaction (Plug-ins,...)

**INTERCEPTORS** SOFTWARE KONSTRUKTE (Design Pattern), die den normalen KONTROLLFULSS UNTERBRECHEN und es erlauben, anderen CODE AUSZUFÜHREN (Mittel um die Middleware anzupassen). Having only limited interception facilities will improve managemen.

**ADAPTIVE SOFTWARE**
* **Separation of concerns:**
Traditionelle Art, Systeme zu modularisieren. Trennen der Teile eines Systems, die FUNKTIONALITÄT implementieren, von denen, die für EXTRAFUNKTIONALITÄTEN wie Reliability, Performance, Security etc. zuständig sind.
* **Computational reflextion:**
Fähigkeit eines Programms, sich SELBST ZU ÜBERPRÜFEN und sein VERHALTEN ANZUPASSEN
* **Component-based design:**
Unterstützt Anpassung durch Komposition (dynamisch zur Laufzeit). Requires support for LATE BINDING, a technique that has been successfully applied in programming language environments, but also for operating systems where MODULES CAN BE LOADED AND UNLOADED AT WILL.

**SELF-MANAGEMENT**
In großen, verteilten Systemen von entscheidender Bedeutung. Für viele Systeme stellen eine ZENTRALE VERWALTUNG UND ORGANISATION KEINE OPTIMALE LÖSUNG dar. Die meisten selbstverwaltenden Systeme haben gemeinsam, dass ANPASSUNGEN MITHELFEN einer oder mehrerer Rückkopplungsschleifen (FEEDBACK-CONTROLL-LOOPS) erfolgen. Diese Schleife besteht neben den komponenten, die das eigentliche VS ausmachen, aus 3 Teilen:
* Die METRIC ESTIMATION COMPONENT quantifiziert die Aspekte eines Systems, die Rückschlüsse auf seine Effizienz zulassen zB Latenzzeiten.
* Die FEEDBACK ANALYSIS COMPONENT wertet diese Messung aus und bestimmt, welche Veränderung am System vorgenommen werden.
* Schließlich beeinflussen verschiedene ANPASSUNGSMECHNAISMANE das System direkt und verändern zB die Platzierung von Repliken, Scheduling Strategien oder Lastverteilung

### 4. Erläutern Sie das Grundprinzip des Remote Procedure Call. Gehen Sie auf die Begriffe "client stub" und "server stub" näher ein.

+ client calls function
+ server receaves the call and responds
+ clinent's procedure is blocked while server is processing the call
+ client resumes after server finished

RPC wants to be tranparent -> calling procedure is not aware that call is executed on a different machine or vice versa.

#### Gehen Sie auf die Begriffe #client_stub und #server_stub näher ein.
+ #client_stub
+ The #client_stub is put into the library
+ #client_stub takes a system call (e.g. read call)
+ does **not** send it to the OS
+ #client_stub sends request and all parameters to a remote server to handle the call
+ after sending the request the #client_stub calls *receive* blocking itself until the reply come back

+ #server_stub
+ server-side equivalent of a #client_stub
+ #server_stub transforms requests into local procedure calls
+ From the server’s point of view, it is as though it is being called directly by the client–the parameters
+ server procedure is called by the #server_stub

#### RPC Abluaf (ohne beachtung von marshaling):
1. The client procedure calls the client_stub in the normal way.
2. The client_stub builds a message and calls the local operating system.
3. The client’s OS sends the message to the remote OS.
4. The remote OS gives the message to the server_stub.
5. The server stub unpacks the parameters and calls the server.
6. The server does the work and returns the result to the server_stub.
7. The server_stub packs it in a message and calls its local OS.
8. The server’s OS sends the message to the client’s OS.
9. The client’s OS gives the message to the #client_stub.
10. The stub unpacks the result and returns to the #client_stub.

***Ausarbeitung POL***
**Definition:** Programme er´halten die Möglichkeit PROZEDUREN auf ENTFERNTEN Rechnern auszuführen. Wenn ein Prozess auf Rechner A eine Prozedur auf Rechner B aufruft, wird der Prozess auf A ANGEHOLTEN und die Ausführen der aufgerufenen PROZEDUR FINDET AUF RECHENER B STATT. Die PARAMETER können Informationen vom Aufrufer zum Aufgerufenen ÜBERTRAGEN und werden im ERGEBNIS der Prozedur ZURÜCKKOMMEN

**Goal:**
Making a REMOTE PROCEDURE CALL LOOK LIKE A LOCAL ONE. In other words, we want RPC to be TRANSPARENT while the calling procedure should not be aware that the called procedure is executing on a different machine or vice versa by using stubs:
* STUB PROCEDURES marshal and unmarshal parameters
* CLIENT STUB marshals input parameters (and unmarshals return parameter).
* SERVER STUB unmarshals input parameters and marshals return parameter.


### 5. Wie können Variablen bei Prozedur-Aufrufen grundsätzlich übergeben werden? Wie werden Sie bei RPC gehandhabt und welche Probleme gibt es dabei?
#### Grundsätzliche Parameterübergabe:
* **Call by value:** Der Wert der lokalen, am Stack gespeicherten Variable wird übergeben.
* **Call by reference:** Die Adresse der Variable am lokalen Rechner wird übergeben.
* **Call by copy/restore:** Der Wert der Variable wird kopiert, lokal verarbeitet und zurückgeschrieben.
#### RPC Parameterübergabe:
* **Value-Parameter:** und der Name/UUID der aufzurufenden Prozedur werden vom Client-Stub in eine Nachricht verpackt (**Parameter-Marshaling**)
* **Reference-Parameter:** Bei Pointern auf einfache Arrays und Strukturen werden die Daten in die Nachricht kopiert und mitgesendet. Anschlißend wird das Ergebnis zurückgesendet und der ursprüngliche Wert überschrieben.

**Problem:** **Verschiedene Geräte** haben oft **unterschiedliche Daten-Darstellungen**. Zwischen diesen Geräten können die Daten nicht einfach verpackt und gesendet werden, da die **Daten flasch interpretiert** werden würden.
BSP:
* EBCDIC (IBM Mainframe)- ACSII (IBM PC)
* Little Endian - Big Endian (Byte Nummerierung rechts nach links-links nach rechts)

**Lösung::** Man muss also vorher die Daten in ein Format bringen die der andere Rechner versteht. Dieser Prozess nennt sich **marshalling**.

### 6. Sind "call by reference" und "call by copy/restore" bzgl. des Ergebnisses des Prozeduraufrufes wirklich immer identisch? Tipp: Denken Sie an eine Prozedur incr(a,b) welche beide Integer-Parameter a und b um jeweils 1 erhöht. Was passiert bei folgendem Aufruf, wo ein und dieselbe Variable zweimal übergeben wird: incr(i,i)?
**Call by Reference**
1. Adress is passed, instead of value
2. Arrays are always passed by reference
**Call by Copy/Restore**
1. The variable is copied from the caller to the stack. Then it is copied back, by replacing the old variable value.
2. Leads to almost the same result as Copy by Reference, however, with more entris in the parametes list.
**Problem:**
1. Wenn mehrere Parameter übergeben werden, kann aber immer nur ein Wert returned werden.
2. Wenn man variablen mehrmals übergibt, werden diese vom Server als verschiedene Variablen behandelt. Im Bsp würde i nur um 1 anstelle um die erwarteten 2 erhöht werden.

### 7. In C gibt es die Datenstruktur "union", bei der in einem Feld einer von mehreren Datentypen enthalten sein kann, wobei zur Laufzeit nicht bekannt ist welcher. Vor welches Problem stellt das die RPC-Laufzeitumgebung und wie könnte man es überwinden?

### 8. Wie schreibt man für RPCs Client und Server und welche Rolle spielt dabei die IDL?
Ein RPC-System besteht aus einer Reihe von **Komponenten** darunter **Sprachen, Bibliotheken, Daemons, Hilfsprogrammen.** Zusammen ermöglichen sie das Schreiben von Clients und Servern.
In einem **Client-Server System** ist die **Schnittstellendefinition** (angegeben in der IDL - Interface Definition Language) der Kleber, der alles zusammenhält.
In den **IDL-Datein** sind **Prozedurdeklarationen** (in ähnlicher Form wie Funktionsprototypen in C), **Typendefinitionen, Konstantendeklarationen** und andere **Informationen für die korrekte Verpackung der Parameter*** und das **Auspacken der Ereignisse** enthalten.
Ein extrem **wichtiges Element** jeder IDL-Datei ist ein **global eindeutiger Bezeichner** (UUID) für die **spezifische Schnittstellt**. Versucht ein Client versehentlich sich zu einem flaschen Server zu verbinden, oder auch zu einer älteren Version des richtigen Servers, wird der Fehler erkannt und die Verbindung findet nicht statt. Nachdem die IDL-Datei bearbeitet wurde (Namen der Prozeduren und ihre Parameter eingetragen), wird der **IDL-Compiler** aufgerufen.

Die **Ausgabe des IDL-Compilers** besteht aus drei Teilen:
* Header-Datei (wird jeweils in den Server- und Client-Code inkludiert)
* Client Stub
* Server Stub

Anschließend werden der Client sowie der Server **Code kompiliert, ebenso** wie bei beiden **Stub-Prozeduren.** Die resultierenden **Client-Code und Client-Stub-Objektdateien** werden anschließend zu der **Laufzeitbibliothek gebunden**, um die ausfürhbare Programmdatei für den Client zu erzeugen.

**Analog dazu** werden der **Server-Code und der Server-Stub kompiliert und gelinkt,** um die Programmdatei des Servers zu erzeugen.
Mit dem Einsatz der **IDL als Schnittstellendefinitionssprache** wird die **Applikationsentwicklung** wesentlich **vereinfacht**.

An IDL supports the defintion of procedures that my be called remotely. It provides a set of "universal" types. IDL compiler generates client and server header files and stubs. Client code includes client header file and links to client stub. Server code includes server header and links to server stub. Caller and callee need not be in same lagnuage!
### 9. Was versteht man beim RPC unter "binding"?
**Definition:** The RPC system can automatically locate the correct server, and subsequently set up the communication between client and server software.

Um eine **"remote procedure"** aufrufen zu können, muss der **Server registriert** und darauf **vorbereitet** sein, eingehende **Anrufe anzunehmen**. Die **Registration** eines Servers ermöglicht es einem Client diesen zu **lokalisieren** und sich an ihne zu **binden**. Erst dann kann eine Nachricht vom Client-Prozess zum Server-Prozess versendet werden. in dieser müssen der **Name der Prozedur** (oder eine **ID**) zbd due **zugehörigen Parameterwerte** enthalten sein.

**DCE: PRC Service Regirstation and Binding Procedure:**
1. Server **registriert** einen **Endpoint** beim eigenen DCE deamon (**port** assigned by the server OS)
2. Server **registriert** einen **Service**
3. Client **looks up** the Service at a **Directory Service**
4. Client **asks Server deamon** for **Endpoint**
5. Client does the acutal RPC


Summary RPC:
* is an end-to-end service implemented on top of transport layers; it allows a procedure to be called in a different process
* An interface definition language supports the definition of interfaces and the generation of stubs to be used by clients and servers
* PRC is supported by a directory service at runtime to register and locate remote procedures (binding)

### 10. Welche Arten von asynchronen RPCs gibt es?
Grundsätzlich kann zwischen **3 Arten von RPCs** unterschieden werden:
* synchron - Wartet auf ein Ergebnis
* asynchron - wartet auf eine Empfangsbestätigung
* one-way - wartet nicht

Der "deffered(verzögerte) synchrone RPC" besteht aus 2 asynchronen RPCs:
* asynchroner RPC (ANFRAGE) wird vom Client an den Server gesendet
* asynchroner RPC(Ergebnisse) wird vom Server an den Client gesendet.

Allgemeiner **überblick** über verschiedene Typen der Kommunikation
* (a) Persstente asynchrone Kommunikation;
* (b) Persistente synchrone Kommunikation;
* (c) Transiente asynchrone Kommunikation;
* (d) Empfansbasierte transiente synchrone Kommunikation;
* (e) Auslieferungsbasierte transiente synchrone Komm;
* (f) Antwortbasierte transiente synchrone Komm;


PERSISTEND: Eine Nachricht wird so lange von der Kommunikations-Middleware gespeichert, wie es dauert, sie an den Empfänger auszuliefern.
TRANSIENT: Eine Nachricht wird nur so lange gespeichert, wie die sendende und empfangende Anwendung ausgeführt wird.

## COMM2: Communication (2)
Unterlagen:
* Buch: 4.1, 4.3, 10.1.1, 10.3, 10.4
### 1.Erläutern Sie die Grundprinzipien verteilter Objekte sowie der Remote Object (bzw. Method) Invocation. Gehen Sie auf die Begriffe "proxy" und "skeleton" ein.
* Ein verteiltes Objekt enthält Daten.
* Diese Daten nennt man State
* Operationen auf diese Daten/States nennt man Mehtods.
* Daten/States können NUR via Methods aufgerufen & manipuliert werden.
* Methoden werden Prozessen via Interface zur Verfügung gestellt.
* Interfaces erlauben die Bereitstellung von Methoden von Maschine A auf Maschine B

**Remote Object**
* Daten/States sind NICHT verteilt-> auf einer Maschine
* Nur Interfaces machen den Zugriff auf entlegene States/Daten möglich
* Solche Objekte nennt man dann REMOTE OBJECTS

**Proxy**
* Client side stub
* Stellt dem Client interfaces vom verteilten system zur Verfügung

**Skeleton**
* server sided stub
* Stellt Wege bereit um auf Data/State zuzugreifen
* Enthält oft unvollständigen Code einer spezifischen Sprache

#### Ausarbeitung POL
**RMI:** Grundlegend das gleiche wie ein RPC nur mittels Objekten anstelle von Applikationen. Erweiterung des OO Modells für **"remote references"** und **"invokations"** (obj.meth(); obj==remote). **Objekte** über das Netzwerk **verteilt**. Oject references can be freely **passed between processes** on different machines

**Object:** Objekte dienen zur **Kapselung von Daten** genannt, Zustand sowie **Operationen** auf diese Daten. Methoden sind **durch ein Interface verfügbar**

**Distributed Object:** Die **Aufteilung zwischen Interfaces und Objekten**, die sie implemejntieren ist essenziell für verteilte Systeme. Sie erlaubt uns ein Interface auf einem anderen Computer als das Object selbst zu plazieren.

**Remote Object** Im Gegensatz zu einem **Interface**, welches auf verschidenen Geräten **verteilt** sein kann, wird der "state" eines Objekts nur **lokal** auf der Maschine gespeichert, welche das dazugehörige Object besitzt. Mittels interface kann dann remot darauf zugegriffen werden.
**Veränderungen** können **nur über Remote Interfaces(Proxy des Objekts)** durchgeführt werden. Dieser **Proxy reicht alle Änderungen an das Sekelton** des Servers weiter, welches dann die eigentlichen Änderungen durchführt.
Wenn sich der Client an das verteilte Objekt **bindet**, wird die **Proxy (Client-Stub) Implementierung geladen**. Diese übernimmt das **Marshalling** der Parameter, **serialize** und **Unmarshalling** der Antwort. Der **Skeleton (server-stub)** (provides the bare means for letting the server middleware access the user-defined objects) übernimmt das **Parameterunmarshalling**, das Ausführen des **Methodenaufrufs** des Objekts und **Marshalling** der Antwort am Server.
### 2.Erläutern Sie den Unterschied zwischen "compile-time" und "run-time" objects bei RMI(Remote Method Invocation).
**Compile-Time**
* Sprache spezifiziert
* Objet aus einer OO-Sprache welches die Instanz einer Klasse ist.
* Die Schnittstellen können clientseitig und serverseitig kompiliert werden, um Java Objecte von einer entfernten Maschine aufzurufen
* Von einer kompilierten Klasse können die Objecte instanziert werden.
* Diese Definition beinhaltet Datenelemente und Operationen auf diese Daten, die das Object aufweist und seine Struktur kann zur Laufzeit nicht geäändert werden.
Bsp:
public class Person{
private String name;
private int age;

}
Person person1=New Person();

Wen man das Programm startet wird die Klasse kompiliert und das Objekt Person wird erstelt.

**Run-Time**
* Sprache nicht festgelegt.
* Die spezifische implementierung bleibt offen
* werden zur Laufzeeit konstruiert dh die implementierung ist weitgehend offen
* Die Objekte werden aufgrund ihrer Schnittstellen definiert

#### Ausarbeitung POL
Objekte können auf unterschiedliche Arten erzeugt werden:
**Compile Time Object**
* language-level object
* defined as an instance of a class (type+interface)
* class is a description of an abstract data type
* definition beinhaltet alle methode
* aus einer klassendefinition können client&server stubs abgeleitet werden
* struktur kann zur laufzeit nicht gändert werden
* programmiersprachen gebunden

**Run Time Object**
* Constructing distributed objects during run-time
* supports multiple languages
* wrapper (object adapter) lets code appear to be an object whose methods can be invoked
* only defined in terms of theirs interface
* cannot automatically generate stubs

**INFO:** To make wrapping as easy as possible, objects are solely defined in terms of the interfaces they implement. An implementation of an interface can then be registered at an adapter, which can subsequently make that interface available for (remote) invocations. The adapter will take care that invocation requests are carried out, and thus provide an image of remoter objects to its clients.
### 3.Wie funktioniert das Binding bei RMI(Remote Method Invocation)? Welchen Zusammenhang gibt es zu den verschiedenen Arten, eine object reference zu implementieren. Vergleichen Sie (exemplarisch) CORBA und Java in Bezug auf Objektreferenzen.
RMI generally provides **systemwide globally unique object references**. Which can be freely **passed between processes** on different machines, f.e. as parameters to mehtod invocations. By hiding the actual implementation of an object reference which provides an **enhanced distribution transparancy**. A process **needs to bind** to the referenced object before beeing able to invoke methods.
**Binding** results in a **proxy** being placed **in the process's address space**, implementin an **interface** containing **methods** the process can invoke. In many cases, binding is done automatically. WHen the underlying system is given an object reference, it needs a way to locate the server that manages the actual object (Naming Service/Directory Server), and place a proxy in the client's address space.

With **impicit binding**, the client is offered a **simple mechanism** that allows it to **directly invoke** methods **using only a reference** to an object.

In contrast, with **explicit binding**, the client shhould first call a **special function to bind** to the object before it can actually invoke its mehtods. Explicit binding generally returns a **pointer to a local proxy**.

A **simple object reference** must contain enought **information to allow a client to bind** to an object. (server NW Addr. + service end point + [object ID + additional information])

**Network addr. + server ID(daemon):** All object references will become invalid if server receives new endpoint after crash. DCE ahs a **local daemon** to listen on well-known ports and updates the **end point table**. When binding a client to an object, we first ask the daemon for the server's current end point. Requires that we encode a **server ID/ server network address** into the object reference that can be used as an index into the end point table.

**Location server + unique server ID:** The server **can never move to another machine** without invalidating all the references to the objects it manages. An obvious solution is to **expand the idea of a local daemon** maintaining an end point table to a **location server** that keeps track of the machine where an object's server is currently running. An object reference would then contain the **network address of the location server**, along with a **systemwide identifier for the server**.

**Additional information:** To be sure, client and server, use the **same protocoll stack**, we can add additional information in the object reference. (f.e. binding protocol, flow control, error handling, parameter marshalling)

**Implementation handle:** Included the object reference, an implementation handle **refers to a complete implementation of a proxy** that the client can **dynamically load when bining** to the object.

**Objektreferenz in Java:**
* **Unterscheidung** in JAva zwischen **remote** objects und **local** objects:
* **local**: passed by **value**
* **remote**: passed by **reference**
* **interface construct** used to **define remote objects**
* remote interface indicates remotely callable object
* in **Java RMI** ist **Referenz** wir folgt implementiert:
* **Netzwerkaddresse* und **endpoint** von einem Server
* **Lokale ID** für ein **Object** im Addressraum der Servers
* Muss auch den **protocol stack** beinhalten
* Prinzip: Jedes Objekt kann als Parameter in einer RMI übergeben werden, vorausgesetzt marshalling kann angewendet werde. D.h. es muss serialisierbar sein. Plattformabhängige Objekte wie file descriptors und sockets sind nicht serialisierbar
* Similar to CORBA but **supports only one language**
* Objects are **passed between JVMs**

**Objecktreferenz in CORBA:**
* Corba Systeme unterstützen spraenunabhängige Repräsentation eines Objekts
* Die Interoperable Object Reference (IOR)
* IOR umfasst die Informationen die benötigt werden um ein Objekt eindeutig zu identifizieren

### 4.Was versteht man unter "static" und "dynamic" RMI(Remote Method Invocation)?
**Static invocations**
* Predifined interfaces
* muss definiert sein BEVOR der Client entwickelt wird (stub)
* -> changes in Interface = recompilation of Client (stub)
**Dynamic invocations**
* composed at runtime
* application chooses at runtime which method is invoked
* invoke(object, method,input_parameters, output_parameters);
* object identifies the distributed object,
* method is a parameter specifying exactly which method should be invoked,
* input_parameters is a data structure that holds the values of that method’s input parameters,
* output_parameters refers to a data structure where output values can be stored.
#### Ausarbeitung Pol
Íst eng verknüpft mit der Frage: "Kenne ich die Typinformation zur Laufzeit oder nicht?" Für RMI muss man grundsätzlich genau wie bei RPC die Objekt-Interfaces in einer IDL spezifizieren. Alternativ dazu kann man eine OO-Sprache - zB Java - verwenden, welche die Generierung der Stubs automatisch handhabt. Dieser Ansatz wird als static invocation bezeichnet.

**Static invocation**
The approach of using **predifined interface definitions** requires that the interfaces of an object are known when the client application is being developed. It also implies that if interfaces **change**, then the client application must be **recompiled** before it can make use of the new interfaces.

object.method(input_param,output_param)

**Dynamic invocation**
**Composes** a method **invocation at runtime which method it will invoke**(repository or reflection) at a remote object.

invoke(object, mehtod, input_param, output_param)

**Nachteil von dynamic RMI:**
* schlechte performance
* möglicher Laufzeitfehler (Compiler kann während der Entwicklung nicht helfen)
* Entwicklung muss in **Interface Repository** nachsehen und sich dort über die **method ID** informieren
* dynamic RMI NUR wenn es nicht anders geht

**Anwendung von dynamic invocation**
* **Object browser:** Prüft welche Objekte welche Methoden anbieten, präsentiert die Möglichkeiten einem Client. Der Client kann nun über diesn Browser die unterschiedlichsten Methoden von unterschiedlichen Objekten aufrufen und erhält über diesen Browser die Antwort.
* **Batch processing service:** Eine Art Scheduled Task, diesem Service können invocation request übergeben werden, dieses Service sammelt dies in einer Queue und ordnet diese nach der Zeit. Sobald die Zeit für die Ausführung erreicht wurde, wird die invocation aus der Queue gelöscht und der Methodenaufruf mit invoke(...)gestartet.
* **Run-Time inspection and frameworks**

**Static vs. dynamic RMI:**
* Static invocation
* Predefined interface definition (IDL or programming language)
* Interface change -> client re-compiled
* myobject.doSomething(in1,in2,out1,out2)
* Dynamic invocation
* compose the method invocation at run-time
* invoke (object, method, inparams, outparams)
* Needs lookup for method-name (repository or reflection)
* Applications: object browser, run-time inspection, batch processing, frameworks
### 5.Wie funktioniert die Parameterübergabe bei RMI? Gehen Sie dabei auf jene Eigenschaften der Objektorientierung ein, welche den Vorteil von RMI(Remote Method Invocation) gegenüber RPC (remote procedure calls)bewirken.
* client programm on Machine A
* Server Program on Machene C
* client has reference to O1 localy
* client has reference to O2 remotely on Machine B
* When calling the method on the server a copy of O1 and a reference of O2 is passed
* the reference consists of NW adress + end point of the server as well as a local identifier for the actual object in the servers address space
#### Vorteil von RMI gegenüber RPC
* trough object references passing parameters is less restricted than in RPC
* but a little bit trickyer

#### Ausarbeitung POL
**systemwide object refereces** makes passing object reference in method **invocations less restricted** than for RPCs. But doing so can be highly **ineffective** for **small objects**

**Remote object:(call by reference)**
reference is copied and passed as value

**Local object:(call by call by value)**
object is copied as a whole

The side effect of invoking a method with an object reference as parameter is that we may be copying an object. Obviously, hiding this aspect is unaceptable, so that we are consequently forced to make an explicit distinction between local and distributed objects. Clearly, this distinction not only violates distribution transparency, but also makes it harder to write distributed applications. local and remote objects are completely different in Java.

**Differences to RPC:**
* RMI is less restrictive due to **systemwide object references**
* A pointer in C can never be used to refer to a remote object
* highly **ineffective** for **small objects**
* Durch die definition neuer Interfaces können neue Datentypen definiert werden ohne die Basisinfrastruktur adaptieren zu müssen. Das heißt dass man komplexe Datentypen, zB eine Liste, als ein Argument problemlos verschicken kann
* "Call by copy/restory" entfällt da "call by reference" mittels object reference möglich ist.

### 6.Geben Sie einen verallgemeinerten Überblick über verschiedene Typen der Kommunikation (persistent/transient bzw. synchron/asynchron).

**Allgemeiner überblick** über verschiedene Typen der kommunikation bei RMI;
* (a) Persstente asynchrone Kommunikation;
* (b) Persistente synchrone Kommunikation;
* (c) Transiente asynchrone Kommunikation;
* (d) Empfansbasierte transiente synchrone Kommunikation;
* (e) Auslieferungsbasierte transiente synchrone Komm;
* (f) Antwortbasierte transiente synchrone Komm;


PERSISTEND: Eine Nachricht wird so lange von der Kommunikations-Middleware gespeichert, wie es dauert, sie an den Empfänger auszuliefern.
TRANSIENT: Eine Nachricht wird nur so lange gespeichert, wie die sendende und empfangende Anwendung ausgeführt wird.
ASYNCHRONUS: Sender continues immediately after submisssion
SYNCHRONOUS: Sender is blocked unitl: Start buffering at receiving host OR Finished delivering to receiver OR receiver has processed


### 7.(F)Angenommen, Ihnen stehen nur transiente asynchrone Kommunikationsbefehle zur Verfügung (also auch nur nicht-blockierendes "receive"). Wie kann man damit - quasi eine Schicht darüber - transiente synchrone Kommunikation realisieren?
Consider a synchronus send primitive. A simle implementation is to send a message to the server using asynchronous communications, and subsequently let the caller countinously poll for an incoming acknowledgement or response from the server. If we assume that the local operating system stores incoming messages into a local buffer, then an alternative implementation is to block the caller until it receives a signal from the OS that a message has arrived, after which the caller does an asynchronous receive.

### 8.(F)Angenommen, Ihnen stehen nur transiente synchrone Kommunikationsbefehle zur Verfügung. Wie kann man damit - quasi eine Schicht darüber - transiente asynchrone Kommunikation realisieren?

### 9.Erläutern Sie die Grundprinzipien von Message-orientierter persistenter Kommunikation (Message-Queueing Model) und gehen Sie auf CORBA Messaging exemplarisch ein.
**Definition:**
Message orientierte Kommunikation basiert auf Nachrichten, die zwischen den einzelnen Systemen hin und hergeschickt werden und bieten Unterstützung für persistente/transiente, synchrone/asynchrone Kommunikation (MoM: persistent asynchron durch Queues; Message Passing Interface: transient synchron/asynchron).

**Grundidee:**
bei einem message-queueing System ist, dass Applikationen über das Einfügen von Nachrichten in eine spezifische queue kommunizieren. Ein wichter Aspekt dabei ist, dass es zwar eine Garantie gibt, dass die Message der queue hinzugefügt wird, aber keine Garantie dafür wann, oder gar ob die Nachricht gelesen wird. Es ist also nicht erforderlich, dass der Empfänger ausgeführt wird, wenn eine Nachricht an seine message queue gesendet wird. Analog dazu ist es nicht erforderlich, dass der Sender ausgeführt wird, wenn die Nachricht vom Empfänger entgegengenommen wird. Sender und Empfänger können völlig unabhängig voneinander ausgeführt werden.
Wichtig ist bei der Kommunikation, dass die Nachricht aus der Sicht der Middleware korrekt addressiert sind. In der Praxis erfolgt die Addressierung durch die Angabe eines systemübergreifenden, eindeutigen Namen der message-queue des Empfängers.

**Basic interface für Applikationen:**
* Put (nonblocking)- Eine Nachricht der message queue hinzufügen
* Get (blocking)- Blockt, bis die queue etwas enthälund die erste Nachricht darauf entfernt
* Poll (nonblocking)- Queue auf Nachrichten überprüfen und die Erste daraus entfernen
* Notify - Handler installieren, der aufgerufen wird, wenn eine neue Nachricht in der Queue ist.

**CORBA Messaging:**
verbindet Methodenaufrufe und objektbasierte Nachrichtenübermittlung miteinander. Objektbasierte Nachrichtenübermittlung ist eine Charakteristik von CORBA und stellt dafür prinzipill einen Nachrichtendienst zur Verfügung, über den **persistente asynchrone Kommunikation** trotz konsequenter objektbasierter Handhabung möglich wird. Zu jeder ursprünglichen Schnittstelle werden 2 neue Schnittstellen erzeugt, wobei eine dem Aufruf dient (Parameter enthalten keine Return Werte)

**Callback-Model:**
Eine Schnittstelle fungiert als Callback (Parameter sind Rückgabewerte der urspr. Schnittstelle) SObald eine Antwort eintriffe, wird der Callback mit dem Return Wert des Anrufs ausgelöst. (Resultat der Invocation wird automatisch an Anwendungsebene weitergegeben, sobald sie verfügbar ist). Der Client muss eine Implementierung des Callbacks zur Verfügung stellen.

**Polling-Mode**
Besitzt eine Schnittstelle (Parameter sind Rückgabewerte der urspr. Schnittstelle), welche es der Anwendungsebene erlaubt, eingegangene Nachrichten (Resultate der Invocation) abzufragen. Dies muss von der Anwendungsebene explizit angestossen werden.

Beide Methoden können aus der ursprünglichen Schnittstelle automatisch generiert werden. Es bleibt dem Client überlassen, sich für synchrone oder asyncrhone Kommunikation zu entscheiden.

### 10.Was versteht man unter "Message-oriented Middleware MoM"? Erläutern Sie Modell und Architektur solcher "Message-Queueing"-Systeme. Gehen Sie insbesonders auf den Begriff des Message Brokers und dessen Bedeutung für EAI ein.
**Definition**
Message-queuing System = **Message-oriented Middleware (MoM)**
**Unterstützung** für **persistente asynchrone Kommunikation** und **zwischenliegende Speicherkapazität** müssen. Jede **Applikation** hat seine **eigene queue**. Sender erhält nur die Garantie, dass seine Nachricht irgendwann einmal in die queue des Empfängers eingefügt wird. Keine Aussage darüber wann und ob die Nachricht tatsächlich gelsene wird. Die Übertragung von der Middleware zum Server kann länger als nur einige Sekunden dauern.

**Combinations** for **communications** using **queues** for **persistent communication** (f.e. Email is a message queueing system)

**Architektur:
* **einschränkung:** Nachrichten könnenn **message queues** nur **hinzugefügt** werden, die für den Sender **lokal** sind. Eine solche Message queue heißt **source queue**. Eine in die message queue gestellte Nachricht enthält die Angabe einer **destination queue**. an die sie übermittelt werden soll. genau so können **Nachrichten** nur von **lokalen** message queues **gelesen** werden.
* **Aufgabe des message-queuing systems:** sendern und Empfängern queues zur Verfügung stellen und **nachrichten von source zu destination queue** zu übertragen. Queues können über das ganze **Netzwerk verteilt** sein, deshalt sollte das System eine **Datenbank von message queue Namen** führen mit einer Zuordnung zu ihrere Position im Netzwerk. Diese Zuordnung ist analog zur Verwendung von DNS für E-Mail im Internet.

**Queue manager:**
Normalerweise **kommuniziert** der Manager direkt **mit der Anwendung**, die eine **Nachricht sendet oder empfängt**. Es gibt auch **besondere Manager**, die als **Router** oder **Relays** arbeiten. Solche leiten eingehende Nachrichten **an anderer Manager weiter**. In vielen message-queuing Systemen gibt es z.B. **keinen allgemeinen Namendienst**, der eine dynamische Zuordnung von Warteschlangen zu Positionen enthält. **Topologie** ist stattdessen **statisch** und jeder Manager benötigt eine Kopie der Zuordnung was in großen Systemen **Probleme in der Netzwerkverwaltung** verursacht. **Lösung** sind **Router**, welche die **Netzwerktopologie kennen**. Wenn sich in der Topologie etwas ändert müssen nur die **Router aktualisiert** werden und **nicht jeder einzelne Manager**. Die Manager müssen nur wissen, wo der **nächste Router** ist.
The **genereal organizsation** of a message-queueing system with routers/relays: topology, multicastin and secondary processing.
**Manuelle Konfiguration** wird in wachsenden Netzwerken dennoch schnell vollkommen unhandlich. Einzige Lösung: dynamisches Routing-Verfahren wie in Computerentzten
**Weitere Gründ für den Einsatz von Relays:**
* Ermöglichen Sekundärverarbeitung der Nachrichten
* Nachrichten können aus Gründen der **Sicherheit** oder **Fehlertoleranz protokolliert** werden.
* Relays können auch für **Multicasting** Zwecke eingesetzt werden.

**Message Broker:** (Besondere Relay-Form)
Dient als Gateway und bringt Nachrichten in ein Format, das vom Empfänger verstanden werden kann. Wichtiger Anwendungsbreich von message queue Systemen: Integration vorhandener und neuer Anwendung in ein einzelnes, zusammenhängendes, verteiltes Informationssystem. Die Anwendungen müssen die Nachrichten verstehen, die sie erhalten -> die ausgehenden Nachrichten des Senders müssen das Format der Empfängers haben.
Zusätzlich zu seiner Hauptaufgabe kann ein Message-Broker jedoch noch andere Aufgaben erfüllen - so wird ein Message-Broker etwa für EAI(Enterprise Application Integration) verwendet. Hierbei handelt es sich um ein sogenanntes Publish/Subscribe-Modell. Hierbei senden Anwendungen Veröffentlichungen zum Thema X an den Broker, der diese Veröffentlichungen dann an andere Anwendungen, die Thema X aboniert haben, weiterleitet.

**Problem:**
Jedes Mal wenn eine neue Anwendung zum System hinzukommt, die ein gesondertes Nachrichtenformat erfordert, muss jeder mögliche Empfänger eingestllt werden, um dieses Format zu erzeugen.

**Alternative**
Auf ein allgemeines Nachrichtenformat einigen. Funktioniert bei message-queue Systemen im allgmeinen aber nicht. Die Prozesse haben nicht genügend Gemeinsamkeiten für ein allgemeines Format. Deshalb arbeitet man doch eher mit Umwandlungen welche an besonderen Knoten im Netzwerk vorgenommen, die als Message Broker zu bezeichnet werden. Message broker sind lediglich eine weitere Anwendung, kein fester Bestandteil des message queueing Systems

**Anwendungsbsp:**
Tabelle aus einer DB, in der Sätze durch einen bestimmten Begrenzer getrennt werden und Felder in einem Satz eine bekannte fest Länge haben. Destination application verwenden zwischen den Sätzen einen anderen Begrenzer und erwartet Felder mit variabler Länge. Umwandlung zwischen 2 unterschiedlichen DB-Anwendungen. Es kann häufig nicht garantiert werden, dass alle in der eingehenden Nachricht enthaltenen Informationen tatsächlich in geeignerter Weise für die ausgehende Nachricht umgewandelt werden können.

**EAI(Enterprise Application integration):**
Hier ist der Einsatz eines MessageBrokes verbeitet. Broker ist dabei nicht (nur)dafür zuständig, Nachrichten umzuwandeln, sondern auf Grundlage der ausgetauschten Nachrichten die passende Anwendung auszuwählen(Publish/subscribe Modell). Anwendungen senden Nachricten in Form von öffentlichen eine Nachricht zum Thema X. Diese Nachricht wird an den Broker gesendet. Broker sendet Nachricht an jene Anwendungen, die solche Nachrichten aboniert haben.
Vorteil: Sender und Empfänger müssen sich nicht kennen. Broker erledigts.