Technologiewahl: Swing/RMI/Sockets

[fapsons]

Hallo zusammen,

ich bin dabei eine kleinere Lager-/Logistikanwendung zu entwickeln, da für die jeweilige Branche keine Standardlösung existiert.

Die Client-Anwendung würde dabei etwa auf 5 Arbeitsplatzrechnern laufen. Die Serveranwendung auf einem Server mit MS Server 2008.

Momentan kommt es mir so vor, dass die meisten Lösungen in diesem Bereich meist nur noch mit Servlets/JSP gelöst werden. Ich möchte allerdings unbedingt clientseitig mit einer Swing-Anwendung arbeiten. Auf dem Server würde ich dann gerne eine Konsolenanwendung entwickeln, die mit den Clients entweder über RMI oder Sockets kommuniziert. Diese Anwendung hätte dann Zugriff zur MySQL-Datenbank, die auf derselben Maschine laufen würde.

Klingt diese Idee für euch völlig unvernünftig? Der Auftraggeber möchte ungern eine Webanwendung nutzen. Ich selber fühle mich in Swing auch wohler und habe das Gefühl hier deutlich schneller voran zu kommen.

Habt ihr Erfahrungen gemacht mit der obigen Konfiguration? Wie stabil laufen Serveranwendungen in JAva?

Vielen Dank für eure Hilfe!!

 

[tuxedo]

Man muss ja nicht alles ins Web verlagern, und man muss ja eine Anwendung nicht auf ein einziges Userinterface festzurren. Bin auch kein Freund von "Webanwendung als Ersatz für _jede Art von_ Desktopanwendung")

Je nach Aufwand und Größe des Projekts lohnt es sich vielleicht für die Serverseite OSGI (Apache Felix?) und auf Clientseite eine RCP Anwendung (Netbeans RCP ist Swing...) zu verwenden. Dann hat man immerhin ein leicht zu erweiterndes bzw. zu wartendes Framework.

Gruß
Alex

 

[fapsons]

Danke für den Tipp. Apache Felix klingt auf jeden Fall schon mal interessant!

Mit welcher Technologie würdest du dann die Kommunikation zwischen Server und Client gestalten? RMI, Sockets, oder noch etwas anderes?

 

[tuxedo]

Für's lokale LAN ist RMI schonmal nicht verkehrt. Allerdings gibt's hierfür eine Alternative (*aufMeineSignaturSchiel*).

Von Hand (sprich: Sockets) würde ich das nicht basteln. Wenn du nicht zwingend ein eigenes Protokoll brauchst, nimm was schon da ist (RPC als RMI). Ansonsten evtl. mal Apache MINA oder JBoss Netty anschauen.

Letzten endes hängt die Wahl vom Einsatzgebiet ab. Aber dazu hast du dich ja noch nicht sehr geäußert.

- Alex

 

[fapsons]

Super Tipps. Vielen Dank. Das hilft mir sehr weiter!!!

 

[Kr0e]

Um vlt. noch die bisher sehr vollständige Aufzählung noch um eins zu erweitern: Mit Java7 kam AIO. Asynchronous I/O. Damit ist NIO quasi abgelöst und endlich kommt ein Threading-Modell direkt mit. Damit könnte man es wagen, sich nochmal mit der low-level Ebene zu beschäftigen. Ich persönlich benutze seit dem Release keine Netzwerkframeworks mehr, sofern ich Java7 benutzen kann. Die ganze unnötige Komplexität von NIO ist damit endlich unnötig geworden und Performancemäßig gewinnst du auch noch ein paar Prozenz, da nun beim Lesen/Schreiben kein Thread-Kontextwechsel mehr stattfindet. Aber klar, wenns schnell gehen soll ist das ein blöder Rat

Gruß,
Chris

 

[homer65]

Man kann auch Sockets nutzen.
Dazu braucht man kein eigenes Protokol zu implementieren,
da man per Socket auch Objekte übertragen kann.
Habe das schon öfter programmiert.
Wir haben hier sogar eine derartige Anwendung, die seit Jahren stabil in Produktion läuft.

 

[Kr0e]

NIO , AIO arbeiten beide prinzipiell mit Sockets, nur sie werden dort anders intern verwendet. Mit java.net.Socket würde ich hingegen nur noch arbeiten, wenn es nicht auf Performance/Skalierbarkein ankommt, wegen der Ein-Thread-Client Geschichte... Der Vorteil von NIO/AIO ist, dass dort stets die beste Methode des jeweligen OS gewählt wird.

Beispiel (in C):

Unter Linux ist poll() epoll() unschlagbar... Unter Windows ist die select() Methode aber totaler Murks. Unter Windows sollte man immer WSA benutzen... Das sind alles Techniken, um den Zustand von Sockets zu überwachen. Ein Socket allein ist erstmal gar nichts besonderes. Aber das handeln von sehr vielen Sockets ist das, wo es haarig werden kann... Und AIO geht jetzt sogar den besten Weg: Es lässt das Betriebssystem das komplett selbst regeln. Genannt Asynchronous IO. Man sagt quasi dem OS "Hier, bitte lies mal was von dem Socket und ruf ein Callback mit den Daten auf, wenn du soweit bist". Da hier OS-intern endlos viel optimiert werden kann, vorallem was Threading angeht, ist AIO klar zu bevorzugen. Und genau diese Lücke wurde imt JDK7 endlich geschlossen.

 

