Frage zu einer 3-Tier Anwendung

[-MacNuke-]

Hallo.

Da wir in der Firma unsere Software komplett neu schreiben müssen, arbeite ich gerade aus wie wir das hier nun genau anstellen.

Die letzte Zeit arbeitete ich mich in Java ein und auch in Hibernate. Wir hatten uns gedacht das wir halt Java/Swing mit Hibernate nutzen. Leider erfährt man ja erst nach eigenen Versuchen oder intensiver Suche im Netz nach all den Nachteilen dieses Vorhabens (in größeren Multi-User Netzwerken). Unterm Strich ist Hibernate für eine Client/Server (2-Tier, richtig?) nicht wirklich geeignet bzw. es ist ein nicht zu unterschätzender Aufwand.

Jetzt geht es halt darum andere Wege zu finden und auch hier im Forum stößt man auf "mache eine 3-Tier Anwendung". Hab mich auch informiert wie das nun so im Groben aussieht, aber man steht als Einzelner da ja nun vor einem riesigen Berg an Dokumentationen und Frameworks.

Eine 3-Tier Anwendung besteht dann ja quasi aus der Datenbank, einem Application-Server und der Oberfläche. Hibernate und der Java-Code laufen dann ja quasi auf dem Application-Server.

Hier die Frage wo ich noch nicht wirklich eine Antwort gefunden habe: Muss die Oberfläche nun zwangsläufig browserbasiert sein oder gibt es auch andere Möglichkeiten eine 3-Tier Anwendung zu erstellen?

 

[maki]

3 Schicht Architekturen sind prinzipiell 4 Schicht Architekturen

Präsentation, Geschäftlogik, Anbindung an die DB inkl. Anpassung der Datenstrukturen und schliesslich die Datenbank selbst.

Ein Applicationserver ist nicht Vorraussetzung, diese Schichten sind logischer Natur.

Hibernate ist sehr häufig verwendet in dieser Art Anwendung, die Probleme samt möglicher Lösungen sind bekannt.
Auch müssen diese Anwendungen nicht notwendigerweise einen Browser als Client unterstützen.

 

[foobar]

Die letzte Zeit arbeitete ich mich in Java ein und auch in Hibernate. Wir hatten uns gedacht das wir halt Java/Swing mit Hibernate nutzen. Leider erfährt man ja erst nach eigenen Versuchen oder intensiver Suche im Netz nach all den Nachteilen dieses Vorhabens (in größeren Multi-User Netzwerken). Unterm Strich ist Hibernate für eine Client/Server (2-Tier, richtig?) nicht wirklich geeignet bzw. es ist ein nicht zu unterschätzender Aufwand.

Die Lernkurve ist steil, aber es lohnt sich auf jeden Fall für Neuentwicklungen. Bei Altanwendungen mit historisch gewachsenem DBschema hat man mit ORM wenig Spaß.

Jetzt geht es halt darum andere Wege zu finden und auch hier im Forum stößt man auf "mache eine 3-Tier Anwendung". Hab mich auch informiert wie das nun so im Groben aussieht, aber man steht als Einzelner da ja nun vor einem riesigen Berg an Dokumentationen und Frameworks.
Eine 3-Tier Anwendung besteht dann ja quasi aus der Datenbank, einem Application-Server und der Oberfläche. Hibernate und der Java-Code laufen dann ja quasi auf dem Application-Server.

Guck dir mal das Springframweork an. Das ist elcihtgewichtig und macht die Integration von Hibernate sehr einfach.

Hier die Frage wo ich noch nicht wirklich eine Antwort gefunden habe: Muss die Oberfläche nun zwangsläufig browserbasiert sein oder gibt es auch andere Möglichkeiten eine 3-Tier Anwendung zu erstellen?

Nein, dein Client kann eine Webapp eine Swinganwendung oder auch eine RCP-Anwendung sein. Das spielt überhaupt keine Rolle. Du kannst die Clients durch verschiedene Remotetechnologien wie RMI,SOAP,REST etc. anbinden.

 

[-MacNuke-]

Das klingt schon mal beruhigender. Aber jetzt habe ich noch ein paar mehr Wörter wo ich mich einlesen muss

