Lightweight Remoting

J

jodevelopment

Grünschnabel
Hallo zusammen,

wer kennt ein Beispiel oder Tutorial für einen SWT Client der mittels Spring skalierbar ist? Habe schon lange im Netz verbracht aber nichts Nutzbringendes gefunden.

Ich möchte EJB's und Application Server aufgrund der Komplexität und Performance gern vermeiden.

Es geht um eine erp Lösung für den Bereich 1-50 User.
Es muß ein Client mit Rich GUI sein, der im Notfall auch ohne Netzanbindung auf eine lokale DB schreiben kann (möglicherweise auch nur XML).
Die Rich Client Platform von Eclipse möchte ich jedoch aufgrund ihres hohen Footprints vermeiden. Es soll nur SWT/JFace als GUI benutzt werden.
Bei Netzzugriff sollen bis zu 50 User gleichzeitig mit der Software arbeiten können.

Mir schwebt folgende Technologie vor:

Client: SWT, JFace
Business Tier: POJO's, Spring Framework
Database Tier: Hersteller neutral

Macht das Sinn? Gibt es ähnliche Projekte?
Rod Johnson spricht von Co-located Objects um verteilte Objekte zu vermeiden.
Wie kann ich mir das praktisch vorstellen?
Wie ist eine solche Anwendung am Besten skalierbar?

Im Internet sind die meisten Beispiele leider nur für Web-Frontends gedacht.

Vielen Dank für Eure Antworten.
 
Hallo,

für das Remoting spielt es keine ROlle ob du eine Swing UI / SWT ui, oder auch nur eine Konsolenanwendung zum Zugriff
auf einen Server verwendest.

In der Regel fährt man in solch einem Szenario mit klassischem RMI oder Springs HTTP Invoker ganz gut
(je nach Anfoderungen lassen sich auch verschiedene Webservice Frameworks zum Remoting nutzen siehe Link + JAX WS).
Siehe auch: http://www.tutorials.de/forum/enter...er-kommunikation-suche-framework-z-b-mom.html
Damit kann man dann sehr einfach synchrone Aufrufe durchführen. Das heißt, je nach Implementierung des Aufrufscode blockiert das UI deines Clients für die dauer des Aufrufs. Willst du das vermeiden musst du den Aufruf in einen separten
Thread auslagern und dort beim eintreffen des Ergebnisses etwaige UI Operationen wieder im passenden Thread-Kontext erledigen (geht unter SWT ganz einfach via display.asyncExec(...) ). Damit kannst du dann deinem user asynchronität "vorgaukeln". Wenn du richtig asynchron Arbeiten willst solltest du über eine Messaging Middleware nachdenken.
Eine Möglichkeit wäre beispielsweise klassiches JMS mit ActiveMQ als MessageBroker auf dem Server. Das lässt sich einfach
ohne viel Aufwand in Serveranwendungen integrieren. Mit solch einem Messaging kann man sehr flexible asynchrone
Client Architekturen realisieren. Aber es muss nicht immer JMS sein denn auch solche leichtgewichtigeren Messaging Frameworks wie JGroups oder JXTA bieten ähnliche Möglichkeiten wie JMS.

Im Prinzip kommt es hier eher auf die Architekur und das Design der Anwendung an als auf eine bestimmte Remoting Technologie...
Wenn du eine Daten intensive Anwendung hast bietet es sich beispielsweise an über mehrere "Remotingkanäle" mit dem
Server zu kommunizieren. Auf dem einen sendest du dann nur logische Steuerinformationen und auf den anderen
überträgst du die Daten (kann auch ein normaler Socket sein, oder ein FTP Client, etc...) und zur (asynchronen) Benachrichtigung des Clients bei langlaufenden Aktionen (Reportgenerierung abgeschlossen, Report liegt unter \\fileserver\finance\reports\2008\bilanz.rpt) kann man dann eines der genannten Messaging Frameworks nutzen.

Bei der Verwendeung von Spring auf Client- und Serverseite bist du im Prinzip sogar weitestgehend unabhängig von einer
konkreten Remoting-Technologie... denn die kannst du über die Konfiguration austauschen ohne eine Zeile Java Code ändern zu müssen.

Gruß Tom
 
Tom hat eigentlich schon alles gesagt. Eine Kleinigkeit noch: was meinst du damit?

jodevelopment hat gesagt.:
wer kennt ein Beispiel oder Tutorial für einen SWT Client der mittels Spring skalierbar ist?
Zum Vergrößern anklicken....

Unter skalieren verstehe ich größere Last durch linearen Resourcenzuwachs (v.a. Hardware) aufzufangen. Du redest von dann aber von 1 - 50 User. Werden das mal X Tausend oder warum der Fokus auf Skalierbarkeit?

REINHAUN!
 
Vielen Dank für die guten Anregungen Thomas und Oliver.
Man merkt, Ihr wisst wovon ihr sprecht.