[tuxedo]

Da du ja immer wieder AIO "promotest": hast du auch nen Link zu einer brauchbaren Anleitung wie man AIO (ohne Netty...plains java 7 sdk ...) benutzt?

 

[Kr0e]

Hallo,

es gab ne lange Zeit immer einen 1-stündigen Screencast dazu. Unter den Suchbegriffen "parleys grizzly aio" spuckt google bei mir als erstes ergebnis diesen link aus:

Parleys.com - Introduction to Asynchronous I/O (NIO.2) using the Grizzly Framework Presentation

Dummerweise gibt es das Video leider nicht mehr =(.

Ein anderer guter Link ist der hier:

An NIO.2 primer, Part 1: The asynchronous channel APIs

Ist zwar nicht so umfangreich wie der Screencast, aber damit kann man alles machen, was mit NIO 1.4 (auf die Sockets bezogen) möglich ist. An und für sich ist der ganze Netzwerkkram mit AIO sehr einfach geworden, verlgeichbar mit einem simplen NIO Framework. Unterschied ist natürlich dass so Sachen wie Handler-Chains oder so selbst erstellt werden müssen.

Und wie schon erwähnt: Die Performance ist etwas höher, einfach weil die CPU nicht zwischen den Aktionen "Lesbar - Gelesen" wechseln muss. Sprich wenn ein Channel lesbar ist, dann wird im selben Thread direkt gelesen und das sogar unter Umständen häufiger, wodurch unter Hochlast ein effizienteres Threadingmodel zur Verfügung steht. Sowas mit NIO1.4 zu machen geht halt nicht, weil dort nicht derart Hardware das Lesen geschieht sondern selbst ausgeführt werden muss...

Solche und noch andere Informationen wurden halt durch den SCreencast klar. Dort wurde viel zu der Technik erklärt und warum es NIO überlegen ist...

PS:

Das größte Problem ist natürlich fehlende Tuts. Das ist aber mit jeder neuen Technik so, überhaupt ist ja JDK7 noch nicht wirklich akzeptiert worden. Aber ist ja klar, dass Betreiber von NIO Frameworks die Entwicklung erstmal hinaus zögern und einen Umstieg wegen ein paar Prozent lohnt auch nicht wirlich... Wenn man halt von vorne anfängt, würde ich nicht mehr auf NIO setzen...

 

[tuxedo]

Der erste Link geht bei mir. Video kommt auch.

Mit der ganzen Versionierungssache: Worin liegt jetzt der Unterschied zwischen NIO 1.4 und AIO?

 

[Kr0e]

Oh man, eben hats echt nicht geklappt Vermutlcih genau den Moment abgepasst wo es nicht geht =(.

Was meinst du mit Versionisierungssache ?

 

[tuxedo]

IO
NIO
NIO.2
AIO
NIO 1.4
...

Merkst du was? Ich kann nur IO und NIO Unterscheiden, und weiß, dass NIO.2 (so wird's auch im Screencast genannt) das neue NIO ist, das mit Java7 kommt/gekommen ist und AIO beherrscht.

Mit NIO 1.4 kann ich gar nix anfangen.

[EDIT]Hier mal ein Bich zum Thema: Pro Java 7 NIO.2 - Anghel Leonard - Google Bücher

Für alle anderen die auf der Suche nach Infos sind:

Mit "AsynchronousServerSocketChannel" liefert google recht viel brauchbares was in die richtige Richtung zu gehen scheint.
[/EDIT]

 

[Kr0e]

Achso, das meinst du.

Nun gut NIO ist der Überbegriff für alles was nicht mit java.io.* zu tun hat. Also grundsätzlich Channels, Buffers, Charsets.

NIO1.4 ist der Stand von Java 1.4, also "das NIO" was dir bekannt ist. Mit JDK7 kam nun NIO 2.0. Was eine Art Ergänzung ist für NIO allgemein. Die Packages heißen nämlich auch weiterhin einfach nur java.nio.* und nicht java.nio2.* oder so. Unter den Neuerungen befinden sich viele weitere außer bloß
AIO:

AIO ist der Überbegriff für Asynchronous I/O und beschreibt die grundlegende Zugriffstechnik auf Daten. Unter Windows heißt das glaub ich Completion-Ports und unter Linux Overlapping IO. Damit ist gemeint, dass man proaktiv an die Sache ran geht und quasi "anfängt" zu Lesen, obwohl noch gar nichts da ist evt. und ein Callback bereitstellt, welches dann auf die Fertigstellung des asynchronen Vorgangs reagiert.
NIO1.4, also die "klassische" NIO Variante geht reaktiv an die Sache ran mit Selektoren und reagiert, nachdem ein Ereignis ausgelöst wurde.

NIO 2.0 bringt also Support für AIO und erweitert die Channels nun um die asynchrone Vorgehensweise. (unter anderem)


EDIT:

Ja sorry, AsynchronousChannel etc sind wirklcih bessere Suchbegriffe bei Google als Java AIO. Hier in der UNI sagt jeder immer AIO und redet eigentlcih von den Asynchronous Channels...