Über Architekturen und Perfektion
Wenn ich mir Architekturen ansehen, wie sie typischerweise präsentiert werden, muss ich an dieses Photo denken:

Ein völlig sauber, möglichst quadratisches Gebäude mit rechten Winkeln - das ist es, was man meistens als Ziel für die Architektur präsentiert bekommt. Oder die tatsächliche Architektur des Systems soll wirklich so aussehen. Meistens gibt es da aber dann die sprichwörtlichen "kleinen" Ausnahmen.
In Wirklichkeit erinnern mich die tatsächlichen Architekturen eher an das hier:

Das ist das Spiel "Villa Paletti", zum bekommen
bei Amazon
. Dabei geht es darum, dass jeder Spieler Säulen seiner Farbe ganz nach oben auf das Gebäude stellen muss, bis es einstürzt. Es gewinnt der Spieler mit den wertvollsten Säulen auf der obersten Ebene.
Wenn man sich die dabei entstehenden Konstruktionen anschaut, sind sie sicher ein Gräuel, wenn man ein Gebäude mit möglichst vielen rechten Winkeln und klaren Strukturen bevorzugt. Und natürlich ist das Ziel einer Software-Architektur nicht, dass sie am Ende einstürzt.
Aber die entstehenden Entwürfe haben auch Vorteile: Auf dem Bild kann man erkennen, dass die oberste Ebene nur von zwei Säulen unterstützt wird. Hier kommt man also mit einem sehr geringen Material-Einsatz aus - und bei einem klassischen Entwurf würde man sicher jede Ebene mindestens mit drei Säulen unterstützen. Es kann also im Laufe des Spiels eine Konstruktion entstehen, die mit weniger Material mehr Höhe erreicht, als dies bei einer im Vorhinein geplanten Konstruktion der Fall wäre.
Die andere interessante Eigenschaft des Spiels ist, dass man ständig evolutionär weiterentwickelt. Das Gebäude umfasst immer alle Bausteine und wird schrittweise "optimiert", also höher. Das ist bei dem Gebäude auf dem anderen Bild sicher nicht der Fall. Dort wird das Gebäude gebaut, es dann irgendwann "fertig" und kann danach eigentlich nicht mehr wirklich verändert werden. Bevor es "fertig" ist, kann man es nicht benutzen. Für Software ist das eine schlechte Eigenschaft, weil man dann die Software nicht ernsthaft weiterentwickeln kann.
Ich bin nun der Meinung, dass "Villa Paletti" eine wesentlich bessere Metapher für Software-Entwicklung ist als das Gebäude weiter oben. Warum?
- Software entsteht evolutionär. Es wird ständig weiterentwickelt, angepasst usw - ein klarer, rechteckiger Entwurf kann dabei nicht entstehen.
- Selbst wenn ein "sauberer" Entwurf entstehen könnte - das "Villa Paletti"-Modell ist teilweise überlegen, wie man am Beispiel des Material-Einsatzes sieht.
Für die Software-Entwicklung bedeutet das aus meiner Sicht, dass wir uns von den klaren, rechteckigen Entwürfen verabschieden müssen - wir werden sie eh nicht realisieren können. Wenn man es dennoch versucht, landet man bei Stackenblocken, weil man es eben nicht schafft, alles in rechten Winkeln anzuordnen. Zu Stackenblocken gibt es unter
http://www.youtube.com/watch?v=QEN5-_93gQg ein sehr sehenswertes Video.
Das bedeutet aus meiner Sicht:
- Lebe damit, dass die Architektur nicht perfekt sein wird!
- Beeinflusse aktiv, welche Teile architekturell besser und schlechter sind. Wenn nicht alles perfekt sein kann, muss man dafür sorgen, dass zumindest die wichtigen Teile eine gute Architektur haben.
- Setze also Prioritäten: Probleme, mit denen man leben kann, sollte man nicht korrigieren. Beispielsweise ist ein sauberer Entwurf kein Wert an sich, sondern er hilft bei der Weiterentwicklung. Ein sauberer Entwurf für einen Teil, den man nicht weiterentwickeln wird, macht daher kaum Sinn.
- Entwickel daher die Architektur und die Software evolutionär weiter. Man kann nicht ein sauberes, neues Gebäude bauen - es wird früher oder später wieder umgebaut werden, das muss evolutionär passieren und das Umschalten auf das neue Gebäude wird nicht einfach sein.
Labels: Architektur
Video zum Vortrag "Architekturen und Spring" online
Unter
http://it-republik.de/jaxenter/news/JAX-TV-Gute-Architekturen-mit-Spring-049097.html kann man nun meinen Vortrag zum Thema "Architekturen mit Spring" anschauen. Viel Spaß!
Labels: Architektur, Spring, WJAX
AJAX, Architektur und Spring?
Auf den ersten Blick scheint AJAX "nur" ein neues GUI-Paradigma zu sein. Das ist sicher auch richtig, allerdings sind z.B. Rich Clients auch "nur" ein neues Paradigma, haben aber deutliche Auswirkungen auf die Architektur einer Anwendung. AJAX ist ähnlich. Ich glaube nicht, dass es damit getan ist, dass man einfach eine geeignete Web-Widget-Bibliothek verwendet. Eigentlich geht es um das Aufrufen eines Servers und das anschließende Manipulieren einer Web-Seite durch Änderungen am DOM-Tree des HTML-Codes. Das kann zumindest im der vollen Flexibilität nicht von einer GUI-Widget-Library abgedeckt werden, die nur passende Buttons etc. anbietet. Dieser Umstand ist eine schlechte Nachricht für alle, die JavaScript ablehnen - man wird sich wohl für ernsthafte AJAX-Anwendungen mit JavaScript beschäftigen müssen. Übrigens hat JavaScript einige interessante Features wie der Prototyp-Objekt-Ansatz und es bietet Funktionen höherer Ordnung, also beispielsweise Funktionen, denen man Funktionen übergeben kann. Bei AJAX ist das ein wichtiges Feature: Man kann so eine Methode auf dem Server aufrufen und eine JavaScript-Funktion übergeben, die mit dem Ergebnis aufgerufen wird. Kein Vergleich mit dem Umgang mit einem Java-Swing-ActionListener, der wesentlich mehr Code erfordert, der auch schwerer zu verstehen ist.
Was bedeutet das für die Architektur? Meiner Meinung nach sollte man sich an den Gedanken gewöhnen, JavaScript für AJAX selber zu schreiben. Das zweite Resultat ist, dass man AJAX-Cients ähnlich wie Rich Clients als einen zusätzlichen Aufrufer der Service-Schicht sehen sollte. Im Prinzip rufen AJAX-Anwendungen mit JavaScript Logik auf dem Server auf, wie man das früher mit RMI, CORBA usw. gemacht hat - nur das die Clients in JavaScript geschrieben sind und das Protokoll XML mit HTTP ist. Das ist eine Abkehr von dem Verschicken von Seiten und Formularen - ähnlich der Transition von Terminals hin zu GUIs.
Ich denke, dass in einer Spring-Architektur nur zusätzliche Exporter für die Service notwendig sind, um sie mit JavaScript ansprechbar zu machen. So etwas setzt zum Beispiel
DWR um, das den Aufruf von Spring-Beans von JavaScript aus nahezu trivial macht. Dabei kann man die Java-Objekte auch übertragen und auf dem JavaScript-Client als JavaScript-Objekte auspacken - was das Leben erheblich vereinfacht.
Eine Vereinfachung, die hinter eigenen Widgets AJAX versteckt, sehe ich zumindest kritisch - solche Abstraktionen führen leicht dazu, dass man weniger Mächtigkeit mit seinen Werkzeugen hat, als wenn man direkt mit JavaScript und dem HTML-DOM-Baum arbeitet. Und eine Lehre aus Spring ist, dass eine Abstraktion nur wirklich gut ist, wenn man sie im Notfall durchbrechen kann.
Labels: AJAX, Architektur, DWR, Spring