Verteilte Anwendung - welche Technik?

[mad-din]

Hi Leute!

Ich bin grad am Grübeln, wie ich eine verteilte Anwendung aufsetzen soll. Es geht dabei um folgendes: auf einer Maschine läuft eine Art "Server", der IDs sammelt. Anhand dieser IDs sollen dann Daten gewonnen werden. Da aber der Server genug damit beschäftigt ist, die IDs zu sammeln, sollen verschiedene "Clients", die Daten sammeln. Dazu sagt der Server dem Client A z.B. "Hol dir alle Daten zur ID XXX und speicher die in der Datenbank ab". Die Clients sollen dabei überall laufen können, also auch außerhalb des Netzwerkes.

Momentan bin ich auf dem Trip das über RMI zu lösen. Aber ist das der richtige Ansatz? Die Clients als WebService laufen zu lassen, hab ich mir auch schon überlegt, aber dann müsste auf jedem Client ein Server (Tomcat o.Ä.) laufen und das will ich vermeiden. Die Clients sollten schon eigenständig sein.

CORBA wäre auch noch möglich, aber da sowohl Server als auch Clients eh in Java geschrieben werden, denke ich, dass RMI dann doch die bessere Wahl ist.

Ich hab aber irgendwie noch ein flaues Gefühl, als hätt ich irgendwas übersehen, irgendeine Technik die besser geeignet ist als RMI. Mir fällt die nur momentan nicht ein

Könnt Ihr mir einen Rat dazu geben?

Danke & viele Grüße,
Martin

 

[maki]

"IDs sammeln"???
"Daten sammeln"???

 

[mad-din]

Hi!

Die Serveranwendung ist eine Art Suchmaschine, die als Ergebnisse immer nur IDs sammelt, da das Sammeln der kompletten Daten zu aufwändig wäre. Deswegen soll der Server an die einzelnen Clients die gefundenen IDs weitergeben und die holen sich dazu die Daten.

Verstanden?

Viele Grüße,
Martin

 

[foobar]

Wenn du eine bidirektionale Verbindung brauchst, ist die Auswahl ziemlich mager. Ich würde da auch zu RMI tendieren. Corba geht ja gar nicht *grusel*
Sowas könnte man aber auch einfach selber schreiben. Wenn es nur darum geht simple Daten hin und her zu schicken und Routing und Typisierung eine untergeordnete Rolle spielen.

 

[tuxedo]

Wie wär's mit SIMON? --> http://root1.de/node/5

- Alex

 

[mad-din]

Hi!

Eine bidirektionale Verbindung wird nur bedingt gebraucht. Die Clients müssen eigentlich nichts vom Server wissen, die müssen nur die IDs annehmen und dann die Daten in die DB schreiben. Der Server müsste nur wissen, wieviele Clients es gibt, damit er die IDs auch richtig verteilen kann. Nicht dass am Ende ein Client die ganze Arbeit bekommt und die anderen nichts zu tun haben
Typisierung spielt eigentlich keine Rolle. Wichtig wäre vielleicht auch noch, dass es über HTTP getunnelt werden kann, da die Clients teilweise über mehrere Rechner übers Internet verteilt laufen.

Viele Grüße,
Martin

 

[tuxedo]

>> Wichtig wäre vielleicht auch noch, dass es über HTTP getunnelt werden kann, da die Clients teilweise über mehrere Rechner übers Internet verteilt laufen.

Das musst du etwas detailierter formulieren:

In der Regel reicht es wenn der Client eine Verbindung zum Server aufbaut. Sofern der Client nicht hinter einen zu restriktiven Firmenproxy oder Firewall sitzt, kannst du ausgehende Verbindungen zu nahezu jedem Port aufnehmen. Von daher wäre HTTP Tunneling eigentlich wurscht.