Also bei der Anwendung fangen wir quasi noch mal an. Die jetzige Lösung hat weder eine SQL-Datenbank, noch basiert die Anwendung auf SQL-Befehlen und ein paar Sachen sind grundlegende Design-Fehlentscheidungen die uns momentan von einigen Erweiterungen abhalten. Diese rein zu korrigieren käme einem Re-Write gleich. Zumal die Umgebung nicht mehr weiterentwickelt wird, vom Hersteller. Daher -> wir müssen weg.

Ich muss also auf nichts rücksicht nehmen, außer das die Bedienung der neuen Anwendung nicht allzu stark von der jetzigen abweicht. Weil die wird bei unseren Kunden immer hoch gelobt.

So. Soviel dazu.

Also Tests mit Hibernate und Java habe ich ja schon genug gemacht. Mein Problem war dann immer das ein Client dann nicht immer aktuelle Daten hatte usw. Das sind halt die Hibernate-Caches. Klar kann man die abschalten, aber dazu habe ich in anderen Foren gefunden, dass ich mich dann auf extreme Performance-Probleme einstellen kann (bis zu Sekundenbereichen). Und ich halte mich nicht für was besonderes, also werde ich über kurz oder lang auch in diese Probleme rennen

Das will ich halt dann von Anfang an vermeiden. Darum wohl empfohlen eine 3-Tier Anwendung. Das passt auch besser, da auf dem Application-Server soweit ich weiß nur ein Hibernate-Cache vorhanden ist, den alle nutzen und somit alle auf den richtigen Daten arbeiten.

Oder bin ich mit dem Application-Server (z.B. Glassfish) jetzt auf dem falschen Weg? Weil irgendwie muss doch auf dem Server was laufen, was die Sachen ausführt, oder? ^^

Die Frage ob es denn eine Webanwendung wird, ist noch nicht ganz geklärt. Toolkits wie GWT sehen ja schon mal ganz gut aus, aber die Dokumentationen dazu sind auch recht spärlich. Und Sachen wie Tapestry sehen sehr.... groß aus

Bisher kenne ich nur Swing und habe bisher auch nur Swing-Anwendungen mit Java gemacht, daher bevorzuge ich sicher das, klar, aber ich will auch nicht allzu verbohrt sein. Noch ist in meinem Kopf Webanwendung = ultrakompliziert, wenn ich eine Webanwendung haben will, die sich wie eine Swing-Anwendung bedient (also ohne Page-Refreshs (AJAX?))

Naja, mal weiter reinlesen in die Sache... muss ich morgen mal ein bisschen ordnen...

 

[foobar]

Oder bin ich mit dem Application-Server (z.B. Glassfish) jetzt auf dem falschen Weg? Weil irgendwie muss doch auf dem Server was laufen, was die Sachen ausführt, oder?

Glassfish ist ein Applicationserver für JEE Anwendungen. Das ist eine Alternative zu Spring bzw. umgekehrt *g*

Also Tests mit Hibernate und Java habe ich ja schon genug gemacht. Mein Problem war dann immer das ein Client dann nicht immer aktuelle Daten hatte usw. Das sind halt die Hibernate-Caches. Klar kann man die abschalten, aber dazu habe ich in anderen Foren gefunden, dass ich mich dann auf extreme Performance-Probleme einstellen kann (bis zu Sekundenbereichen). Und ich halte mich nicht für was besonderes, also werde ich über kurz oder lang auch in diese Probleme rennen

Du hattest wohl langlaufende Sessions auf den Clients. Das lässt sich aber leicht lösen. Du kannst nur auf den Secondlevel-Cache verzichten den Firstlevel-Cache (Session) gibt es immer.

 

[-MacNuke-]

Glassfish ist ein Applicationserver für JEE Anwendungen. Das ist eine Alternative zu Spring bzw. umgekehrt *g*

Hmmm... OK...

...ich glaube ich lese erst mal noch ein bisschen rum, bevor ich weiterfrage Ich hab momentan nicht so wirklich den Plan

 

[foobar]

