RMI oder Sockets

[drlunze]

Hallo,

also ich bin am überlegen mein Praktikum nochmal neuzuschreiben.

Folgendes szenario:
Einen Webviewer für medizinische Bilder.

Die aktuelle Lösung verwendet ein Applet als Client und Serverseitig rennt ein RMI Server.
Es wird ganz simpel berechnet wo man sich Bild befindet mit welcher Zoomstufe, diese Information wird an den Server gesendet, der wiederum den Bildausschnit als return zurückgibt.
Funktioniert alles soweit ganz gut, aber mir kommt die Lösung etwas komisch vor.

Meine Idee wäre das ganze auf Sockets umzustellen, vor allem weil ich bei der "Clientwahl" flexibler wäre.
Ein Flashclient wäre ganz nett.

Mein nächster Schritt ist die Bildübertragung auf "Tiling" umzustellen, also anstatt das ganze Bild aufeinmal anzufordern werdern immer nur x*x große Auschnitte angefordert und bevor ich das mache wollte ich eben mal nachfragen.

Lohnt sich der Neuaufwand, bzw macht es überhaupt Sinn?

MfG

 

[tuxedo]

Das kommt auf deine Kommunikation an.

RMI nimmt dir viel Protokoll-Logik ab und die verwendung ist recht einfach. Wenn du auf Socket wechselst, wechselst du mindestens 1-2 Layer nach unten. Da musst du dann alles selbst machen.

Im Endeffekt kommt's auf dein Ziel an.
Ist dein Ziel den Client sprachunabhängig zu machen: Nimm Sockets.
Wenn du das letzte bisschen Performance aus der Leitung kitzeln willst: Nimm Sockets.
In allen anderen Fällen: Nimm RMI oder jede andere RPC Technik

Bzgl. der Performance mit RMI:
Wenn du die Objekte die über die Leitung gehen (also Methodenargumente und Rückgabewerte) möglichst ein sehr flaches POJO darstellen und somit fast ausschließlich aus Primitiven und Arrays aus Primitiven bestehen, dann bist du da schon auf der sehr sicheren Seite. Besser wird's dann mit RMI nicht gehen.

Um also deine Frage(n) zu beantworten solltest du erstmal dein Ziel fest definieren. Auf Basis von "vielleicht" und "kommt mir komisch vor" lassen sich schlecht Aussagen treffen.

- Alex

 

[FArt]

Socket muss nicht sein. Wenn du dir die Java-Abhängigkeit schenken möchtest, dann nimm z.B. SOAP.

Ok, ist nicht immer das schnellste. Dann kann man auch auf Burlap oder Hessian ausweichen (Hessian ist ein schönes Binärprotokoll mit APIs für viele Sprachen).

Noch besser: ein sauberes Design auf der Serverseite erlaubt es dir verschiedene Übertragungsprotokolle zu verwenden... vielleicht sogar plugable ;-)

 

[tuxedo]

Richtig, das gute alte Soap ... Vergesse ich immer wieder 🙂

Zum Pluggable Thema fällt mir noch Spring RPC ein. Da kann man anscheinend auch die Kommunikationsschicht einfach austauschen wenn man will.

- Alex

 

[drlunze]

Hallo,

Danke euch für eure Vorschläge und Tips :toll:

Bzgl. der Performance mit RMI:

Die Performance ist eigentlich super, wenn man bedenkt das die jetzige Implementierung immer ganze Bilder verschickt sobald man sich im Bild auch nur 1 pixel bewegt.

Noch besser: ein sauberes Design auf der Serverseite erlaubt es dir verschiedene Übertragungsprotokolle zu verwenden... vielleicht sogar plugable

Das ist nicht gefordert, ein fancy Client wäre da wichtiger, aber dafür braucht mein Projektpartner einen Server der Clientunabhängig ist.

Hier ist der Link zum Viewer der Scannerfirma: Spectrum WebScope

Ich werde heute mal hessian antesten.

Danke auf jeden Fall 🙂