RMI vs REST oder doch was anderes?

D

Der Wolf

Erfahrenes Mitglied
Hallo und guten Morgen,

ich wollte euch mal nach eurer Meinung zum Thema Remote-Control fragen. Folgendes Szenario dazu: Ich habe eine Applikation geschrieben, die auf einer Client Maschine läuft und verschiedene Sensor-Daten verarbeitet. Um die internen Parameter setzen und die Ergebnisse der Verarbeitung anzeigen lassen zu können, hätte ich gerne eine weitere Applikation die sich von einem anderen Rechner aus mit der datenerzeugenden App verbinden kann.

Ich habe schon ein wenig mit jetty experimentiert und mir auch schon ein wenig die Haare bei Versuchen mit Java RMI gerauft. Die meisten Parameter könnte ich über die REST API einstellen, das ist weniger das Problem. Allerdings werden einige der internen Berechnungen mehrmals pro Sekunde durchgeführt (teilweise alle 20 Millisekunden). Ich frage mich nun, ob ich diese Ergebnisse auch über die REST API und meinen Jetty Server an meine Remote-Control App schicken lassen sollte oder lieber die Java RMI Funktionalität verwenden sollte. Oder vielleicht etwas ganz anderes, da RMI anscheinend überholt ist? Was meint ihr dazu?

Mit freundlichen Grüßen
Der Wolf
 
Salve

Ich würde dir REST empfehlen - für mich ist da alles irgendwie "einfacher". Es basiert auf HTTP, ist durch json auch sehr schlank, man kann Netzwerktraffic sniffen und verstehen, Security-Aspekte sind durch das HTTP Protokoll sehr gut berücksichtigt (packet inspection), etc. Auch kann man sehr einfach eine URL in den Browser posten und kann so den Service aufrufen - ist für eine etwaige Überwachung auch von grossem Vorteil, weil es einfach einfach ist...

(Muss aber natürlich auch sagen, dass ich RMI überhaupt nicht mag)

Gruss
slowy
 
Hallo und danke schonmal für deine Antwort,

für das Einstellen der Parameter denke ich, ist REST auch die richtige Vorgehensweise. Aber halt für das online anzeigen der Berechnungsergebnisse weiss ich nicht, ob er Weg über HTTP richtig ist, da sich die Anzeige auf dem Cient alle paar Millisekunden automatisch updaten sollte.

Gruß
Wolf
 
Hallo

da sich die Anzeige auf dem Cient alle paar Millisekunden automatisch updaten sollte.

Uhhm,.... muss das so sein? Ich habe da schon das Gefühl, dass da sich die Applikationen sich dann gegenseitig äweng auf den Füssen stehen - ich sehe Probleme und Komplexität in Zusammenhang mit Multithreading und synchronisierten Zugriffen.

Wäre eine Datenbank als Backend eine Option? Somit wären die Applikationen unabhängiger voneinander, SQL ist sowieso toll, Reports anhand von Zeit sind angenehmer, eventuell bessere Performance, Backup ist dann vielleicht ja auch noch ein Thema,...

Gruss
slowy
 
Hallo,

ich sollte vielleicht etwas konkreter werden, was mein Szenario angeht. Die Applikation die die Daten generiert ist ein Tracking-Framework. Das heisst, da ist zum Beispiel ein Laser-Scanner und eine Kinect angeschlossen, auf deren Daten basierend ich verschiedene Personen in einem Raum verfolge. Zum Teil muss ich dafür Parameter anpassen um das Tracking Verhalten zu beeinflussen. Die Ergebnisse des Trackings, also zum Beispiel die aktuell ermittelte Position der Person würde ich gerne auf dem Client anzeigen lassen. Dazu kommen noch weitere Daten, wie die ermittelte Größe etc. Ich brauche die Daten zum einen um die ganze Applikation zu konfigurieren, zum anderen zum debuggen, daher sollen die immer möglichst zeitnah übertragen werden (also mehrmals pro Sekunde).

Gruß
Wolf
 
Ui, das hört sich aber sehr, sehr spannend an =)

Okay, also am liebsten hättest du das möglichst realtime. Okay, du hast zwei Komponenten:
Eine Tracking-Komponente, die eine Konfiguration besitzt und anhand dieser Positionen von Personen ermittelt.
Eine Client-Komponente, die - sagen wir es mal reduziert - diese Positionen anzeigt.

Ich denke auch, dass REST ist hier die falsche Wahl ist. Ich wäre jetzt hingegangen und hätte selber Server/-Sockets entwickelt, RMI mag ich nach wie vor nicht, müsste aber auch hier funktionieren.

Was ich sicher vermeiden würde wäre ein Polling zu implementieren, ergo: Ich hätte den "Client", welcher die Daten anzeigt als Server implementiert. Somit kann man realtime die Daten von der Tracking-Komponente an die Client-Komponente senden (und man pollt nicht, obwohl es nichts zu holen gibt).

Gruss
slowy
 
Ah, ok. Dann bin ich ja schonmal auf dem richtigen Weg. Im Moment habe ich halt mit beiden Varianten experimentiert und bin erstmal bei REST geblieben, da es schnell ging und ich schonmal Parameter verändern kann. :) Mit der Client/Socket Variante ohne RMI habe ich auch schonmal experimentiert, dachte aber, wenn Java schon dieses RMI Framework anbieten sollte ich es vielleicht auch verwenden. Sieht auch ganz interessant aus, scheint ja aber aus der Mode gekommen zu sein. Auf jedenfall dachte ich, es würde die Realisierung von Diensten auf der Server Anwendung eventuell vereinfachen.

Ich hätte das publishen der Daten auch nicht als polling realisieren wollen, sondern hätte auf Seiten der Tracking Anwendung einen Dienst geschrieben der von dem Tracking benachrichtig wird, wann eine (interessante) Änderung der Daten stattgefunden hat und der diese dann an den Client schickt. Allerdings ist halt diese Netzwerk-Kommunikations-Sache auch alles noch relativ neu für mich. Und um ehrlich zu sein, mache ich diese ganze Implementierungs-Arbeit in dem Bereich zwar auch, weil es mir die Arbeit erleichtert, aber hauptsächlich weil ich Spass daran habe mich mit dem Thema auseinander zu setzen und zu lernen. ;)

Gruß
Wolf
 
"Ein bisschen" Off Topic:
Wenn es dir auch darum geht, Spass daran zu haben und etwas zu lernen - unabhängig davon, welche Technologie jetzt überhaupt eingesetzt werden soll und am meisten Sinn macht - würde ich dir schon raten, dich mit der Socket-API auseinander zu setzen. Einfach aus dem Grund, dass viele Technologien auf dieser API aufsetzen. Ich sagen unseren Lehrlingen eben auch immer so Sätze wie "Wenn man mal selber ein kleines MVC-Framework implementiert, hat man es einerseits definitiv verstanden, ergo versteht man fertige Frameworks besser."... oder so ähnlich *g*

Ausserdem gehört's zur J2SE - da schadet es sicher nicht, das auch in seinem Repertoire zu haben =)

Gruss und viel Spass
slowy
 
Hey,

dem stimme ich auf jedenfall zu. Ich dachte nur daran, dass wenn ich reine Socket API verwende und auf Server Seite verschiedene Dienste anbiete, muss ich mir ja darüber im klaren sein, wie der Client die Methoden der Dienste ansprechen kann, also muss man sich auf ein Protokoll einigen. Bei der RMI hätte der Client ja "direkt" die Methoden der Dienste aufrufen können. Allerdings ist mir eben beim essen aufgefallen, dass ich, wenn ich das Tracking-Framework als Server aufsetze und dann einen Dienst anbiete, der die Daten exportiert ich um die Socket-API wahrscheinlich eh nicht drum herum kommen.

Auf jedenfall schonmal vielen Dank für deinen Input.

Gruß
Wolf
 
Hallo,

anstatt hier auf "rohe" Socket Kommunikation zu setzen, würde ich mir, an deiner Stelle, bei diesen Anforderungen WebSockets genauer anschauen.
WebSockets sind gerade für die Umsetzung solcher Szenarien (near real-time updates) IMHO gut geeignet. Eine Alternative zu WebSockets wären long-polling / Bayeux basierte Techniken.

Gruß Tom
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück