Ich habe vor kurzem dieses Block auf WordPress 2.7 aktualisiert. Damit gibt es jetzt eine “auto update” Funktion. Sprich ich kann per Knopfdruck automatisch die aktuellste Version installieren. Damit erspare ich mir jedesmla die Dateien herunter zu laden und mühsam zu aktualisieren. Die PHP Welt scheint hier doch um einiges agiler als die Java Welt zu sein. Bisher ist mir keine Java Webanwendung bekannt die ein ähnliches Feature eingebaut hätte, aber was nicht ist kann ja noch werden.
Obwohl eigentlich alles zur Zeit über Web 2.0 spricht und der Browser mehr und mehr der Client für alle Anwendungen zu sein scheint, hat IBM vor kurzem die Lotus Expeditor Plattform herausgebracht.
Ich hatte in der letzten Woche einmal gelegenheit mir das genauer anzuschauen, Lotus Expeditor besteht aus:
- Eclipse 3.2 als Basis Framework
- Komponenten zur Anwendungsverwaltung, Steuerung und Aktualisierung
- Einem lokalen Java Web Server
- Einem lokalen Portlet Container (JSR-168)
- Einer WebService Engine
- Komponenten zur ansteuerung der DBe, im Sinne einer Offline Datenbank
- Komponenten zur Ansteuerun von MQe im Sinne eines Offline JMS
Die Plattform besteht aus vielen seit langem von IBM einzeln Angebotenen Komponenten und macht im großen und ganzen einen ausgereiften Eindruck. Der Startup dauert ziemlich lange, aber die Performance im Betrieb kann durchaus überzeugen.
Reizvoll ist die Kombination eines RCP Plattform (Eclipse RCP) und einer zentralen Serververwaltung. Dadurch kann man klassische Java Anwendungen bauen, ohne sich bei jedem Client um deren Verwaltung, Auslieferung und Aktualisierung kümmern zu müssen. Zudem liefert IBM einige Plugins mit, die zwar keine hippeFunktionialität aufweisen, aber für den Professionellen Einsatz einfach unentbehrlich sind.
Neben der Standalone version, ist Expeditor seit einiger Zeit auch Grundlage der IBM Produkte Lotus Notes und Sametime. Von daher wird die Plattform sicherlich im Unternehmensalltag im Laufe der Zeit ihre Freunde finden.
Wir alle kenne den Spruch “Wenn Du entdeckst, dass Du ein totes Pferd reitest, steig ab.” Bei meinem ersten Projekt ist es jetzt soweit, ich habe beschlossen das “Pferd” JSF ist vielleicht nicht tot, aber zumindest schwer krank.
Anforderung des Kunden war es sowohl “Deep Links”, also URLs anzubieten die direkt tief in den Webauftrit einsteigen als auch den Browser Back Button sauber zu unterstützen. Nach einigen Experimenten und einer Menge Recherche Arbeit bin ich zu der Erkenntnis gekommen, dass JSF für solche Projekte nicht die richtige Plattform ist. Deep Links lassen sich vielleich nocht realisieren, aber den Back Button in Zusammenhang mit Datatables habe ich nicht in den Griff bekommen. Problem ist, dass die Datatable ihren Zustand aus der Session holt, spricht ihre eigentlichen Objekte auf Basis einer drunterliegenden Collection holt. Wenn diese Collection nicht mehr vorhanden ist, funktioniert die Datatable nicht (einen guten Artikel hierzu gibt es auch im myFaces WIKI). Egal wie ich es gedreht habe, ich konnte mit JSF nicht den Speicherbedarf und die Performance parallel in den Griff bekommen, so dass ich die Anwendung auf klassische Servlets (auf MVC Basis) zurück drehen musste.
Die Moral von der Geschicht? Aus meiner Sicht wird JSF nicht DAS Web Framework werden. Im schlimmsten Fall droht JSF ein ähnliches Schicksal wie EJB 1.x und 2.x, gute Ideen aber für die praktische Umsetzung zu kompliziert, im besten Fall wird es ein mögliches Framework für Web Application bleiben. Den de facto Standard Status, wie Struts ihn bis vor einigen Jahren hatte, wird es aber so schnell nicht erreichen können.
Nachdem ich diese Woche die Problemstellung hatte, ein Konzept zu schreiben für ein Projekt, wo die Problemstellung so komplex war, dass man sie mir vor Projektbeginn gar nicht beschreiben konnte. Der Kunde wusste nur, dass er komplexe fachliche Probleme hatte und er das wissen seiner Mitarbeiter irgendwie in Programmlogik gießen wollte. Aber wie man Logik aufbauen kann die es noch gar nicht gibt?
Selbst mit Strategy Pattern kommt man irgendwann zu einem Punkt wo der Code komplex und schwierig zu warten wird. Wenn dann, wie hier, der Fachanwender auch noch selber Logik hinzufügen soll, ist man spätestens mit seinem Latein (oder Java) am Ende. Genau so oder ähnlich war meine Situation diese Woche und ich habe nach einem Ausweg gesucht. Mein erster Gedanke war es eine Skriptsprache wie Groovy oder JRuby zu integrieren und den Fachanwendern Zugriff auf (Teile) des Codes zu lassen. Eigentlich ein ganz brauchbarer Ansatz, aber die Welt der Skriptsprachen ist noch sehr in Bewegung und ich habe mich dagegen entschieden.
Als Alternativen untersuche ich jetzt einen eigenen Regel Parser mit ANTLR aufzubauen oder das ganze unter eine hübsche grafische Oberfläche mit Drools zu packen.
Ich arbeite nun schon seit vielen Jahren mit log4j, aber erst in dieser Woche habe ich herausgefunden, dass es auch einen Email Appender gibt. Standardmäßig wacht er über ein Logfile und protokolliert die Ereignisse wie jeder andere File Appender auch, trit aber ein Ereignis mit Level ERROR auf, so schickt er eine Email mit den letzten Logereignissen an eine konfigurierbare Adresse.
Seitdem muss ich nicht mehr in meine Logfiles schauen, wenn mir die Anwender Fehler melden, sondern bin meistens schon im Vorfeld informiert, dass etwas schief gelaufen ist. Und alles ohne Entwicklungs- nur mit Konfigurationsaufwand.
In der letzten Woche hatte ich eine interessante Diskussion mit einem Arbeitskollegen. Ausgehen von einem konkreten Problem kamen wir nach und nach zu einer Recht fundamentalen Diskussion über das Pro und Contra des Model View Controller (MVC) Ansatzes für Web Anwendungen.
Nachdem ich anfangs fast automatisch in die übliche Schema gefallen bin, alles bisherige zur verteidigen, wurde mir Schritt für Schritt bewußter, dass ich das ganze nie wirklich hinterfragt hatte. Spätestens seit den Zeiten von Struts 1.x war MVC für mich eigentlich gesetzt und im Laufe der Zeit hat es sich so sehr festzementiert, dass ich mir Web Entwicklung ohne MVC fast nicht mehr vorstellen kann.
Nach der Diskussion habe ich dann mal im Web recherschiert, in der Tat scheinen 99% aller Java Web Frameworks (und davon gibt es ja nun wahrlich genug) auf dem MVC Pattern zu beruhen und Kritik oder alternative Ansätze gibt es wenig. So musste ich eine ganze Weile suchen bis ich diesen Blogeintrag entdeckt habe.
Sind wir mal ehrlich, alle die wir schon einmal eine Web Anwendung geschrieben haben wissen: Es gibt nur eine View: HTML. Alle Beispiele für alternative Ausgabekanäle (WAP; XML…) sind konstruiert oder haben ein sehr begrenztes Anwendungsszenario. Zudem sind die Anforderungen die das Netz mit sich bringt oft so speziell dass auch der Controller ohne Web keinen Sinn macht. Also können wir die ganze Diskussion über Austauschbarkeit und Wiederverwendbarkeit mal getrost der Wissenschaft überlassen. Bleibt noch die Wartbarkeit, bekanntlich soll der Code ja leicht zu ändern und gut zu pflegen sein. Aber sauber organisierter Code muss nicht gleich MVC heissen, im Gegenteil manchmal steht MVC der Wartbarkeit sogar entgegen.
Das soll jetzt keine Predigt gegen MVC an sich sein, aber jedes Muster sollte man nur dann anwenden wenn es passt. Mit der Zunahme von Mashups und anderern Aggregationstechniken, einem starken Innovationsdruck von Seiten der Skriptsprachen her und den immer dynamischeren Applikationen (Web 2.0) darf MVC kein heiliger Gral sein. Für mich ist MVC kein Selbstzweck, vielleicht darf es manchmal noch einfacher sein, schließlich ist ja bekanntlich gut, gut genug.
Zur Zeit beschäftige ich mich mal wieder mit dem Thema (Web) Content Management Systeme und als Java Entwickler trifft man dann früher oder später auf JSR 170 (Java Content Repository). Bisher war mir irgendwie immer nicht ganz klar was das ist und wozu das gut sein soll.
In den letzten Tagen ist da jetzt aber endlich mal ein bisschen Licht ins Dunkel gekommen. Die JSR-170 beschäftigt sich nicht mit Content Management in dem Sinn, es ist keine API für Content Management Systeme, sondern eine API für ein Content Repository.
Größtes Problem für mich als deutschsprachiger Java Entwickler, war dass ich Content Repository nicht vernüftig übersetzt bekommen (“Inhaltsverzeichnis” ist wohl nicht brauchbar). Worum geht es also?
Es geht um eine API um Daten zu speichern, nicht mehr und nicht weniger. Ein System das JSR-170 unterstützt unterstütz also einen bestimmten Zugriff auf die Klassen, so wie eine relationale Datenbank i.d.R. SQL als Abfragesprache für seine Daten unterstützt, unterstützt ein solches System eine bestimmte API um auf seine Daten zugreifen zu können. Die Daten werden dabei allerdings nicht relational sondern (logisch) hierarchisch gespeichert.
Die JSR-170 gibt es in zwei (Basis) Leveln die jeweils verschiedene Fähigkeiten beinhaltet, auf Level-1 ist nur lesender Zugriff möglich, erst auf Level-2 kann man auch Daten schreiben. Hat man also ein System das JSR-170 Leve-2 implementiert, kann man es auf diesem Wege mit Daten befüllen und auch auf die Inhalte zugreifen.
Die API ist also eher ein Ersatz für eine Datenbank oder eine proprietäre Speicherung im Filesystem als eine API für Content Management Systeme. Ein ganz gute Abgrenzung findet sich bei der Firma Day Software AG in diesem PDF Dokument.
Die meisten meiner Webanwendungen haben, zumindest sofern sie mit HTTP GET arbeiten relativ kryptische URLs, die sich letztlich auf Datenbankschlüssel, Suchparameter und ähnliches zurückführen lassen. Das sieht zwar nicht unbedingt schön aus, hat aber bisher ganz gut funktioniert.
Leider scheinen da gegen nicht nur einige Benutzer sondern auch ne ganze Menge Internet Suchmaschineen eine Abneigung zu haben, so dass ich versucht habe das zu ändern, möglichst ohne komplette Anwendungen neu zu schreiben. Die Standardlösung für mich ist mod_rewrite in einen vorgeschalteten Apache einzubinden und zu konfigurieren. Das funktioniert, erfordert aber das ich vor meinen lokalen Tomcat nen Apache httpd schalte, wo mir erst mal der Aufwand zu hoch war. Also habe ich nach einer reinen Java Lösung gesucht und bin fündig geworden.
Der UrlRewriteFilter liefert als Servlet Filter sowohl die Möglichkeit ausgehende URLs nach einem bestimmten Muster (auf Basis von Regulären Ausdrücken) zu parsen, als auch eingehen URLs entsprechend einer Konfigurationsdatei umzuändern.
Positiver Nebeneffekt der reinen Java Lösung, ist dass Servlet Filter natürlich nicht nur Zugriff auf URLs und Parameter sondern auch auf den ServletContext und die HTTP Session haben. Dadurch kann man sehr schön jedem Link bestimmte Session Parameter (z.B. die aktuelle Sprache oder andere Einstellungen übergeben). Die so erzeugten Links sind dann mehr oder minder Stateless und können problemlos gebookmarkt oder auch weitergegeben werden.