Wenn aber doch ein Firmenproxy dazwischenfunkt und dir verbietet z.B. Port 1099 (RMI) oder einen anderen, nicht "80"er Port zu benutzen, steht es dir natürlich frei den Server auf Port 80 horchen zu lassen. Dann klappt's auch mit dem Proxy/Firewall (außer es wird Packet-Inspection betrieben ....).

Von daher auch wieder: HTTP tunneling nicht wirklich von nöten.

- Alex

 

[mad-din]

Hi!

Also HTTP-Tunneling spielt schon eine Rolle, da der Server hinter einer Firewall sitzt und zeitgleich aber schon ein Server auf Port 80 läuft. Das heißt der weitere Server müsste auf Port irgendwas laufen, die Daten aber über Port 80 tunneln. Gleiches gilt natürlich auch für alle Clients, da die - jetzt mal übertrieben - auf der ganzen Welt stehen können und eigentlich nur über das Internet kommunizieren.

Aber HTTP-Tunneling funktioniert ja via RMI ganz schön, bei SIMON hab ichs noch nicht getestet. Werde wohl auch SIMON einsetzen, da es wirklich einfacher als RMI zu verwenden ist!

Viele Grüße,
Martin

 

[byte]

Ich würde einfach Spring Remote benutzen. Dann kannst Du problemlos die Implementierung später wechseln (RMI, Webservices, Burlap, HttpInvoker, ...), ohne den Java-Code umstellen zu müssen.

Ein unter GPL stehendes Protokoll ohne produktive Release-Version und Dokumentation wäre mir ein viel zu hohes Risiko. Dann doch lieber eine Library verwenden, die sich seit Jahren in der Wirtschaft bewährt hat, dessen Qualität durch zahlreiche Unittests sichergestellt ist, für die umfangreiche Dokumenation und Support besteht und die in vielen Bereichen den Quasi-Industriestandard darstellt und dazu noch unter einer der lockersten Lizenzen steht (Apache License 2).

 

[lhein]

...
Ein unter GPL stehendes Protokoll ohne produktive Release-Version und Dokumentation wäre mir ein viel zu hohes Risiko.
...

:lol:

 

[tuxedo]

>> Also HTTP-Tunneling spielt schon eine Rolle, da der Server hinter einer Firewall sitzt und zeitgleich aber schon ein Server auf Port 80 läuft

Ja, dann ist das natürlich "schlecht". Aber wenn die Firewall noch 443 (HTTPS) durchlässt und kein HTTPS Server läuft, wäre das noch eine alternative.

>> Gleiches gilt natürlich auch für alle Clients, da die - jetzt mal übertrieben - auf der ganzen Welt stehen können und eigentlich nur über das Internet kommunizieren.

Die einzigste Restriktion die mir beim Client einfällt ist, dass eine Firewall oder Proxy verbietet zu etwas anderem wie 80/443 verbindung aufzunehmen. Sofern der Server auf 80 oder 443 laufen kann weil der jeweilige Port noch nicht benutzt ist, interessiert das den Client nicht.

>> Aber HTTP-Tunneling funktioniert ja via RMI ganz schön, bei SIMON hab ichs noch nicht getestet.

Um ehrlich zu sein: Ich hab tunneling bei RMI noch nicht probiert, weiß auch nicht wie sich das mit Callbacks verhält.
SIMON kann kein HTTP tunneling. Du kannst lediglich dem Server sagen: Laufe auf Port 80 oder 443. Das Protokoll bleibt dabei das gleiche. SPielt auch keine Rolle solange kein "Packet inspection" betrieben wird und tatsächlich "reingeschaut" wird, ob da auch wirklich HTTP gesprochen wird oder etwas anderes.

>> Werde wohl auch SIMON einsetzen, da es wirklich einfacher als RMI zu verwenden ist!

Danke für die Blumen. Anregungen, Wünsche und Bugreports sind natürlich gerne gesehen...

Aber wenn's denn wirklich über HTTP gehen soll, ist SIMON (noch) nicht das MIttel der Wahl.