...ich glaube ich lese erst mal noch ein bisschen rum, bevor ich weiterfrage Ich hab momentan nicht so wirklich den Plan

Das geht uns allen so *g* Ständig gibt es irgendwelchen neuen Apis, Frameworks und haste nicht geshen. Da weiß man bald gar nicht mehr was man überhaupt noch nutzen soll.

 

[robertpic71]

Noch zu Hibernate: Bei mir ist der Secondlevel-Cache per default abgeschalten - das sollte keine Probleme machen.

Ich habe so einen ähnlichen Entscheidungsprozess auch vor 2 Jahren durchgemacht, hier nur gaaanz grob ein paar Möglichkeiten:

1.) Desktopanwendung (Swing/SWT/RCP)
mit Hibernateanbindung
- kein Secondlevelcache
- Hibernateengine erhöht Anforderungen an den Client
+ GUI ohne Kompromisse möglich
- zwischen Businesslogik und Datenbank liegen mitunter in andern Bundesländern..

2.) Desktopanw. (Swing..) + Applikationsserver über RMI
+ Hibernate läuft am Server
+ Hibernate kann Secondlevelcache nutzen
+ GUI wie bei 1.)
+ Businesslogik am Server

Programmtechnisch schaut das so aus, dass für die Manager, DAO's.. Klassen noch ein
Interface bereitgestellt weden muss und diese vom Server dann auch Remote angeboten werden.
Im Desktopprogramm holst erzeugst du die Businessklassen nicht selber, sondern holst sie
dir z.b. von einem JNDI-Client, der diese wiederum vom Server holt.

3.) Ajax-Web-Anwendung
+ Hibernate läuft am Server
+ Hibernate kann Secondlevelcache nutzen
+/- schöne GUI mit Ajax möglich, aber an Swing/SWT kommt es nicht ganz ran
+ Businesslogik am Server
+ keine Deploymentsorgen
- je nach Framework aufwändiger Erstellung
- höhere Serveranforderungen
+ man kann (!) linkfähige Anwendungen erhalten bzw. leicht zu anderen
Webanwendungen verzweigen

Unser Knockout-Kriterium für 1. und 2. waren die 500 Network-Clients welche nur via Remotedesktop (Citrix, RDB, X11) oder per nativen Browser arbeiten können. 500 x Remotedesktop heißt 500 JVM's am Server...
Weiters läßt sich in eine Webanwendung leichter mit den bereits vorhandenen Webanwendungen migrieren.

Das Problem bei den Ajax-Frameworks ist, dass es da viele davon gibt und sich noch kein Gewinner abzeichnet. Aber bisher jedes Framework war mMn noch übersichtlicher und einfacher als JSF + Ajaxzusatz.

Wir verwenden jetzt das Framework ZK mit Hibernate und Spring. Das Framework bietet weitgehend das Desktopprogrammiermodel an (Komponenten, GUI-Events..) und bietet auch zusätzlich die Möglichkeit die GUI mit XML zu beschreiben und dabei noch die Vorzüge von WebAnwendungen (z.B. EL's) zu vereinen.

/Robert

 

[-MacNuke-]

Wow, vielen Dank für die Zusammenfassung

Das mit Remote Desktop und der Masse an JVMs habe ich ja z.B. gar nicht bedacht...

... wird warscheinlich die Entscheidung beeinflussen. Aber das werde ich in der Firma am Montag besprechen

 

[ARadauer]

Programmtechnisch schaut das so aus, dass für die Manager, DAO's.. Klassen noch ein
Interface bereitgestellt weden muss und diese vom Server dann auch Remote angeboten werden.
Im Desktopprogramm holst erzeugst du die Businessklassen nicht selber, sondern holst sie
dir z.b. von einem JNDI-Client, der diese wiederum vom Server holt.

hier ist spring auch ziehmlich hilfreich... hab eine anwendung die von der client seite auf einen service zugreift. dieser service kapselt die ganze business logik und den db zugriff über hibernate. zum entwickeln zutz ich den server am client, der client benutzt einfach die klassen im eclipse projekt... eine änderung in der spring konfig und der client greift über rmi auf den service am server zu... feine sache..