Anwendung mit Web- und Windowsclient

[AKST]

Hallo Leute,

welche Technologien würdet ihr empfehlen, wenn ich meine Anwendung für verschiedene Clients entwickeln möchte.

Ich möchte die Datenbankzugriffe und die Anwendungslogik nur einmal unabhängig von der Clienttechnologie schreiben.
Die Weboberfläche will ich mit JSF entwickeln.

Womit entwickle ich den Windowsclient und wie greift er auf die Anwendung zu? Welche Technologie/Architektur würdet ihr empfehlen? Ich bin gerade erst in der Ideenfindung und für vieles offen.

Gruß

 

[Thomas Darimont]

Java 5 benutzen

Presentation Tier:
Web Client: JSF / Struts Shale
Rich/Smart Client: Eclipse RCP (Eclipse Plugin Architecture, JFace, SWT)
----------------------------
Business Logic Tier (Serverside):
Spring Framework / OSGi implementation (Equinox, Knopflerfish)
(Wobei bei einem Rich Client die Logik auch beim Client liegen darf)

POJO based Domain Model
----------------------------
Persistence Tier:
Hibernate / EJB 3.0 (Hibernates Entity Manager)
Hibernate Annotations (Validation, Mapping, etc...)

Gruss Tom

 

[AKST]

Hallo Thomas,

ich dachte evtl. daran, die Anwendungslogik komplett auf dem Server zu belassen, so wie bei einer normalen Webanwendung. Mir stellt sich eben die Frage, mit welcher Technologie ich dann die Kommunikation zwischen Windowsclient (SWT oder Swing) und Anwendungsserver realisieren sollte. Ein Tomcat dürfte dann ja wohl nicht mehr reichen und EJB wollte ich nicht einsetzen.
Oder sollte ich die Logik doch in den Windowsclient packen? Dann müsste ich aber die Javaklassen mit der Anwendungslogik im Projekt ständig kopieren und im Sync halten, was ich nicht so toll fände. Dann hätte ich wohl ein Webprojekt und ein RCP-Projekt. Naja wie du schon merkst ich bin erst in der Anfangsphase, bin daher für viele Ideen offen.

Gruß

 

[Thomas Darimont]

Hallo!

Mir stellt sich eben die Frage, mit welcher Technologie ich dann die Kommunikation zwischen Windowsclient (SWT oder Swing) und Anwendungsserver realisieren sollte. Ein Tomcat dürfte dann ja wohl nicht mehr reichen und EJB wollte ich nicht einsetzen.

Wieso sollte das denn nicht reichen? Sobald du Spring dabei hast kannst du auch dessen Remoting Faehigkeiten nutzen (RMI, JAX RPC, Webservices, Hessian, Burlap, Spring HTTP Remoting, etc.). Ein Tomcat reicht dazu dicke aus.

Oder sollte ich die Logik doch in den Windowsclient packen?

Du solltest dich entscheiden, ob du eine 2-Tier oder eine 3-Tier Anwendung haben moechtest / haben musst. Wenn du Spring oder einen anderes IoC Framework verwendest ist eigentlich egal wo die Logik liegt... Spring kann man auf dem Server, auf einem Client und sogar in einem Applet laufen lassen
Weiterhin solltest du dir bezueglich der Praesentation mal das Pattern Model View Presenter anschauen.

Dann müsste ich aber die Javaklassen mit der Anwendungslogik im Projekt ständig kopieren und im Sync halten, was ich nicht so toll fände.

Wenn deine Anwendung auf Eclipse RCP fusst, dann kannst du auch den integrierten Update Mechanismus verwenden.

Gruss Tom

 

[AKST]

Hallo!
Wieso sollte das denn nicht reichen? Sobald du Spring dabei hast kannst du auch dessen Remoting Faehigkeiten nutzen (RMI, JAX RPC, Webservices, Hessian, Burlap, Spring HTTP Remoting, etc.). Ein Tomcat reicht dazu dicke aus.

Das hört sich gut an. Ich werde mir mal meine JavaMagazin Sammlung rausholen und die unzähligen Spring-Artikel durchlesen, die habe ich bis jetzt nicht wirklich verinnerlicht.

