Hallo zusammen! In der dritten Aufgabe arbeitet ihr noch einmal mit eurem eigenen Fernaufrufssystem

auf Basis von Java RMI. Dieses Mal stellt ihr Fehlertoleranzmechanismen in Form von

verschiedenen Aufrufssematiken bereit, um zum Beispiel den Verlust von Nachrichten zu

tolerieren. Zum Testen der neuen Funktionalität simuliert ihr dann Fehler in eurem Kommunikationssystem.

Schauen wir wieder kurz auf unser Klassendiagramm. Die Fernaufrufssematik kann pro Operation

angegeben werden. Da definiert ihr für euren Auktionsdienst für jede Methode eine dafür

sinnvolle Semantik. Die Umsetzung der Semantiken geschieht dann in Stub und Skeleton. Genauer

gesagt im VS Invocation-Händler beim Client und VS Server auf Serverseite. Ihr stellt

dabei ein oder zwei Semantiken zur Verfügung, last of many und add it most once, wobei letztere

nur für 7,5 ECTS benötigt wird. Zum Testen der neuen Semantiken sollen zudem Fehler wie

der Verlust oder das Verzögern von Nachrichten eingeschleust werden. Das kann zum Beispiel

in einer neuen Klasse VS Buggy Object Connection geschehen. Ihr dürft hier aber auch eigene

Ideen entwickeln.

Für die Implementierung der zwei Semantiken braucht es einige Änderungen an eurem Fernaufrufsystem.

Für last of many müsst ihr euren Aufrufen z. B. eindürge Addies und für mehrfache Versuche

Sequenznummern zuweisen. Zudem braucht es Timeouts, um zu definieren, ab wann ein Aufruf

als fehlgeschlagen angesehen wird. Bei add most once ist es zudem wichtig, dass eine

Anfrage maximal einmal ausgeführt wird. Das Ergebnis muss sich also gespeichert werden

und wie bei allem, was man speichert, braucht es in dem Fall auch wieder eine garbage collection.

Mehr Details zu den einzelnen Semantiken findet ihr im zugehörigen Video.

Welche Fernaufrufssematik dabei verwendet wird, soll für jede Methode einzeln festgelegt

werden können. Dies soll durch eine Annotierung im Interface durch den Anwendungsentwickler

ermöglicht werden und wird dann zur Laufzeit von eurem Fernaufrufssystem ausgewertet.

Annotationen sind eine Möglichkeit, Metadaten im Quelltext zu hinterlassen. Häufig dienen

sie als Markierungen für die Programmierer oder werden von der IDI oder auch bei der

Übersetzung verwendet. Man kann sie aber auch zur Laufzeit auflesen.

Hier ein Beispiel, wie man eigene Annotationen definiert. Es sollen Methoden als Lesen oder

Schreiben annotiert werden. Um einer Annotation verschiedene Werte zuweisen zu können, also

schreibend oder lesend, definiert man ein Hilfs-Inam. In unserem Beispiel das Inam

Thou's Method Type mit den beiden Werten ReadAccess und WriteAccess.

Die Annotation selbst definiert man dann mit dem Keyboard Add Interface, wie hier im Beispiel.

Die Add Retention Annotation der Annotation selbst definiert, wann die Annotation weggeworfen

wird, also wie lange sie sichtbar bleibt. Wir wollen unsere Annotation zur Laufzeit

auslesen können und nehmen daher die Retention Policy Runtime. Es gibt auch andere Möglichkeiten

und dann wird die Annotation zum Beispiel vor der Übersetzung oder nach der Übersetzung

weggeworfen. Durch den Rückgabetyp der Standardmethode

Value definieren wir zudem die Werte, die unsere Annotation annehmen kann, also unser

Inam Thou's Method Type. Unsere Annotation setzen wir dann ganz gewohnt mit dem vorgestellten

Add ein. Den Wert der Annotation übergeben wir als Parameter. Ein zusätzlicher Hinweis,

wenn der Wert sich vom Rückgabetyp der Value-Funktion unterscheiden soll und einer anderen Funktion

angehört, muss diese explizit angegeben werden, wie hier auf der Folie unten im Beispiel für

Foo. Um unser Beispiel weiterzuspinnen, haben wir

in einem Interface VS Key Value Store zwei Methoden annotiert. Die Put-Methode als schreibend

und die Get-Methode als lesend. Jetzt wollen wir zur Laufzeit analysieren, welche Annotation

unsere Methode jeweils hat. Das geht wieder mit der aus der letzten Aufgabe schon bekannten

Reflection API. Wenn man ein Method-Objekt für eine Methode

hat, hat man dort die Methode GetAnnotation. Diese sucht nach einer speziellen Annotation

und erwartet daher die Klasse der Annotation als Parameter. Hier unsere VSAnnotation.class.

Wenn die Methode eine derartige Annotation hat, wird sie von der Methode zurückgegeben.

Wenn nicht, bekommt man einfach Null zurück. Aus diesem VSAnnotation-Objekt, das wir bekommen,