Hallo zusammen, in der zweiten Aufgabe baut ihr auf eure Implementierung aus Aufgabe 1

auf und tauscht Java RMI gegen euer eigenes Fernruf-System aus.

Im Rahmen dieses Videos geht es dabei zuerst um Stubs, die auf kleinen Seiten als Stellvertreter

des Servers stehen, dann um Skeletons auf Serverseite, die als Stellvertreter des Aufrufers,

also des Clients, fungieren und am Schluss noch darum, wie Remote-Objekte zwischen Servern identifiziert

werden.

Schauen wir uns jetzt zuerst das Konzept eines Stubs an.

Fernaufrufe in einem System wie Java RMI sollen so transparent wie möglich geschehen.

Das bedeutet, dass der Anwender nicht merken soll, dass es sich bei einem Methodenaufruf

gerade um einen Fernaufruf handelt.

Fernaufrufe sollen also genauso wie normale lokale Aufrufe verwendet werden können.

Ein wichtiger Teil dieser Transparenz sind Stubs.

Ein Stub ist ein Stellvertreter eines entfernten Objekts.

Der Stub implementiert dabei die Schnittstelle des entfernten Objekts, der Aufrufer kann

ihn damit genauso verwenden, als ob er ein lokales Objekt von diesem Typ verwenden würde.

Intern füllt der Stub die Anfrage dann aber natürlich nicht direkt aus, sondern leitet

sie an das zugehörige entfernte Objekt am Server weiter, damit sie dort ausgeführt werden

kann.

Die zentrale Aufgabe des Stubs ist also die Umwandlung des lokalen Methodenaufrufs in

ein Fernaufruf.

Die folgenden Einzelschritte sind dabei wichtig.

Aus dem lokalen Methodenaufruf muss eine Anfragenachricht erzeugt werden.

Diese muss eine eindeutige Identifizierung des jeweiligen Methodenaufrufs auf Serverseite

ermöglichen, also welcher Prozess ist gemein und welches Objekt darin und welche Methode

genau.

Zudem müssen alle Parameter der Methode mit in die Nachricht gepackt werden.

Diese Nachricht muss anschließend über das Kommunikationssystem an den Server gesendet

werden, der dann die Methode ausführt.

Nach erfolgreicher Ausführung bekommt der Stub vom Server eine Antwortnachricht geschickt.

Diese enthält unter anderem auch den Rückgabewert der Methode, der dann natürlich wieder ausgepackt

werden muss und anschließend in den Aufruf zurückgegeben wird.

Der Aufruf erhält jetzt, wie bei einem normalen Methodenaufruf auch, den Rückgabewert und

merkt, bis auf eine etwas höhere Latenz, nichts davon, dass gerade ein Fernaufruf stattgefunden

hat.

Schauen wir uns das Konzept nochmal an einem kurzen Beispiel an.

Wir wollen ein Hello-Welt-Service als entferntes Objekt anbieten.

Darüber braucht es zuerst eine Schnittstelle mit allen als Fernaufruf angebotenen Methoden.

In unserem Beispiel haben wir ein Setter und ein Getter für den Namen und die Methode

SayHello.

Natürlich brauchen wir auch eine tatsächliche Implementierung des Interfaces, das hier die

Methode SetName, GetName und SayHello implementiert.

Soweit so gut.

Die lokale Nutzung des Objekts wäre damit schon mal möglich.

Für einen Fernaufruf brauchen wir jetzt neben der tatsächlichen Implementierung, die nachher

auf Serverseite läuft, auch einen Stub, der auf kleinen Seiten zur Verfügung gestellt

werden kann.

Dieser implementiert ebenfalls das Interface.

Anstatt die Methoden direkt auszuführen, verpackt er an der Stelle aber jetzt den Aufruf

und die Parameter in eine Anfragenachricht und sendet diese an den Server.

Wenn eine Methode ein Rückgabewert hat, wie zum Beispiel hier GetName, wird von Stub zudem