Danke für den Tip. Wenn du noch weitere Ideen hast lasse es mich wissen.

Gruß

 

[CHaoSlayeR]

Ich hätte da noch eine andere Idee...

...ich arbeite derzeit auch an einem Projekt, dessen Umsetzung zum Ziel hat primär eine Web-Applikation zu bauen mit einem Web-Frontend, welches möglichst nah an der Bedienung einer herkömmlichen Applikation herankommt und sekundär einen Client zu bauen, der allein arbeiten kann und keine ständige Internetverbindung benötigt.

Wir haben dazu eine ganze Woche damit verbracht, Informationen zusammen zu tragen um so etwas mit möglichst wenig Aufwand zu bewerkstelligen. Dazu kommt auch die Notwendigkeit, die Clientlogik synchron zu halten bzw. Bugfixes und Updates auf beiden Clients gleichermaßen zur Verfügung zu stellen. Dazu gibt es zwar auch schon eine Menge Frameworks, aber in die müßte sich auch erst jemand einarbeiten.

Dann kam ich auf die Idee mit XUL und hab mich damit mal beschäftigt, was da möglich ist. Und nun verwenden wir XUL...

Nachteile von XUL:

Wenn als Web-User-Interface eingesetzt, gilt die Beschränkung bisher leider auf Browser mit Gecko-Engine (Mozilla, Camino, Firefox), allerdings ist ein XUL-Plugin für den Internet-Explorer bereits in Arbeit, da sich XUL zunehmend gerade im Business-Bereich stark verbreitet. Zudem gelten in Web-Browsern dann übliche Beschränkungen auf priviledged JavaScript und Verbot von Cross-Site-Scripting und anderen.

Vorteile von XUL:

Wenn das Konzept bei der Entwicklung stimmt, dann kann man nahezu die gleichen Quellen sowohl für ein Web-Frontend, als auch eine Steh-Allein-Applikation verwenden. Desweiteren ist eine XUL-Oberfläche sehr schnell, was Firefox, Thunderbird und andere XUL-basierte Applikationen beweisen. Zudem hat man mit XUL fast ähnliche Cross-Plattform Möglichkeiten, wie mit Java.

XUL ist sehr leicht zu erlernen, wie ich herausgefunden habe, benutzt eine stark erweiterte JavaScript-Variante für die Funtionalität und bietet viele Möglichkeiten auf Ressourcen und andere Systeme zuzugreifen.


Wenn Du wissen möchtest, was XUL kann, und was nicht, dann schau Dir einfach die Mozilla-Applikationen an (Firefox, Thunderbird, Calendar, ...). Einen guten Überblick, sowie Tutorials und Sprach-, Element- und Script-Referenzen findest Du auf http://www.xulplanet.com/ .

Vielleicht ist ja XUL auch eine Überlegung wert?