>> Ich würde einfach Spring Remote benutzen. Dann kannst Du problemlos die Implementierung später wechseln (RMI, Webservices, Burlap, HttpInvoker, ...), ohne den Java-Code umstellen zu müssen.

Das hat in der Tat was für sich.

>> Ein unter GPL stehendes Protokoll ohne produktive Release-Version und Dokumentation wäre mir ein viel zu hohes Risiko.

Nur gut dass es auch "mutige" gibt. Sonst würde man ständig auf der Stelle treten und nicht vorwärts kommen

>> Dann doch lieber eine Library verwenden, die sich seit Jahren in der Wirtschaft bewährt hat, dessen Qualität durch zahlreiche Unittests sichergestellt ist,

Kommt drauf an was man machen will .. Für Hobbyprojekte muss das vielleicht nicht unbedingt sein.

>> für die umfangreiche Dokumenation und ...

Naja, so viel gibts an SIMON nicht zu dokumentieren, noch nicht. Das Codesample beschreibt eigentlich shcon fast die ganze Funktionalität.

>> Support besteht ...

Support gibts bei SIMON ja auch ...

>> und die in vielen Bereichen den Quasi-Industriestandard darstellt

Womit wir wieder beim Thema sind: Kommt aufs Projekt an. Würde unsere verteilte RCP Anwendung hier in der Firma auch nicht einfach so auf SIMON umstellen. Aber für Hobbyprojekte tut's das durchaus. Und wieder: Ohne Wagnis kein Fortschritt.

>> und dazu noch unter einer der lockersten Lizenzen steht (Apache License 2).

Der gute alte Lizenzkampf Glaub da brauchen wir nicht drüber diskutieren. Das kommt auf den einzelnen an ... ;-)

In diesem Sinne: Man muss eben abwägen was man für was benutzt. Wenn's SIMON wird: Mir solls recht sein. Stehe mit Rat und Tat zur Seite.
Wenns was anderes wird: Auch kein Problem. Jedem das seine.

- Alex

 

[tfa]

>> Ich würde einfach Spring Remote benutzen. Dann kannst Du problemlos die Implementierung später wechseln (RMI, Webservices, Burlap, HttpInvoker, ...), ohne den Java-Code umstellen zu müssen.

Das hat in der Tat was für sich.

Das kann ich nur unterstützen. Spring macht das Remoting verlockend einfach. Das gute daran ist wie gesagt, dass man an keine Technologie gebunden ist. Man konfiguriert einfach, ob man per RMI, HTTP, Webservices o.ä. kommunizieren will (Vielleicht gibt es ja auch mal ein SIMONRemoteInvokerExporter ). Ich empfehle jedem, sich das mal anzusehen. Ich benutze es seit einiger Zeit und bin immer noch begeistert.

 

[mad-din]

Hi!

Also die Geschichte mit Spring Remote werd ich mir auch mal ansehen, wobei wir eigentlich auf Spring verzichten wollten. Allerdings hat sich die Lage geändert. Es muss jetzt über HTTPS laufen, das macht es natürlich für SIMON und RMI schwierig. Wie sieht das denn bei SpringRemote aus? Kann ich das über HTTPS laufen lassen?

Viele Grüße,
Martin

P.S.: Port 443 reicht da nicht, es muss wirklich verschlüsselt übertragen werden!

 

[tuxedo]

Vielleicht gibt es ja auch mal ein SIMONRemoteInvokerExporter

Das wär doch was für meine Roadmap ...

Hab mal kurz nach "spring remote" gegoogelt und bin auf folgende Seite gestoßen:
http://www.torsten-horn.de/techdocs/jee-spring-remote.htm

Also grob überflogen ist das, jetzt direkt mit einer "nackten" Benutzung von SIMON verglichen, schon etwas mehr "Aufwand" und bringt eine höhere Komplexität mit sich. Aber der Vorteil die Kommunikation austauschen zu können gleicht das sicher wieder aus.

 

[tuxedo]

@mad-din