Nun, da ich aus der C++, C#, VB.NET Ecke komme und grad den Schwenk zu JAVA / J2EE mache, ist mir einiges noch neu.

Grundsätzlich geht es mir darum eine Anwendung zu entwickeln, deren Schichten strikt voneinander getrennt sind (was auch sonst....). So sollte es möglich sein, erstmal einen Rich SWT-Client zu verwenden und bei Bedarf auch ein Web-Frontend an die Business-Logik anzuflanschen.

Was die GUI (und die Tools dafür) betrifft bin ich mir im klaren.
Nur die Architektur der weiteren Schichten ist noch nicht ganz deutlich geworden.

Mir schwebt vor, die einfachste Architektur zu verwenden und das ist auch gleichzeitig das Schwierigste an der ganzen Geschichte ('Simplicity is not a trivial goal').

Mit Skalierbarkeit meine ich, 2 User sollten gleichzeitig auf den Daten arbeiten können aber wenn die Notwendigkeit besteht auch n User (in Zukunft über Web-Frontend). Wie müssen in diesem Fall meine Business-Objekte gehostet werden?

Einige empfehlen gleich einen Application-Server zu verwenden, aber das ist meiner Ansicht ein Schritt in Richtung 'over-engineered'.

Jetzt bin ich auf Spring gestossen und habe die Bücher von Rod Johnson gelesen.
Sein Ansatz gefällt mir sehr. Er empfiehlt das co-locating von Objekten.
Was bedeutet jedoch co-located Objects in der Praxis?

Na ja, vielleicht habt Ihr einen Rat, welche Architektur ich verwenden kann.....
 
Co-located meint, dass im Großteil der Fälle logish separate Applikationen (z.B. die Serveranwendung und das Webfrontend) in ein und der selben VM laufen. D.h. eine physische Separierung und die Kommunikation nicht notwendig ist. EJB 2.X hatte distributed objects als Designfokus, ist damit aber bekanntlichermaßen an Realworld Requirements vorbeigeschossen.

In deinem Fall ist das Konzept also nur für eine evtl. laufende Webapplikation von Bedeutung. Einen Richclient wirst du schwer auf dem Server zum Laufen bekommen ;).

Der Fokus deiner Anwendung sollte auf einem guten Domänenmodell liegen. Vielleicht liest man dazu nochmal das Domain Driven Design vom Evans o.ä. Nächste Priostufe liegt auf einer sauberen Serveranwendung die Funktionalität auf dem Domänenmodell nach aussen trägt. Hier wirds schon komplizierter: welche Services bietest du an? Wie ist die Datenhaltung? Wo werden Transaktionsgrenzen definiert usw. usw. Ich würde im ersten Schritt versuchen eine Schnittstelle (Menge von (Java)Interfaces) zu definieren, die möglichst technologieunabhängig die Funktionalität der App beschreiben. Diese lässt sich dann z.B. mit Spring wiren und erstmal grundsätzlich startbar zu bekommen. Ob das Teil dann in einem Appserver läuft, in einem Tomcat oder Standlone ist grundsätzlich erstmal egal.

Nächster Schritt: exportieren der Funktionalität in konkrete Technologien. Exportieren mein hier bereitstellen. Im Allgemeinen schaut man sich nun konkret die Clients an und schreibt clientspezifische Exporter, die die Daten von Client für den Server aufbereiten und umgekehrt. Ob hier wirklich Code notwendig ist, kommt auf den Client an. für eine Kommunikation per RMI genügt z.B. ein wenig XML Konfiguration in Spring und du hast die Serverfunktionalität per RMI verfügbar. Allerdings sollte man aufpassen, dass man nicht unbedingt Domänenobjekte an den Client ausliefert um die Kopplung zu verringern. Hier bietet sich das DTO Pattern an. Bei einem Webinterface benötigst du natürlich Code, der die HTTP Requests entgegen nimmt. Letztendlich ist das aber auch nix anderes als eine Form des Remotings.

Auf der Clientseite genau das gleiche. Der sollte so designt sein, dass es ein technologieunabhängiges Interface zur Kommunikation mit dem Server gibt. Wie dies dann implementiert wird ist eine Entscheidung der konkreten Remotingtechnologie. Auf der Seite weiß Tom allerdings sicher X mal mehr Bescheid als ich ;). RichClients sind nicht gerade meine Domäne.

Ich hatte für ein Webinar hier mal ein Beispielprojekt ausgearbeitet, dass ein sehr rudimentäres Ordermanagement implementiert. Serverapp in Spring, einen Webclient und ein Swing Client per RMI. Sicher arg vereinfacht, aber die grundsätzliche Architektur sollte deutlich werden:


http://www.synyx.de/de/galleries/download/schulungen/j2ee-entwicklung-mit-spring-beispielcode.zip

Vielleicht kann dir Tom auch den Link zum Webinarrecording geben? Falls es das noch gibt? Da wird relativ viel drumrum erzählt.

REINHAUN!
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück