Java über WebStart oder Serverseitig?

[janw]

Hallo zusammen,

mich beschäftigt eine grundsätzliche Frage, und zwar, ob ich eine Java-Applikation in Swing über Web Start zur Verfügung stelle oder ob ich über z.B. JSF eine Weboberfläche anbiete.
Als AppServer läuft der JBoss, die DTOs und die SessionBeans sind als JAR-File deployt in der shared/lib des Tomcats und natürlich im JBoss.

Bei der Web Start-Variante würde ich folgendermaßen vorgehen:
- Die Kommunikation zw. Client und Server läuft über den Tomcat: Anfragen an Servlets geben DTOs serialisiert zurück, als ObjectInputStream o.ä. Somit kann auf Clientseite ein objektbasierter Zugriff erfolgen.

Was spricht denn gegen Java Web Start?
- Man kann alle GUI-Komponenten von Java verwenden.
- Ich könnte mir vorstellen, dass Server-Zugriffe minimiert werden => weniger Traffic = schnellere Antwortzeiten (z.B. eine Liste von Aufträgen wird einmal an den Client übertragen, eine Detailansicht eines Auftrags wäre dann ohne erneuten Serverzugriff möglich).

Nachteile fallen mir ein:
- Unter Umständen langsames Verhalten auf schwachen Client-Rechnern
- Laden der Applikation über JNLP dauern ein wenig länger, wiederholt sich, wenn eine neue Version / weitere DTOs in einem JAR bereit stehen

Welche Nachteile von Java Web Start sind denn noch bekannt?

Schönen Gruß
Jan

 

[takidoso]

Hi,
also ich selbst habe nur erfahrung mit Web-Start weniger mit Thin-Client-Technologie.
Die Nachteile die Du aufzählst sind im Grunde auch die, die mir einfallen würden. Da seit Java1.4.2_XXX, meines wissen auch die Probleme bezüglich Autorisierungsverfahren mit und von Microsoft überwunden wurden, kann ich lediglich noch einen netten Vorteil nennen.
Du kannst die Anwendung auch unabhängig eines Servers laufen lassen. Wenn die restlichen benötigten Resourcen nicht auf dem Verteilungsrechner liegen, und der Client irgendwie weiß wie er an die anderen Resourcen (z.B. DB-Server) ran kommt kann man unabhängig des Verteilungsrechner arbeiten. Andererseits kann ein Client ja theoretisch so gestrickt sein, dass, wenn z.B. DB-Server nicht verfügbar ist einfach die ein oder andere sache in einen Cash schreibt und wenn beim nächsten Mal wieder alles notwendige da ist die vorangegangene Sache losschickt. Wobei dies natürlich nur bei bestimmten Problemen geht und nicht bei allen.

mal ne Frage für mich als Ahnungslosen, was war doch gleich nochmal DTO?

Takidoso

 

[Thomas Darimont]

Hallo!

DTO = Data Transfer Object

Meiner Meinung hat ein Smart Client als Webstart Lösung noch den Vorteil, dass die "User Experience", wenn man das Teil anständig designed, weitaus größer ist als wenn man mit einer schnöden Web-GUI daher kommt (wenn man sich nicht gerade einen mit irgendwelchen AJAX Kunststückchen abbricht).

Wenn du eine Swing GUI bauen willst würde ich dir unbedingt empfehlen die JGoddies Bibliothek zu verwenden http://jgoodies.com/ .Damit lassen sich recht einfach /richtig/ schicke GUIs bauen

Ansonsten wenn du dich mit Eclipse und dessen Rich Client Platform auskennst könntest du ja auch einen Eclipse RC hochziehen und diesen über Webstart verteilen:
http://sourceforge.net/projects/webrcp/

Na ja, ein weiterer Vorteil der mir bei Webstart einfällt ist die einfache Aktualisierbarkeit, da der update Mechanismus schon fix und fertig eingebaut ist.

Ein "Nachteil" von Webstart ist, dass auf den Clients eine Java Runtime + Webstart installiert sein muss. Weiterhin sollte der Clientrechner auch entsprechend ausgestattet sein, wobei die heute gänigen Rechner damit keine Probleme haben sollten (500 Mhz + 512 MB Ram reichen in der Regel schon aus).

