ideale Client-Server-Kommunikation mit Java?

[SeeksTheMoon]

Moin!

Wenn ich ein Client-Server-basiertes Java-Programm schreibe (Client mit Java und Server mit Java), das über das ganze Internet funktionieren soll, was für eine "Fern"-API nehme ich da am besten?
Ich weiß jetzt noch nicht, wieviel Daten hin und herwandern, aber es soll vom Client eine von mehreren definierten Anfragen abgeschickt werden, der Server führt sie aus und schickt seinerseits das Ergebnis oder selber einen Befehl zurück, den der Client dann ausführen soll. Nehmen wir mal an, dass es maximal 30 Clients geben kann.
Sicherheit ist übrigens nicht soo wichtig, ich will mich nach Möglichkeit also nicht mit Sandkästen oder Sicherheitsmanagern rumschlagen (außer es geht nicht anders); die sorgen höchstens dafür, das irgendwas nicht klappt und man zusätzlichen Aufwand in jeder Hinsicht hat...

Es gibt ja RMI, Corba, die Klassen Socket und ServerSocket, XML-RPC, ....

Kann mir jemand die Vor- und Nachteile der einzelnen Methoden erläutern, bzw. welches scheint auf den ersten Blick am geeignetsten? Hab ich ein Verfahren vergessen?

Welches Verfahren bietet sich an, wenn man:
a) schnelle Kommunikation in beide Richtungen haben will und/oder
b) den Programmierer nicht überfordern will ;-) und/oder
c) es sowohl client- als auch Serverseitig leicht einzurichten sein soll

Was eignet sich, wenn jetzt jemand sagt "Der Server oder Client ist zu langsam, in C/C++ wäre er schneller" und man nicht alles neu schreiben will?

Ich habe übrigens mal gehört, RMI kommt nicht über Proxies hinaus, aber ich konnte nirgendwo eine Bestätigung dafür lesen. Hat RMI solch eine Einschränkung?

[peschmae]

im Javabuch von www.javabuch.de hats n kapitel über RMI, schaus mal an!

MfG Peschmä

[Mattburger]

a) Meine Wissens benutzt RMI einen anderen Port, daher bietet sich SOAP-RPC an.
SOAP läuft meist via http und ist daher eher (immer) offen. Nebenbei kann man dann den Client auch in einer anderen Sprache schreiben.
Nachteil hoher text-Overhead (10% Nutzdaten, 90% Formalisus).

b) Wenn Java zu langsam, dann kompiliers doch mit towerj towerj.com.
Habs aber nicht ausprobiert.

c) Ich hof ich häng mich hier nicht so weit aus dem Fenser aber:
Wenns schnell gehen soll ist Java, C#, PHP, perl, Pyton oder andere nicht
"native Compiler" ohnehin verkehrt.
Auf der anderen Seite ist die C-Programmierung aufwendiger.
Hilfe könnte vielleicht Kylix/Delphi bieten. Mit den Indy componenten hab ich hiermit schon einen Http-server programmiert. War schnell genug.
C ist jedoch leichter auf andere UNIXe portierbar.

Aber wir reden hier wirklich von schneller Kommunikation also mehrere 1000 Anfragen pro Sekunde. Im Internet herscht ohnehin ISDN oder DSL vor weshalb ich mal behaupten wurde <100 user tuts auch Java oder ein schnellerer Rechner.

d) Die Geschwindigkeit hängt jedoch zunächst vom verwendete Algorithmus ab.
Es gbit auch langsame C Programm.


Es gibt nebenbei erwähnt noch
- DCE (Unix-welt nicht mehr hype)
- DCOM (Windows standard)
- RPC


Empfehlung:
SOAP Protokoll mit Kylix und den Indy Componenten als Server
und Java mit gSOAP als Client.

Alternative: nur Java mit RMI.

Grüse

Mike

[Lin728]

Hi,

Habe Benchmarks gesehen, die Java mit nacktem, optimiertem C verglichen haben.
Die Performance bleibt sich so ziemlich gleich, im Gesamten (alle benchmarks verglichen) ist Java vieleicht um 20% langsamer!

Das kmopiliertes Java schneller ist, ist ein großer Irrtum! Ich habe vor kurzem einen test bezüglich der Performace von nativen Java-Compiliern und der JVM von Sun gesehen, und ich muss sagen, dass die JVM von SUN eigentlich in den meisten Bereichen sehr gut performt-
Auch hab ich einen vergleich gesehen, indem einem C,C++,Perl,Python und PHP gemicrobenchmarked hat, C und C++ knapp vor Java, dann Python danach PHP und dann Perl. Man muss allerdings anmerken, dass der Abstand zwischen den Scriptsprachen und Java extrem groß ist, teilweise um den Fator 5-15!!

Mfg

[SeeksTheMoon]

ok, das war ja schonmal was.
Es muss auf jeden Fall beides in Java geschrieben werden.

Also läuft es wohl auf RMI hinaus, richtig? Corba ist anscheinend sehr fett und wenn man bei Java bleibt, ist also RMI erste Wahl.

Wie sieht es mit einer selbstgestrickten Lösung (Socket/ServerSocket) im Vergleich zu RMI aus?
Wäre das einfacher? Ich meine, wenn der Server auch dem Client Befehle schicken kann, dann wirds mit RMI doch schon was komplizierter, oder?

Könnte das dann so aussehen, dass man sich Strings mit festgelegten Anweisungen hin und herschickt oder wäre das irgendwie von Nachteil (Sicherheit, Geschwindigkiet, Paketgröße, ....)?

[anda_skoa]

RMI hat den Vorteil, dass du dir über die Kommunikation keine großen Gedanken machen mußt.

Der Nachteil von RMI ist, dass es HTTP Tunneling nur als Fallback macht (meine diesbezügliche Information ist aber chon ein bischen älter).

Ich denke, ein eigenes Verfahren ist nur sinnvoll, wenn die zu transportierenden Daten einfach sind und es nur wenige Kommunikationspartner gibt.

Eine Frage zu den Befehlen Server->Client.
Ist das eine aktive Kommunikation seitens des Servers, odr antwortet er nur mit einem Befehl?

Ciao,
_

[SeeksTheMoon]

er antwortet mit einem Befehl oder mit einem Ergebnis

[anda_skoa]

Wenn es nicht aktiv ist, also nur als Antwort, dann ist das immer leichter, weil der Server von sich aus keine Verbindung initiiern muß.

RMI dürfte am einfachsten zu implementieren sein, weil du dir über die Kommunikation selbst keine Gedanken machen mußt.
Es ist einfach ein Methodenaufruf.

Ciao,
_

[SeeksTheMoon]

dann muß ich RMI auf beiden Seiten implementieren.
Ich seh mich schon die Stubs und Skeletons wild hin und her verteilen und mich mit dem bösen Security-Manager und seinen Exceptions rumschlagen....GEIL! *gg*

Also wenn niemand nen Vorteil für Selbstgestrickes (Socket/ServerSocket) aufschreibt, mache ichs mit RMI...

[anda_skoa]

Aber du brauchst RMI nur in eine Richtung.
Der Server muß ja nichts am Client aufrufen.

Selbst gestricktes ist nicht so schwer.
Man hat mehr Kontrolle über die Kommunikation, zb welche Ports benutzt werden, oder wie der Transport passiert.

Hab ich schon mal für eine Übung auf der Uni gemacht.
Man muß halt sehr aufpassen, da man zuerst ein gutes Konzept hat

Ciao,
_

[SeeksTheMoon]

es gibt auch noch XML-RPC (hat noch niemand was zu gesagt) und Java Messaging Service!
Wo liegen da jetzt die Stärken und Schwächen?

Wenn es noch mehr gibt, brauche ich nen weich gepolsterten Raum =)

[kimsey]

XML-RPC (genau wie Soap-RPC) ist simples HTTP-POST, läuft daher auf via Proxys und hinter Firewalls. Ist außerdem extrem simpel zu implementieren.
Wenn's ein bissel komplexer sein soll, dann würde ich reines XML via HTTP-Post empfehlen. Das ist flexibler als Soap.

[Mattburger]

Hi
SOAP ist nicht unbeding kompliziert.

Der Vorteil von SOAP liegt nicht im technischen, sondern darin, das es ein verbreiteter Standard ist und es entsprechende Tools gibt. Das letzte Projektchen was ich hierbei realisiert habe war ein SOAP Client für diverse Services unter ORACLE.
Hierbei wurden die Classen definiert, ein Interface angelegt und das ganze an die Tools von Oracle geschickt, welcher es via Application-Server deployed hatte. Über die eigentliche Kommunikation musste ich mir hierbei keine Gedanken machen.
Ich denke (weiss es jedoch nicht) das gSOAP hier ähnlichen Kompfort bietet.

Also bevor ich XML-RPC, Sockets oder ähnliches selber programmieren würde, ist der Einsatz von entsprechenden Hilfsmitteln leichter. Z.B. SOAP Client mit Delphi/Kylix ist in ein paar Minuten gebaut. Oder eben entsprechende Tool auf der Server-Seite.
- Kylix/Delphi
- Oracle App Server (OC4J)
- gSOAP
es gibt bestimmt noch viele andere .

Grüße aus Böblingen
Mike

[kimsey]

Fertige Klassen gibt es übrigens auch für XML-RPC (z.b. http://xml.apache.org). Und HTTP-Server/Clients findet man auch zu Hauf, wenn man keinen Bock hat sowas selbst zu machen.