RMI Gui auf client updaten basierend auf den Property Änderung des Models auf dem Server ohne polling

[Dennis4]

Hallo an alle,
ich sitze seit einiger Zeit an einem Problem mit RMI und dem MVC Prinzip.

Man Stelle sich vor es gäbe drei Klassen, ein Model, ein View und ein Controller. Der Controller fungiert als Bridge zwischen Model und View.
View und Controller liegen auf dem Server und die View liegt auf dem Client.
Der Controller hat Referenzen zum Model und zur View. Der Controller implementiert das PropertyChangeListener Interface und registriert sich beim Model als solches. Treten beim Model Property Veränderung auf wird ein PropertyChangeEvent erzeugt und mit firePropertyChange der Controller benachrichtigt.
Der Controller propagiert das Event weiter and die View, welche sich dann entsprechend den neuen Werten anpasst.
So Weit so Gut. Nun gibt es ein Problem, da der Controller eine Referenz zur View benötigt, wird diese durch RMI serialisiert. Dies möchte oder muss ich aber vermeiden, da ich es nicht sinnvoll finde die Komplette Gui zu serialisieren. Ein weiterer Punkt, es geht auch nicht.
Ich habe die View mit Hilfe von Matisse erzeugt und das von Matisse verwendete GroupLayout implementiert nicht das Serializable interface.
Dementsprechend wirft RMI auch die NotSerializableException.

Gibt es nun eine Möglichkeit die MVC Architektur beizubehalten über RMI? Die einzige Möglichkeit, die ich bisher gefunden habe wäre ein Polling von der Clientseite aus um nach Änderungen zu fragen. Polling find ich aber in diesem Zusammenhang nicht sehr schön und frisst auch mehr Ressourcen.

Ich hoffe damit wird mein Problem klar und hoffe ihr könnt mir helfen.
Sollte es weiter Fragen geben kann ich auch noch schnell ein simples Beispiel implementieren.

Danke im Voraus.
Dennis

 

[Marcinek]

Nein das geht nicht mit dem java native rmi.

Es gibt implementierungen von rmi, die es erlauben an das Socket der RMI connection zu kommen. Damit kannst du vom Server über die bestehende Verbindung eine Nachricht an den Client zu schicken.

Daafür registrierst du so callback handler.

Ich meine diese Implementierung heißt: Easy RMI.

Aber ich finde das gerade nicht.

 

[Dennis4]

Hallo,
Danke erstmal für die Antwort.

Heißt das nicht, das RMI gänzlich ungeeignet ist für Applikation mit einer Grafischen Oberfläche?
Ich habe irgendwo gelesen, dass man nicht davon ausgehen soll, die GUI Komponenten von Java würden Serialisierbar bleiben.

Ausgenommen sind natürlich applikation deren GUI sich nicht an das dahinterliegende Model anpasst.

Grüße
Dennis

 

[Marcinek]

Ich verstehe deine Aussage nicht. Hier scheinen einfach mehrere Fachbegriffe in ein Posting gepackt und mit Verben verbunden.

Natürlich kannst du mit RMI mit einer GUI nutzen. Alle Informationen, die auf dem Client angezeigt werden müssen durch den Client selbst abgefragt werden.

Der Server kann nicht sagen. So nun sende ich dir die Daten, die du vor einer Stunde angefragt hast. Dazu eigent sich das klassische RMI nicht.

Der Controller ist einfach in zwei gesplittet. Du würdest einen Teil in der GUI und einen anderen Teil auf dem Server implementieren.

Der Controller im Client würde wirlich nur GUI Elemente auslesen und dann serialisieren und zum Server scicken. Auf keinen Fall würdest du Events der GUI in den Server schicken. DAs muss getrennt sein, sonst würde man sich dazu verleitet führen im Server Textfield.setText() zu machen, was auf keinen Fall funktionieren würde.

 

[irgendjemand]

ich wüde MVC noch nicht mal so trennen ... sondern alles client-seitig implementieren ...
auf dem server läuft dann vielleicht noch MC *also ohne view* ...
die schnittstellen zwischen beiden stellen würde ich selbst implementieren das man a-sync von einem zum anderen schicken kann *beduetet das eine seite informationen schicken kann ohne das diese von der anderen angefordert wurde*

wenn dann auf dem server eine veränderung des Model festgestellt wird kümmert sich der Controller auf dem server dem Controller auf dem client diese informationen mitzuteilen ...
dieser aktualisiert darauf hin sein lokales Model *zum cachen* und dann entsprechend seinen View ...

aber das gesamte pattern so krass trennen und über mehrere knoten hinweg ausdehnen ... das halte ich dann doch für aufwändiger anstatt eine eigene , schnelle schnittstelle zu implementieren

 

[Dennis4]

"Alle Informationen, die auf dem Client angezeigt werden müssen durch den Client selbst abgefragt werden."

Das ist genau was ich meine. Die einzige Möglichkeit eine GUI mit RMI zu realisieren heißt der Client muss den Server pollen, ob veränderungen eingetreten sind. Es gibt soweit ich das sehe keine Möglichkeit bei Veränderungen im Model auf dem Server, die GUI entsprechend über diese Veränderungen zu informieren.

Bei mir wäre es so wie "irgendjemand" gesagt hat. Ich habe MC auf dem Server und das V auf dem Client mit einem quasi mini Controller der dem Server die Informationen über die GUI Events vermittelt.

Man stelle sich nun andere Fälle vor, die Client View muss in echtzeit aktualisiert werden, weil es um Millisekunden geht(Beispiel Spiele?), da kann Polling doch nicht die Lösung sein oder doch?

 

[irgendjemand]

du hast nicht ganz verstanden wie ich das meinte

nach deiner aktuellen auffassung muss der client beim server nachfragen ...

auch wenn ich mich jetzt nicht mit RMI auskenne würde ich jedoch behaupten das eine a-sync verbindung möglich ist ... also das beide seiten zwar in einem thread auf daten vom anderen warten ... aber unabhängig davon auch beliebig daten senden können ...
das sollte mit RMI umsetzt bar sein ...

falls nicht : selbst implementieren

 

[Marcinek]

Was der TO sucht ist ein RMI Callback.

Aber das ist so nicht vorhanden. Da muss man auf andere Implementierungen zurückgreifen.

Bei kaufmännischen Anwendungen ist das aber imho nicht notwendig und spiele sollten eigene effiziente Protokolle implementieren.

 

[Dennis4]

Also, ich habe mich mal erkundigt nach RMI Callback.

Danke auf jeden Fall für den Hinweis mit RMI Callback. Ich habe jetzt auf Clientseite dem Client ein Remote Interface verpasst und mit UnicastRemoteObject.exportObject automatisch einen stub erstellt. Jetzt wo der Stub vorhanden ist, wird die GUI nicht mehr serialisiert, sondern nur der Stub, der mit der Grafischen Oberfläche nichts zu tun hat übergeben.

Also zusammengefasst:
Es funktioniert jetzt ohne Polling und nach dem MVC Modell.

Danke an alle.

 

[tuxedo]

Wenn die Anwendung nicht nur im lokalen Netz, sondern auch über's Internet funktionieren soll, wirst du mit dem RMI Callback-Verfahren Probleme bekommen: RMI Callback-Problem

Gruß
Alex

 

[irgendjemand]

wesshalb ich ja auch bereits den tipp gegeben habe : verbindung selbst implementieren ...

denn MVC ist wenn überhaupt nur sehr schlecht auf die art und weise ... "trennbar" wie TO es hier versucht ...

 

[tuxedo]

Wieso selbst implementieren wenn es bereits eine Lösung zum RMI Callback-Problem gibt?? (siehe Link)

 

[Dennis4]

Danke ich seh mir das auf jeden Fall an wenn es denn soweit ist bis jetzt funktioniert es ja alles^^.