JAOO: The new guardian.co.uk (Matt Wall, Guardian, Erik Dörnenburg, Thoughtworks)
Guardian Unlimited ist eine der ersten und größten Zeitungs-Web-Sites in Europa. Ursprünglich war die Site mit TCL, Perl, Apache usw. gebaut und sehr schwer zu ändern. Sie haben dabei statt einem hierarchischen Ansatz einen Tag-basierten Ansatz gewählt. Dadurch kann man Seiten mit Artikeln erzeugen lassen, die bestimmte Worte enthalten.
Die Implementierung basiert auf einem Java Open Source Stack. Spring 2.0 wird genutzt. Spring dient auch und vor allem als Integrations-Plattform der verschiedenen Technologien. Dann wird noch Hibernate 3, Velocity 1.5, YUI/JSON, EHCache, ROME, C3PO etc. Der Resin-Web-Server wird als Produktivumgebung genutzt und entwickelt wurde auf Jetty. Sie haben auch Ruby on Rails evaluiert, aber hatten damals nicht das Vertrauen in diese Plattform.
Als Design-Ansatz wurde Domain Driven Design (DDD) genutzt mit dem Ziel einer klaren und expliziten Modellierung der Domäne. Trotz der scheibaren trivialen Domäne - CMS ist ja eigentlich ein Thema für Standard-Software - gab es eine Menge spezifischem Business-Code. Vor allem das DDD-Prinzip der Ubiquitous Language wurde genutzt, also die gemeinsame Sprache im gesamten Projekt, die sowohl von den Nutzern, Entwicklern und auch im Code genutzt wird. Dadurch wird die Domäne auch im Code wirklich abgebildet.
In dem Projekt haben die Entwickler einen eigenen Aspekt gebaut, der bei einer Änderung an der Site auch gleich den Cache invalidiert. Dabei hängt sich der Aspekt an die Transaktions-Verwaltung, so dass beim Beenden der Transaktion auch dei Objekte aus dem Cache entsprechend entfernt werden. Hier sind man den Power von Spring und Spring AOP.
Ein wichtiges Problem ist natürlich Performance. Der Guardian hat im Schnitt 150 Millionen Hits pro Monat, wobei es sehr unterschiedlich viel Belastung gibt und vor allem die Lastspitzen sind das Problem - man denke nur an 9/11. Alle Seiten werden dynamisch erzeugt. Sie nutzen EHCache für Hibernate Objekte und für HTML-Komponenten. Die Hibernate-Objekte tauchen recht schnell im Cache auf, weil viele Seiten dieselben Objekte verwenden. Bei einem reinen HTML-Cache würde das deutlich länger dauern. Ein Server hat nach ungefähr 4 Minuten einen voll funktionsfähigen Cache. Außerdem machen sie in Bezug auf den Prozess Performance-Tests und ein einfaches Design. Auch beim Cache dominitert Einfachheit: Sie nutzen EHCache, der einfach ist und gut verstandende Konfigurations-Parameter hat.
Zuvor lief die Seite auf Vignette und TCL. Dadurch waren die Seiten mit URLs ausgestattet, wie http://www.guardian.co.uk/story/0,,125425,0.html . Das neue System hat URLs wie http://www.guardian.co.uk/news/iraq/2007/06/28/cabinet . Die alten Bookmarks sollten aber weiterhin funktioniere. Das ist notwendig, weil 30-40% des Traffics auf alte Seiten geht, also von alten Bookmarks kommt. Dazu haben sie mit Apache ein System gebaut, dass die alten URLs auf die neuen URLs abbildet. Sie nutzen mod_asis dafür und schicken den Inhalt eines Files auf der Platte als Antwort. Dieses File enthält dann das Redirect - ein recht einfacher Ansatz.
Der Talk zeigt recht deutlich, wie man sehr große Sites mit Technologien wie Spring implementieren kann. Dabei bekommt man auch sehr gute Performance hin - mit relativ "normalen" Ansätzen. Und man kann mit AOP dann auch interessante Features implementierten - wie zum Beispiel das Cache-Handling.
Labels: Erik Dörnenburg, Guardian, JAOO2007, Matt Wall, Spring, Spring MVC
JAOO: Help! Which web Framework should I use? (Alef Arendsen, Interface21)
In dieser Session gab mein Kollege Alef Arendsen eine Übersicht über Web Frameworks. Da Alef wie ich auch für Interface21 arbeitet, ist er natürlich voreingenommen.
Er zeigte erstmal Servlet-Code, wie er 1997 war. Dann JSPs als nächster Schritt, dann die Trennung zwischen View und Controller. Und dann kam Struts, das diesen Ansatz ebenfalls implementiert. Und das war dei Evolution nur bis 2001. Und bis heute (2007) ist noch eine ganze mehr Menge an Frameworks gekommen. Also: Welches soll man benutzen? Die typische Berater-Antwort: Das kommt darauf an...
Es gibt viele nicht-technische Aspekte, die man beachten muss:
- Gibt es eine ausreichend Große Community?
- Gibt es (kommerziellen) Support?
- Wie ist in der Vergangenheit mit Rückwärtkompatibilität umgegangen worden?
- Nutzt es wirklich schon irgendjemand?
- Hat das Team viel Erfahrungen mit einer bestimmten Technologie? Macht es dann Sinn, eine neue einzuführen?
Technisch gibt es unterschiedliche Aspekte, und die Frameworks eignen sich für unterschiedliche Themen. Dabei geht es vor allem darum, die rechte Abstraktionsebene zu finden. Es gibt eben keine Evolution von Struts zu JSF, es sind zwei unterschiedliche Ansätze.
Nehmen wir als Beispiel eine Anwendung mit einem zustandsbehafteten Workflow. Das Beispiel ist ebookers.com, bei dem man Reisen buchen kann. Soetwas kann man als einen Ablauf bzw. Workflow modellieren. Dazu kann man Spring Web Flow nutzen. Man kann dann den Ablauf in Eclipse grafisch modellieren. Dabei ist das Zustands-Management vollständig transparent und wird einfach vom Zustands-Automat ausgeführt. Man kann auch Teile des Ablaufs wiederverwenden und man zum Beispiel den Back-Button besser unterstützten. Allerdings muss man dazu den Zustand in der Http-Session, in der Datenbank oder auf dem Client speichern. Dabei werden Ressourcen verwendet, was die Skalierbarkeit beeinflusst.
Als Beispiel für eine zustandslose Anwendung zeigte er ilse.nl, die zweitgrößte niederländische Suchmaschine. Sie ist vollständig mit Spring MVC implementiert. Der Betreiber dachte zuerst, er könnte die Anwendung nur mit C++ implementieren. Ein Trick hier war, die Views mit SAX zu rendern und die Anwendung vollständig zustandslos zu implementieren. Für die Anwendung werden 3 Maschinen für das Frontend genutzt und 2 für das Backend. Eine ähnliche niederländische Seite benötigt anscheinend 400 Maschinen. Die letzteren haben allerdings einen zustandsbasierten Ansatz.
Was ist mit zustandsbehafteten Modellen? JSF hat ein limitiertes Navigations-Modell, weil es keine Navigations-Regeln gibt. Also muss man ein Framework wie Spring Web Flow nutzen, um das zu JSF hinzuzufügen. Diese Regeln kann man in XML (oder auch in Java) definieren. Alef zeigte dann ein Beispiel für einen Flow, der sogar Ausdrücke für die Steuerung des Ablaufs enthielt.
Google Web Toolkit hat einen ganz anderen Ansatz. Es kompiliert Event-Handling-Code, der in Java geschrieben ist, zu JavaScript, der dann im Web-Browser ausgeführt werden kann. Eine Integration zum Beispiel in Spring Web Flow gibt es noch nicht, aber darüber wird zumindest nachgedacht. Das Programmiermodell von GWT ähnelt einem traditionellen GUI-Modell wie AWT oder Swing.
Bei Struts, Spring MVC und Struts 2 hat man ein Request/Response-orientiertes Modell, das man allerdings durch Spring Web Flow ergänzen kann - wenn es notwendig ist.
Ein weiterer interessanter Gedanke: Sollte die HttpSession vielleicht durch Zustand entweder auf dem Client oder dem Server abgelöst werden? Immerhin ist die Http-Session eigentlich nur ein Hack, um ein zustandsloses Protokoll mit Zustand zu versehen.
Aber weiter mit dem Vergleich: JSF speichert die Zustand der Komponenten in der Session, was eben die Skalierbarkeit negativ beeinflusst. Dependency Injection und Navigation kann zum Bespiel durch Spring und Spring Web Flow ergänzt werden. Spring Web Flow speichert den Zustand auf dem Server - entweder in der Session oder in der Datenbank. GWT hingegen nutzt den Client für den Zustand. Der Zugriff auf den Server ist explizit, so dass man merkt, was man tut. Das ist gut, weil Remote Zugriffe eben wesentlich langsamer sind als lokale Aufrufe. Allerdings hat es keine Lösung für Dependency Injection - und es gibt noch keine Integration mit Spring. Natürlich kann man Spring immer noch auf dem Server nutzen. Struts, Spring MVC und Struts 2 haben keine eigene Features für Zustand - außer der Session. Dependency Injection kann man zum Beispiel durch Spring "nachrüsten". Diese Frameworks eignen sich also vor allem für zustandslose Anwendungen.
Was ist also mit Templating oder GUI-Design? Bei GWT kann man das HTML nicht mehr wirklich ändern oder gar von einem Designer ändern lassen - man kann allerdings CSS zum Anpassen des Design nutzen. Mit JSPs kann man Tag Libraries nutzen. AJAX muss man dann aber selber irgendwie mit JavaScript bauen. Da HTML-ähnlich ist, kann man es eher vpn Designer bearbeiten lassen. FreeMarker oder Velocity ist im Prinzip ähnlich. JSF ist deutlich anders. Es bietet auch Chancen für Anbieter von Komponenten. Man sollte es auf jeden Fall mit Facelets nutzen. AJAX ist durch einige Erweiterungen wie z.B. Spring Faces, IceFaces etc. integrierbar.
Ingesamt ein ganz gute Überblick - und die Session war auch sehr gut besucht.
Labels: Alef Arendsen, JAOO, JAOO2007, Spring MVC, Spring Web Flow, Web Frameworks