Auf meiner TODO Liste stehen noch folgende Punkte:

a) Austauschbares Protokoll
b) verschlüsseln der Kommunikation (was in mehr oder weniger direktem zusammenhang mit a) steht)

Beides dauert aber noch ein wenig. Siehe Roadmap: http://root1.de/mantis/roadmap_page.php

 

[byte]

Also die Geschichte mit Spring Remote werd ich mir auch mal ansehen, wobei wir eigentlich auf Spring verzichten wollten. Allerdings hat sich die Lage geändert. Es muss jetzt über HTTPS laufen, das macht es natürlich für SIMON und RMI schwierig. Wie sieht das denn bei SpringRemote aus? Kann ich das über HTTPS laufen lassen?

HTTPS habe ich bisher nur in Verbindung mit dem HttpInvoker benutzt. Das setzt aber einen Webcontainer wie den Tomcat voraus. Ich möchte aber nicht ausschließen, dass es auch Möglichkeiten für andere Protokolle gibt.

Wegen Einfachheit von Spring Remote:
Was kann einfacher sein, als ein Interface + Implementierung zu schreiben? Der Rest wird konfiguriert. Das ist aber im Grunde auch nur Copy/Paste, wenn man Spring wirklich nur für das Remoting einsetzen will.

Hier mal ein vernünftiger Link zu dem Thema:
http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html#remoting-introduction

 

[mad-din]

Hi!

Die Verwendung eines Containers (sei es nur Servlet oder Application) wie Tomcat will ich eigentlich vermeiden. Im Grunde soll es so laufen: Server läuft auf Port 2000, alle Clients im direkten Netzwerk kommunizieren über RMI direkt. Die Clients, die außerhalb des Netzwerkes sind sollten auch - sofern möglich - direkt über RMI kommunizieren. Ist dies aber auf Grund von Einschränkungen wie Firewall, Packet Inspection, Proxy, etc. nicht möglich, sollten die Anfragen getunnelt werden und das am besten über HTTPS.

Doch wie ich das jetzt recherchieren konnte, ist das wohl ohne einen Servlet-Container nicht möglich, außer ich bau den SSL-Mechanismus mit den ganzen Hand-Shakes und ACKs selbst nach, aber das ist mir zuviel Aufwand.

Viele Grüße,
Martin

 

[byte]

Es gibt auch die Möglichkeit, Webcontainer wie Glassfish embedded zu starten. Du könntest auf diese Weise einen entsprechenden Container in die Anwendung integrieren. Ist natürlich ganz schöner Overhead, wenns eigentlich nur um HTTPS geht.

Edit: Es muss doch bestimmt auch eine Lösung für RMI geben, die unter der Haube SSLServerSockets verwendet? ???:L

 

[mad-din]

Es gibt auch die Möglichkeit, Webcontainer wie Glassfish embedded zu starten. Du könntest auf diese Weise einen entsprechenden Container in die Anwendung integrieren. Ist natürlich ganz schöner Overhead, wenns eigentlich nur um HTTPS geht.

Genau deswegen will ich ja darauf verzichten Das ist mir einafch zuviel Overhead, der die ganze Software aufbläht ohne Ende. Ich bin auch der Meinung, dass es eine Möglichkeit geben müsste RMI über HTTPS zu bekommen, aber fündig bin ich noch nicht geworden!

Viele Grüße,
Martin

 

[byte]

Wenn Du eh nur IDs übergeben willst, dann kannste das ganze natürlich auch einfach oldschool per javax.net.ssl.SSLSocket
machen.

 

[tfa]

Bei RMI kannst du dir Socket-Factorys basteln, und einfach die Verschlüsselung auf der Stream-Ebene realisieren.
Hier gibt es ein Tutorial: http://java.sun.com/j2se/1.4.2/docs/guide/rmi/socketfactory/index.html

 

[mad-din]