Gruß, C]-[aoZ

 

[Thomas Darimont]

Hallo!

Dann schlag ich auch noch CASABAC vor: http://www.oisoft.com/index.pl/casabac
Mehr "insider" Informationen zu XUL findet man u.a. hier: http://xulblog.de/xul/

Gruss Tom

 

[CHaoSlayeR]

Hey! Das blog kannte ich noch gar nicht... danke schön!

Zu "CASABAC": OK, es läuft im Internet Explorer...

...aber die Oberfläche ist langsam, wie jede andere herkömmliche Web-Oberfläche. Das mag ich ja so an XUL, dass man da so viele Möglichkeiten hat, Fenster, Tabs und Inhalte generell zu verstecken und zu verwalten. Damit bauen wir unsere Web-Applikation derzeit so, dass beim initialen Login alles geladen wird und nur noch XMLHttpRequests bzw. Web-Service- / SOAP-Calls. Natürlich kann man so etwas auch in HTML machen, allerdings bläht sich der Code durch solche Geschichten unglaublich auf, während es bei XUL immernoch übersichtlich zugeht.

Insgesamt finde ich die Handhabung von XUL gerade in größeren Projekten wesentlich einfacher und strukturierter als HTML.

Gruß, C]-[aoZ

 

[AKST]

Hallo,

xul ist zwar interessant, aber ich denke, dass ich damit nicht arbeiten werde.
1. Ich möchte mit den Java Server Faces und all seinen Möglichkeiten arbeiten.
2. Eine Beschränkung auf gewisse Browser ist nicht akzeptabel, zumal unsere Kunden so gut wie alle den IE verwenden.
2. Ich möchte SWT oder Swing verwenden, XUL scheint mir noch nicht ausgereift genug zu sein.

 

[CHaoSlayeR]

Hallöchen AKST,

Also ich denke nicht, dass XUL noch nicht ausgereift ist. XUL befindet sich zwar immernoch in der Entwicklung, allerdings heißt das nicht, dass es unausgereift ist, sondern nur, dass ständig Optimierungen und neue Funktionen eingebaut werden, schließlich stellt es schon seit etlichen Jahren zusammen mit der Gecko-Engine den Kern einer jeden Mozilla-Applikation. Ich finde gerade in Punkto Geschwindigkeit hat XUL einer SWT-, AWT-, Swing- oder andersartigen Java-Oberfläche einiges voraus, wenn man denn das dahinterliegende JavaScript anständig programmiert hat, ansonsten entstehen da natürlich auch mal Verzögerungen beim öffnen eines Fensters...

Das Browserargument kenn ich nur zu gut, aber ich konnte schon einige Kunden überzeugen, statt des Internet Explorers den Firefox zu benutzen. Natürlich ist das für solche Kunden indiskutabel, die auf stur schalten (oder so eine besch**erte interne Vorschrift haben) oder einfach nur Angst haben, mal was neues ausprobieren zu "müssen"... dann hab ich natürlich mit meinen Argumenten für XUL keine Chance...

...aber das ist ja immer so: Was nützt eine wirklich gute Technologie, wenn keiner sich traut sie einzusetzen?

Risiko ist heute leider Gottes immernoch ein negativer Faktor, obwohl man gerade durch neue Technologien den Arbeitsbereich einer Firma enorm vergrößern kann. Aber das gehört wohl eher in einen anderen Thread... ;-)

Also das JSF-Argument kann ich natürlich auch nicht verleugnen. Unsere Applikation beruht noch auf JSP's in Verbindung mit dem Struts Action Framework und da wir uns nun ja für XUL entschlossen haben, darf ich jetzt endlich das machen, was ich schon lange vor hatte: Die Stuts Taglib auf XUL zu portieren...
_________________

Was ich allerdings noch zu Rich-Client-artigen Web-Oberflächen sagen kann ist, dass eines meiner letzten Projekte ebendieses auch zum Ziel hatte und in möglichst vielen Browsern laufen mußte, da das Produkt, welches aus dem Projekt hervorging später durch Customizing an den Kunden gebracht wurde. Nach einigem Suchen im Netz bin ich dann auf eine JavaScript-Bibliothek gestoßen, die letztendlich die Basis für die Web-Oberfläche dargestellt hat: die X-Library. Diese Bibliothek wird vom Entwickler ständig weiterentwickelt aber kann bereits als sehr stabil und für JavaScript-Verhältnisse als äußerst performant angesehen werden. Es sind zwar nur Grundfunktionen, die man dort vorgeworfen bekommt, aber was man damit aufbauen kann ist echt genial! Und wenn der eigene Code auch Cross-Browser-fähig ist, dann läuft die Web-Oberfläche in nahezu allen JavaScript-fähigen Browsern gleichermaßen. Die Bibliothek umfaßt dabei Funktionen für Fenster-/Popup-Management, Objekt-Animationen, Menüs, Tooltipps, Layouts, Mouse-/Keyboard-Events, TabPanels, Bars, Scroller, Tabellen und vielem mehr. Ein Blick daruf könnte sich lohnen! Diese Bibliothek hat meinen Ursprünglichen JavaScript-Code auf weniger als ein Viertel reduziert und dabei die Browser-Kompatibilität noch erhöht...

Gruß, C]-[aoZ