Ein Vorteil von Web Applikationen ist der, dass die Zugangsvoraussetzung geradezu minimal sind. Alles was der Benutzer braucht ist ein funktionierender Webbrowser und es müssen (außer der Eingabe der URL) keine Einstellungen am Client vorgenommen werden. -> "Zero Installation / Administration" Probleme kanns hier geben, wenn man die Webanwendung so bauen muss, dass eine möglichst große Zahl an Browsern unterstützt wird... da muss man sich mit AJAX und JavaScript spielereien schon mal ein wenig zurück halten oder umständliche Workarounds in kauf nehmen.
Wenn diese Lösung für ein Unternehmen sein soll ist dieser Punkt u.u. zu vernachlässigen da dort oftmals durch Richtilinien genau vorgeschrieben ist welchen Browser die Benutzer zu verwenden haben.

Bei der Web Start-Variante würde ich folgendermaßen vorgehen:
- Die Kommunikation zw. Client und Server läuft über den Tomcat: Anfragen an Servlets geben DTOs serialisiert zurück, als ObjectInputStream o.ä. Somit kann auf Clientseite ein objektbasierter Zugriff erfolgen.

Weshlab soll die GUI denn mit den Servlets reden? Sind Servlets deine Facade? Dü könntest ein BusinessDelegate / Facade auf Client Seite bereitstellen um den Zugriff auf den entfernten Service anzubieten und gleichzeitig die fahcliche Client Logik von den technischen Dateils der Remote Kommunikation entkoppeln. Weiterhin solltest du darauf achten, dass du Remoteaufrufe auf ein absolutes Minimum reduzierst, da diese recht teuer sind. Baue grobkörnige DTOs die die gewünschte Information in einem Rutsch und nicht über 200 Aufrufe verteilt zurückgibt.

- Laden der Applikation über JNLP dauern ein wenig länger, wiederholt sich, wenn eine neue Version / weitere DTOs in einem JAR bereit stehen

Na ja, wie oft wirst du das System im echtbetrieb denn updaten? 1 mal im Monat? Wie groß werden die Änderungen sein? Vielleicht ein 20 kbyte großes Jar dazu? (Okay es könnten auch neue gößere Bibliotheken hinzukommen aber das würd IMHO eher seltener der Fall sein). ich denke diese "zusätzliche" Zeit ist nicht wirklich der Rede wert.

Soweit mal fürs erste...

Gruß Tom

 

[takidoso]

Also ich habe vor ein paar Jahren Apache SOAP als Kommunikation verwendet und den Aufruf zu SOAP in einer Klasse, die abgeleitet wurde, gekapselt.
Inzwischen ist natürlich das etwas veraltet, da APACHE AXIS halt mehr bietet.
Ein Problem kann es sein, wenn es darum geht viele viele viele Daten in einer Tabelle darzustellen. Mit viele meine ich einige tausend. Da gibt es prinzipiell 2 Möglichkeiten, entweder man lädt alles (und das kann dauern) oder man lädt immer nur einen Teil, d.h. man hat Serverseitig mehr aufwand, denn Server müsste dann die Daten sortieren.
Situation 1 kann man mit einem lokalen Cashe beglücken, Schwachpunkt bzw weitere Problematik da ist natürlich die Aktualität des selben. Situation 2 ist halt herzlich aufwendig aber es gibt dafür auch eine interessante Lösung hier der Link
http://www.javaworld.com/javaworld/javatips/jw-javatip137.html


takidoso

 

[Thomas Darimont]

Hallo!

Oftmals ist das nicht wirklich nötig so viele Daten zum Client zu schicken. Besonders nicht für den Benutzer, denn die können mit dieser "Teils" unnötigen Informationsflut nicht sehr viel anfangen...

Gruß Tom

 

[janw]

Hi!

Danke für die Antworten.

Weshlab soll die GUI denn mit den Servlets reden? Sind Servlets deine Facade? Dü könntest ein BusinessDelegate / Facade auf Client Seite bereitstellen um den Zugriff auf den entfernten Service anzubieten und gleichzeitig die fahcliche Client Logik von den technischen Dateils der Remote Kommunikation entkoppeln.

Wenn ich das richtig verstehe ist Dein Tipp:
Den Service (in meinem Fall eine SessionBean) direkt vom Client ansprechen, allerdings über ein Business Delegate.
Da habe ich mir gleich mal das entspr. J2EE-Pattern angeschaut.
Ist das Business Delegate dann also eine "normale" Klasse, die in einem per JNLP übertragenen JAR-File enthalten ist und etwa so aussieht?:

  public class Delegate{
    public List getKunden(String kundenID){
  	MySessionBeanHome home = (MySessionBeanHome) ServiceLocator.getServiceHomeObject()...;
  	MySessionBean session = home.create();
  	List kunden = session.getKunden(kundenID);
  	session.remove();
  	return kunden;
    }
    ...
  }