Bei RMI kannst du dir Socket-Factorys basteln, und einfach die Verschlüsselung auf der Stream-Ebene realisieren.
Hier gibt es ein Tutorial: http://java.sun.com/j2se/1.4.2/docs/guide/rmi/socketfactory/index.html

Hi!

Danke für den Beitrag! Ich hab auch grad mal in der Doku nachgesehen und siehe da, es gibt eine SslRMIServerSocketFactory. Hab das mal eben getestet, würde denke ich funktionieren, wenn ich wüsste, wo man die ganzen Keys, Ciphers, etc. hinterlegt

Viele Grüße,
Martin

 

[byte]

Die setzt Du iirc als System Property entweder mit java -D... beim Start oder halt im Code.

Müsste eigtl. hier beschrieben sein:

http://java.sun.com/javase/6/docs/technotes/tools/windows/keytool.html

 

[Guest]

Die setzt Du iirc als System Property entweder mit java -D... beim Start oder halt im Code.

Müsste eigtl. hier beschrieben sein:

http://java.sun.com/javase/6/docs/technotes/tools/windows/keytool.html

Hi!

Danke! Habs zwar mittlerweile schon selbst rausgefunden, aber ein Link mit Beschreibung ist immer gut Man kann nie genug Favoriten haben Also, RMI mit SSL Verschlüsselung ist zumindest kein Problem mehr. Hab auch extra mit einem Sniffer nachgeschaut und die Nachrichten sind wirklich verschlüsselt. Trotzdem läuft es immernoch nicht über HTTP, aber das denke ich mal sollte man auch noch hinbekommen!

Viele Grüße,
Martin

 

[ARadauer]

@alex0801: gibts schon größere firmen die simon einsetzen?

 

[tuxedo]

@alex0801: gibts schon größere firmen die simon einsetzen?

Nein, das Projekt ist ja auch noch recht jung...(etwa 9 Monate). Bin aber über jegliches Feedback froh.

- Alex

 

[Natorion]

http://lipermi.sourceforge.net/index.php

Vielleicht hilft dir das ja weiter, in den planned Features stehen auch SSL/HTTP, vielleicht kann dir der Autor weiterhelfen

 

[Natorion]

<<to be deleted>>

 

[tuxedo]

Das sieht ja ähnlich aus wie SIMON ... *mal spicken geh*

[update]

Prijekt wurde am 09.10.2006 bei SF eingepflegt und zuletzt am 19.10.2006 geupdated (zumindest die letzte binary).

Ist irgendwie ein wenig in die Tage gekommen (keine verwendung von Java NIO?). Aber die Idee mit SSL/HTTPS ist nicht schlecht.

- Alex

 

[tfa]

http://lipermi.sourceforge.net/index.php

Vielleicht hilft dir das ja weiter, in den planned Features stehen auch SSL/HTTP, vielleicht kann dir der Autor weiterhelfen

Also ich weiß nicht:

Version 0.4
Registered: Oct 10 2006
Last Update: Oct 19 2006

Viele Sourceforge-Projekte fangen ja ambitioniert an. Aber dann kommt was gutes im Fernsehen oder ein geiles Computerspiel erscheint und alles schläft ein...

 

[tuxedo]

Und letzter CVS commit von 22 Monaten.

Vielleicht kann ich ja die eine oder andere gute Idee aufgreifen. Mal schauen.

- Alex

[update]

Ich will die Lib nicht unbedingt kritisieren, aber auch die Webseite ist stein alt. Intern wird kein NIO verwendet, für jeden Client gibts einen Thread. Das "Protokoll" verwendet auf den ersten Blick oft und gerne "new", was der Performance nicht zugute kommt. ThreadPools werden ebenfalls nicht genutzt. Wenn ich dazu komme vergleich ich's mal mit SIMON. Mal schauen wer schneller ist.

 

[byte]

Viele Sourceforge-Projekte fangen ja ambitioniert an. Aber dann kommt was gutes im Fernsehen oder ein geiles Computerspiel erscheint und alles schläft ein...

ROFL :lol: