RMI RMI - Begriffe erklären

[karmenStefani_1]

Hallo Liebes Forum-Team,

Kann mir jemand vielleicht die Folgende Frage beantworten:

1. Erläutern Sie die Begriffe Server Interface, Server Object und Client bei RMI.

// Ich hab gegoogelt und nichts passendes gefunden ;-(

2. Soweit ich es verstanden habe ist RMI nur für Programmierier interessant und es ist sozusagen eine Entwicklungsumgebung??
Der Anwendunsprogrammier sucht eine Methode um diese für in seinem Programm einzubinden, sucht über Stub auf dem Registery bekommt dort ein Referenz auf einem Objekt.
// Achtung
Danach sobald die Methode. inkl. Adresse gefunden wurde wird eine Verbindung auf dem Host wo sich die Methode befindet zwischen stub und skeleton aufgebaut und Programmcode ausgetauscht???? RICHTIG???

// Mein Wissensstand

Nach dem die Methode auf dem anderen Server gefunden wurde z.B. addiereZweiZahlen()
bindet der Programmierier dies in seinem Programm und arbeitet damit????

Ich bitte um Hilfe und ob ich mit meinem Wissen richtig lege.

Danke
Stefani

 

[Niki]

Nicht so ganz:

Der Client sucht auf einem entfernten Rechner in einer Registry mit einem Service-Namen nach einem Service. Wird ein Objekt unter diesem Namen gefunden, bekommt der Client davon den Stub. Das Objekt implementiert dabei ein Interface welches das Remote-Interface erweitert. Der Client kann jetzt auf diesem Objekt Methodenaufrufe (die vom Interface vorgegeben werden) ausführen, die jedoch auf dem Server ausgeführt werden. Daher der name Remote Method Invocation

 

[karmenStefani_1]

Besten Dank für die Antwort.

Also. Nach dem der Client eine Methode auf dem Registery-Server lokalisiert hat , bekommt der vom SERVER einen STUB, damit kann er dann die Interaktion zwischen dem Server wo sich die Methode befindet unn dem Client gewährleistet.

// Hätte gerne noch die Antwort für diese Frage:

1. Erläutern Sie die Begriffe Server Interface, Server Object und Client bei RMI.

Gruss
Stefani

 

[tuxedo]

1. Erläutern Sie die Begriffe Server Interface, Server Object und Client bei RMI.

Gruss
Stefani

Server Interface: Eine Schnittstelle, die der Server Clients zur Verfügung stellt

Server Objekt: Ein Objekt das ein Serverinterface implementiert.

Client: Ein Client der sich zu einem Server verbinden kann, ein "lookup" auf ein entferntes Objekt machen, und dieses Objekt dann anhand des Server Interfaces benutzen kann.

Hat alles in allem enorm wenig mit RMI zu tun. Ist mehr "plain java", "gesunder Entwicklerverstand" und "RPC" zuzuordnen ;-)

- Alex

 

[Niki]

der Client lokalisiert keine Methode am Server sondern fragt nach einem Objekt, welches unter einem Namen in der RMI-Registry abgespeichert ist. Existiert so ein Objekt, kann der Client von dem Objekt Methoden aufrufen, die am Server ausgeführt werden. Es gibt sicher hunderte Tutorials im Internet, die dir das Prinzip gut erklären. Am besten ist, du probierst es einfach aus, das macht das ganze wesentlich verständlicher als irgendeine Theorie.

zu deiner Frage:

Server Interface:
Das ist das Interface welches das Remote Object implementieren muss. Die Methoden, die das Interface definiert, können dann in weiterer Folge vom Client aufgerufen werden. Das Interface selbst muss das Interface "Remote" erweitern

Server Object:
Dies ist das Objekt welches das Remote Interface implementiert. Es muss entweder von UnicastRemoteObject abgeleitet werden oder exportiert werden. Das Objekt wird in der Registry registriert und kann von Clients "abgeholt" werden

Client:
Dies ist der Programmteil der den Stub vom Server erhält und die entfernten Methoden aufruft. Der Begriff sollte durch die oberen Erklärungen von selbst erklärt sein.

 

[karmenStefani_1]

So, die Kommunikation läuft zwischen Client und Server Synchron d.h. es wird eine Anfrage wird gesendet und der Client warter bis die Antwort kommt bis dahin ist der Client blockiert. Nun ist der Server auch in der Zeit wo die Bearbeitung stattfindet blockiert?
Welche Nachteile hat die Synchron-Übertragung???

 

[tuxedo]

So, die Kommunikation läuft zwischen Client und Server Synchron

Das könnte ich jetzt so nicht sofort unterschreiben ...

d.h. es wird eine Anfrage wird gesendet und der Client warter bis die Antwort kommt bis dahin ist der Client blockiert.

Korrekt. Aber in erster Linie ist das nur der Thread auf Clientseite in dem der Methodenaufruf getätigt wird. Der Kommunikationskanal ist derweil aber frei für andere Methodenaufrufe aus anderen Threads.

Nun ist der Server auch in der Zeit wo die Bearbeitung stattfindet blockiert?

Der Server ist nur im Thread, der die Bearbeitung und Ausführung des Methodenausrufs behandelt blockiert. Alles andere, läuft frei.

Welche Nachteile hat die Synchron-Übertragung???

Welche Synchron-Übertragung?

Dass ein Methodenaufruf solange dauert wie er dauert und dass ich in diesem Thread dann keine anderen Methoden zu dieser Zeit aufrufen kann, gilt auch für Umgebungen in denen keine Netzwerkkommunikation und/oder RMI/RPC zum Einsatz kommt.

- Alex

 

[karmenStefani_1]

Also, diese "Thread" beziehen sich auf dem Betriebssystem??. Da der Prozessor viele Threads erzeugen kann wird somit quasi parallel laufen alles?
Beispiel:

Client ruft eine Methode addiereZahl(); auf und schickt sie an dem Server.
Server kennt die Methode und führt die gewünschte Operation durch.
An dem Prozess waren von Client-Seite ThreadX und auf Server-Seite ThreadY beteiligt. Diese sind solange blockiert bis der Fall abgeschlossen ist und neben bei kann Client andere Threads an die Arbeit schicken die ähnliche Anfragen entgegen nehmen können.

 

[tuxedo]

Also, diese "Thread" beziehen sich auf dem Betriebssystem??. Da der Prozessor viele Threads erzeugen kann wird somit quasi parallel laufen alles?

[yoda]nicht alles durcheinander bringen du musst[/yoda]

Ein Thread wird im Endeffekt vom Betriebssystem angelegt, und nicht vom Prozessor. Ein Thread gehört zu einem Prozess (die Dinger die du im Windows TaskManager siehst).

Das Betriebssystem gibt jedem Thread eines Prozesses nach einem bestimmten Schema Ausführungszeit der CPU. Das heisst, die Threads werden in kleinen Stückchen nacheinander und nicht parallel ausgeführt (bezieht sich auf einen CPU-Kern. Mehrere Kerne können natürlich parallel laufen). Da das aber sehr schnell passiert, erscheint die Ausführung mehrere Threads quasi-parallel. Und mit Multi-Core CPUs geht's dann richtig parallel. Ein 4-Kern-System kann 4 Threads tatsächlich zur selben Zeit ausführen.

Beispiel:

Client ruft eine Methode addiereZahl(); auf und schickt sie an dem Server.

falsch.

Der Client schickt den wunsch, die Methode "addiereZahl()" aufzurufen an den Server.

Server kennt die Methode und führt die gewünschte Operation durch.

... und liefert das Aufrufergebis zurück an den Client, der dann denkt, er hätte die Methode selbst ausgeführt. Dabei war's der Server.

An dem Prozess waren von Client-Seite ThreadX und auf Server-Seite ThreadY beteiligt. Diese sind solange blockiert bis der Fall abgeschlossen ist und neben bei kann Client andere Threads an die Arbeit schicken die ähnliche Anfragen entgegen nehmen können.

Jepp, das kann man so sagen.

 

[karmenStefani_1]

Danke,

Mit Threads hast du vollkommen recht hab was durcheinander gebracht.

Kannst du mit bitte ein Beispiel basteln, wie dieses Zusammenspiel zwischen Client und Sever funktioniert und wie die Methoden aufgerufen und abgearbeitet, wie sie zurückkommen. Ich bin mir irgendwie nicht ganz sichter alles verstanden zu haben.


Ich bin euch sehr DANKBAR.

 

[tuxedo]

Das macht doch alles RMI für dich und ist nahezu uninteressant.

Ob ein Programm nun ein lokales, eigenes Objekt benutzt, oder ein entferntes Remote-Objekt ändert nichts an dem Verhalten. Der Thread in dem der Aufruf passiert blockiert solange bis der Aufruf beendet ist. Das ist mit und ohne RMI so.

Und der Server hält idealerweise für jeden Client mindestens einen Thread bereit (wieviele weiß man bei RMI nicht so genau... ist nicht wirklich dokumentiert). RMI funktioniert auf Serverseite komplett entkoppelt. D.h. mehrere Methodenaufrufe von einem oder mehreren Clients können gleichzeitig abgearbeitet werden. Sofern du in einer Serverobjekt-Implementierung keine blockierenden Abhängigkeiten/Synchronisationen eingebaut hast, kommt sich da auch nix in die Quere. Wenn du mit "blockierenden Abhängigkeiten/Synchronisationen" nix anfangen kannst, schlage ich vor dass du mal in der JavaInsel (oder ähnlichem) nach "synchronized", "deadlock" und "thread" suchst und die entsprechenden Kapitel liest. Das ist nix was man "mal eben schnell in 3 Sätzen erklären kann".

Allgemein zu RMI: Die genauen internas sind ziemlich "mysteriös". Kaum einer weiß was da wirklich vor sich geht. Zumindest nicht ohne den recht umfangreichen Code unter die Lupe genommen zu haben.

Genaues kann ich dir nur zu den Internas von SIMON sagen. Das funktioniert im Prinzip "aussen" ähnlich. Innen sieht's aber komplett anders aus.

- Alex

 

[karmenStefani_1]

Ich danke euch noch mal.

Werde nun weiter lesen und wenn fragen auftrauchen melde ich mich ;-)
schönen Tag noch

 

[Niki]

vielleicht noch ergänzend zu dem Thema synchronized und RMI. Soweit ich mich erinnern kann arbeiten alle Clients mit dem selben Remote Object aus der Registry. Willst du wirklich für jeden Client ein eigenes Remote Object haben, muss das Remote Object vom Server wieder ein Remote Object erzeugen und dieses an den Client zurück liefern. Der Server ist dann so intelliegent und weiß, dass es nicht das eigentliche Objekt an den Client schicken muss, sondern den Stub.
Man möge mich bitte ausbessern wenn ich falsch liege. Ist schon lange her dass ich mit RMI gearbeitet habe.

 

[tuxedo]

Das ist soweit korrekt. Gebrauchen kann man sowas unter anderem prima für Logins:

ServerObjekt bietet z.B. folgende Methode an:

public Session login(String user, String pass) throws RemoteException {
   if (isValid(user,pass)){
      return new SessionImpl(user);
   }
   return null;
}

"Session" ist hierbei ein Interface das vom "Remote" erbt. SessionImpl ist die entsprechende Implementierung.

Das ServerObjekt selbst bietet nur die Login-Methode an. Alle anderen Methoden bekommt der Client nach einem erfolgreichen Login via SessionObjekt zur Verfügung gestellt.

Obiges Beispiel ist nur sehr rudimentär.. Natürlich sollte man das Session-Objekt nicht einfach erzeugen und dem Client geben ohne sich selbst eine Referenz darauf in einer Liste oder Map zu merken etc...

- Alex