Dann müssten, im Gegensatz zur Kommuniktaion über Servlets, die DTOs und die Klassen der SessionBean auf dem Client liegen.
Wenn jetzt das Business Delegate "nur" eine Klasse auf dem Client ist, und die Signatur einer Methode der SessionBean ändert sich, oder eine der Service-Methoden fällt weg, müsste ja das Delegate auf dem Client ausgetauscht werden, weil sonst ja das Business Delegate versucht, eine nicht mehr vorhandene Methode aufzurufen. Der Austausch auf dem Bean Container sollte dann wahrscheinlich am besten dann geschehen, wenn niemand mit dem Client arbeitet, damit der Web Start Update-Mechanismus greift.

Na ja, ein weiterer Vorteil der mir bei Webstart einfällt ist die einfache Aktualisierbarkeit, da der update Mechanismus schon fix und fertig eingebaut ist.

Du meinst, es ist einfacher, per JNLP z.B. neue/andere DTOs bereitzustellen als sie z.B. dem Tomcat ins shared/lib zu legen?
Da ist etwas dran, der Tomcat erfordert dann ja einen Neustart.

Wenn du eine Swing GUI bauen willst würde ich dir unbedingt empfehlen die JGoddies Bibliothek zu verwenden http://jgoodies.com/ .Damit lassen sich recht einfach /richtig/ schicke GUIs bauen

Die JGoodies sehen schick aus. Und anscheinend auch frei, jedenfalls die unter "Freeware" zu findenden Libs wie die Forms.

Gruß
Jan

 

[Thomas Darimont]

Hallo!

Ist das Business Delegate dann also eine "normale" Klasse, die in einem per JNLP übertragenen JAR-File enthalten ist und etwa so aussieht?:

Ja, so koennte man das beispielsweise machen.

Dann müssten, im Gegensatz zur Kommuniktaion über Servlets, die DTOs und die Klassen der SessionBean auf dem Client liegen.
Wenn jetzt das Business Delegate "nur" eine Klasse auf dem Client ist, und die Signatur einer Methode der SessionBean ändert sich, oder eine der Service-Methoden fällt weg, müsste ja das Delegate auf dem Client ausgetauscht werden, weil sonst ja das Business Delegate versucht, eine nicht mehr vorhandene Methode aufzurufen. Der Austausch auf dem Bean Container sollte dann wahrscheinlich am besten dann geschehen, wenn niemand mit dem Client arbeitet, damit der Web Start Update-Mechanismus greift.

Ja, die entsprechenden DTO's muessen dann auch beim Client verfuegbar sein. Insbesondere wuerde ich hier die DTO's nicht nur als pure "Datencontainer" verwenden, sondern auch ein paar nuetzliche Zusatzfunktionalitaet wie dirty-Flags (dirty,new,delete,updated) etc. einfuehren. Wie Kommunizierst du denn im moment vom Client aus mit den Servlets? Schickst du Kommandos in Form von normalen HTTP Requests (Post/Get) ab?

Gruss Tom

 

[janw]

Hi!

Wie Kommunizierst du denn im moment vom Client aus mit den Servlets? Schickst du Kommandos in Form von normalen HTTP Requests (Post/Get) ab?
Gruss Tom

Im Moment gibt es nur eine Weboberfläche, generiert von Servlets. Diese kommunizieren (immerhin über eine eigene Klasse) mit dem JBoss. Einen echten Java-Client gibt es noch nicht. Bisher sind das Gedankenspiele, ich will mir ein Bild machen, wie so etwas aussehen könnte.
Eine reine HTML-Weboberfläche wird auf jeden Fall gefordert, hat sich herausgestellt. Vielleicht ist dann eine "Doppelpflege" Java-Client und HTML zu aufwendig.
Ich kannte ein Projekt, wo die Kommunikation zum Server eben über Servlets über HTTP. Vielleicht gab es dort Gründe, zu vermeiden, dass der JBoss direkt vom Client angesprochen wird, Firewall o.ä., da frag ich nochmal nach.

Und nochmal Danke für die guten Tipps...

Gruß
Jan