Hi,
mein Börsenspiel erreicht langsam soweit feature-completness für ein 0.6 Release, dass ich es in google code hochladen will (ca. 2 Wochen)
Für mich ist das eine Spielwiese für kontrollierte Beschäftigung mit JSF/Spring/Hibernate Entwicklung.
Inhaltlich handelt es sich um eine Art Handelsplattform als Börsenspiel.
Server: Tomcat. Datenbank: PosgreSQL (ich werd für das 0.6 Release keine weitere Datenbank unterstützen, die neueste DB2 Version ist sicher in der Pipeline).
Mittelfristigere Arbeit benötigt vor allem noch die Skallierbarkeit auf größere Anwenderpopulationen. Vor allem die Transaktions-Isolierung ist vorsichtig gesprochen mehr als optimistisch. Egal. Zur Not zieh ich da später einen Messaging Server wie ActiveMQ dazwischen.
Caching gehört auch unter das Skallierbarkeitsthema.
Sowie Security und ein Webinterface für einen Spielleiter.
Kurzfristige Arbeit vor dem upload besteht in gewissen Aufräum- und Konsolidierungsarbeiten sowie ein paar Antskripte und kurzen Doku-Texten, die es Interessierten einfach machen sollen, das Zeug zu installieren (direkt auf Betriebssystemebene und von Eclipse aus).
Was hat das mit Lotus Domino zu tun?
Spring/Hibernate ist quasi eins von zwei Lotus Domino unseres Jahrzehnts
Kontrolliertes Rapid Application Development. Für den, der tiefer in die neuen Themen wie Integration von Websphere Portal Server, DB2, Expeditor, SOA, etc. einsteigen will, mag es hilfreich sein, sich mal mit einer konsequent geschichteten, transaktionalen Java Server Anwendung auseinandergesetzt zu haben. Ausserdem sollte man die Anwendung auf Websphere 6.0 deployen können. Vielleicht kann damit mit dem alten Vorurteil aufgeräumt werden, Java-Anwendungen wären "kompliziert". Das ist nicht (mehr) wahr (s. #1 hier ->
http://peteryared.blogspot.com/2007/05/what-happened-to-lamp.html).
Pluspunkte:
- klar geschichtet in Schichten: Webfrontend, Service Layer, Data Access Layer
- find die Spring- und Hibernate-Sachen sind streckenweise echt ziemlich sauber implementiert, find ich jedenfalls. Jeder, der was anderes behauptet, ist fies.
- Unit und Integrationstests für Service und Data Access Schicht
- JSF als Webframework, weil das gewinnt definitiv an Boden und ist nicht schlecht (trotz gewisser nicht wegzudiskutierender nerviger Nachteile von JSF).
- komplette Anwendung, die zwar keinen Business Wert hab, aber vielleicht Spaß macht. Da ich auf der Lohnliste von manchmal wechselnden Softwarehäusern stehe, ist es für mich problematisch, Anwendungen mit Business Wert openSource zu stellen.
- Handelsplattformen sind vom transaktionalen Standpunkt von ihrer Natur aus herausfordernd.
- zumindest für links-nach-rechts-und-oben-nach-unten Sprachen ist die Internationalisierung/Lokalisierung komplett vorbereitet und sehr einfach durchführbar.
- für das Hobbyprodukt eines Entwicklers find ich die Optik goutierbar.
- über weite Strecken übersichtlich und leicht erweiterbar.
needs-work-Punkte:
- Security (warte auf angekündigte Releases von Acegi-Security, das in Spring-Security umbenannt wird)
- die Zuordnung der JSF Backing Beans auf die einzelnen JSF Seiten ist leider zur Zeit ziemlich chaotisch.
- langsam wirds wirklich Zeit stärker Java 5 Annotations zu benutzen anstatt alles in xml-Konfigurationsdateien zu schreiben.
- anemic domain model. Eine typische Schwäche vieler serverseitiger Java Anwendungen. Nach hoher OO-Schule sollten die zentralen Domain Objekte nicht nur aus Eigenschaften, sondern auch aus Methoden bestehen. Die Frameworks und verwendeten Pattern wirken aber faktisch (noch) in die Gegenrichtung. Der verbesserte Support für Aspekt-Orientierung wird interessanterweise dazu führen, dass der alten OO-Forderung besser entsprochen werden kann. Das war mir erstmal zu bleeding edge.
- Lasttests und vor allem Test von konkurrierenden Transaktionen.
- Caching zur Zeit nicht vorhanden
- hippere JSF Tagsammlungen wie Trinidad aka. Oracle ADF Faces oder sogar ICEFaces.
- das übliche: Kleinigkeiten
Gruß Axel
