“Wir sind eh zu 100% ausgelastet. Wir brauchen eine Lösung, die uns hilft schneller und effektiver zu arbeiten und nicht etwas, das uns mit Glück die Zeit spart, die es selber kostet um es einzurichten und am Laufen zu halten.”
Diese oder ähnliche Aussagen höre ich oft von Administratoren. Mit dem Effekt, dass Lösungen für das Application Performance Monitoring (APM) nur von Experten als “Feuerlöscher” eingesetzt werden.

Was wird also gebraucht? Eine Lösung, die mit minimalem Konfigurationsaufwand eine große Menge an Applikationen überwacht und im Problemfall rasch die Ursache identifiziert.

Tatsächlich habe ich inzwischen ein Tool gefunden und getestet, dass diese Anforderungen erfüllt. AppDynamics hat ein Produkt entwickelt, das nicht zuletzt durch seine sehr einfache Bedienung überzeugt. Mit hoher Skepsis bin ich an die Lösung herangegangen, habe jedoch in den bisherigen Installationen keine Enttäuschung erlebt. Fast schon wie eine iPhone- oder Android-App: Einfach benutzen.

Die 3 Schritte zur 24×7 Überwachung

Betrachten wir das Aufsetzen eines typischen Application-Monitorings Schritt für Schritt und welche Vorteile dabei die Lösung von AppDynamics bringt.

1. Was messe ich?  - Messpunkte

Die Definition der Messpunkte stellt die erste Herausforderung dar. Die meisten APM-Lösungen im Bereich Java und .NET verwenden BCI (Bytecode Instrumentierung), um an Performance Daten heran zu kommen. Die Messpunkte müssen sinnvoll definiert werden, damit der Einfluss der Messung auf das Ergebnis gering gehalten wird (Overhead), da ja zusätzlicher Code ausgeführt wird. Dieser Schritt erfordert mindestens einen Experten, in der Regel einen Entwickler oder Architekten, der die Applikation im Detail kennt. Und das für jede Applikation, die  überwacht werden soll.

Wird agil entwickelt ist das ein anstrengendes Unterfangen, da sich die Klassen täglich ändern können, bzw. neue dazu kommen. Ein “Trial and Error”-Verfahren verbietet sich in Produktion, da dazu die Applikationsserver meist neu zu starten sind und evtl. der Overhead zwischendurch so stark erhöht wird, dass die     Nutzer davon merklich betroffen werden.
AppDynamics wendet hier ein zum Patent angemeldetes Verfahren an, welches mit minimaler BCI auskommt und trotzdem bis auf Methodenebene Auskunft geben kann, welche Komponente einer Applikation “trödelt”. Und das ohne jeglichen Konfigurationsaufwand. Der Architekt / Entwickler darf also weiterhin seiner eigentlichen Tätigkeit nachgehen.

2. Wie verschaffe ich mir einen Überblick? – Visualisierung

Für den Überblick bieten sich Dashboards an, welche die Architektur (wer spricht mit wem wie oft) und die Fachlichkeiten (welche Business Transaktion braucht wie lange und warum?) für alle Applikationen veranschaulichen.

Die meisten Hersteller benutzen zur Visualisierung “Customizable Dashboards”, also jenes “Allheilmittel”, mit dem man individuelle Ansichten für jeden Benutzer erstellen kann. Und genau das ist dann auch in allen Details und für jede Applikation zu tun – quasi “Mustomizable Dashboards”. Neuerlicher Aufwand entsteht, sobald sich etwas in der Umgebung oder an den Fachlichkeiten ändert.

AppDynamics Dashboards erstellen sich dagegen automatisch und ermitteln die Business Transaktionen im laufenden Betrieb basierend auf den “inneren” Werten einer Applikation (z.B. Struts Actions, URL Pattern oder HTTP Parametern). Sollten die Definitionen nicht passen, können sie mit wenigen Klicks angepasst werden und das System ist fertig eingestellt.

AppDynamics - Application Overview

AppDynamics Application Flow Map

3. Alarm! Da läuft was schief! – Schwellwerte

Was ist ein Problem in der Produktion? In der Regel etwas, dass außerhalb der Reihe passiert. Z.B. der Login eines Anwenders dauert 3-mal so lange wie normal zu dieser Tageszeit in Applikation X oder eine JVM hat einen starken CPU Verbrauch. Solche Auffälligkeiten werden durch zuvor definierte Schwellwerte erkennbar, deren Überschreitung einen Alarm auslöst.

Jetzt sehe ich in der Praxis oft 100 Applikationen mit diversen fachlichen Transaktionen die unterschiedliche “normale” Laufzeiten haben: Mal ist 2 Sekunden gut (Kostenkalkulation in der Versicherung), mal sind 200 ms Antwortzeit schon eine Katastrophe (Platzierung einer Wette in einem Online Wettsystem). Oder es liegen gar keine genau definierten nicht-funktionalen Anforderungen vor, so dass ins Blaue Werte festgelegt werden, die anschließend aufwändig anzupassen sind. Denn gehen wir mal nur von 50 Applikationen mit jeweils 50 fachlichen Transaktionen aus, sind das schon satte 2.500 Schwellwerte, die ich anpassen muss! Regelmäßig. Und wir betrachten hier nur Antwortzeiten…

Mit AppDynamics fällt dieser Aufwand zum großen Teil weg, da ein schlaues Baselining und statistische Methoden wie die Standardabweichung verwendet werden. Hier kann ich die Werte individuell einstellen, aber mehr als 95% der Schwellwerte sind mit den Standardregeln schon abgedeckt. Sogar Tageszeit-bezogene Unterschiede (Montag morgens dauert der Login doppelt so lange aufgrund der Last wie 2 Stunden später) werden dabei berücksichtigt.

4. Und was ist mit der Root Cause-Analyse? (Bonusschritt)

Alarmierungen bei Problemen sind gut und schön, man weiß dann, dass etwas schief ging, aber wer ist jetzt zu benachrichtigen? Möglichkeiten zur Triage und Root Cause Analyse vervollständigen die Überwachung. Also die Verantwortlichen für die Problemlösung identifizieren und ihnen dann auch gleich die Detaildaten übergeben, um schnell wieder Normalität einkehren zu lassen.

Ich habe vorher ausgeführt, dass AppDynamics nur sehr wenig Bytecode instrumentiert. Wie komme ich dann an die erforderlichen Details? Hierzu verwendet AppDynamics so genannte Snapshots, welche einem Callstack gleichen, mit Transaktionsdetails angereichert sind und im Bedarfsfall erzeugt werden. Bedarf besteht dann, wenn etwas außerhalb der Norm passiert, bzw. immer mal wieder zur Stichprobe zwischendurch. Dadurch wird ein Operator nicht mit Unmengen an Daten belastet, sondern erhält genau die richtigen Informationen, wenn sie benötigt werden.

In den nächsten Wochen werden wir hier im Blog auch noch auf verschiedene typische Performance-Probleme und deren Diagnose eingehen.

Einfach und effektiv

Zusammenfassend hat AppDynamics eine einfach zu benutzende und effektive Lösung auf den Weg gebracht in der ich endlich das verwirklicht sehe, was in den letzten sieben Jahren zwar angedacht aber nie umgesetzt wurde. Es ist ein einfach zu bedienendes System, welches spezifisch auf die Produktionsüberwachung ausgerichtet wurde.

Ist das revolutionär? Eher evolutionär. AppDynamics hat die Lehren aus bisherigen Lösungsansätzen verschiedenster Anbieter gezogen und vor allem über die Automatisierung nachgedacht. Das Ziel wird in den Zahlen “2-3-100” zusammen gefasst: 2 Administratoren können in 3 Tagen 100 Applikationen in die Überwachung nehmen.

Hatten die ersten Anbieter von APM Lösungen (für Java und .NET) das vordringliche Ziel,  überhaupt Daten zu bekommen und die Blackbox zu öffnen, erweiterte die zweite Generation das Ganze auf Transaktionen, um auch moderne, dynamische SOA/SBA Applikationen vernünftig zu durchleuchten. Was auf der Strecke blieb war bis jetzt die Usability. Wie bekomme ich ohne Aufwand Ordnung in meine Messdaten und mache daraus wertvolle Informationen?

Auf in die nächste Generation des APM!

Also: Agent in die Anwendung einbinden (siehe AppDynamics Lite Screencast von Fabian), an den zentralen Controller Daten schicken lassen und kurz warten, bis sich die ersten Werte einstellen.

Agile Methoden wie Scrum oder Kanban  etablieren sich zunehmend als Alternative zu klassischen Vorgehensmodellen in der Softwareentwicklung. Ist das alles nur ein großer Hype oder steckt mehr dahinter? Gibt es vielleicht sogar einen echten Business Case? Anhand einer idealisierten Geschichte soll verdeutlicht werden, welche Chancen die Agilität bietet und warum sich ein Umstieg rechnet.

In der aktuellen Ausgabe des Business Technology Magazins beschreiben Andreas und ich anhand einer fiktiven Geschichte, warum sich Agilität auch aus finanzieller Sicht für Unternehmen lohnt.

Die 4 Kernthesen für den Business Case für Agilität sind dabei:

1. Schneller geschäftlicher Nutzen und Time to Market
2. Weniger Fehl- und Blindleistungen
3. Risikomanagement von komplexen Situationen
4. Hohe und nachhaltige Qualität

Den vollständigen Artikel kann man von unserer Webseite herunterladen: Business Case für Agilität

Worum geht’s?

Ich wollte nur diejenigen unter Euch, die es noch nicht wissen, kurz darauf hinweisen, dass Dana Bredemeyer seinen bekannten Software Architektur Workshop vom 13.9.2010 – 16.9.2010 bei codecentric halten wird. Dana hat seit fast 10 Jahren keinen öffentlichen Workshop in Deutschland gehalten und von allem, was ich bislang darüber gehört habe, wird das ein wirklich guter Kurs werden. Also, falls irgend jemand von Euch Interesse an dem Workshop haben sollte und dafür nicht extra in die USA reisen möchte (oder darf): Mehr Infos gibt es unter http://www.meettheexperts.de/software-architecture.

Außerdem wollte ich das “Meet the Experts” am 17.9.2010 erwähnen. Das Motto lautet dieses Mal “Herausforderungen in der Architektur heute”. Fünf bekannte Sprecher, darunter Dana Bredemeyer, Dr. Gernot Starke und Prof. Dr. Heinz Züllighoven werden ihre An- und Einsichten zu dem Thema mit Euch teilen. Und wie immer wird es jede Menge Zeit für Diskussionen, Netzwerken, Open Space für Eure Fragen, super Catering, usw. geben. Falls das für jemanden von Euch interessant klingen sollte: Mehr Infos dazu gibt es unter http://www.meettheexperts.de/meettheexperts-architektur.

Okay, das war’s schon. Mehr wollte ich gar nicht erzählen. Ich denke, dass beide Veranstaltungen echt spannend werden und werde auf jeden Fall dabei sein. Und falls jemand von Euch da sein sollte, freue ich mich schon darauf, Dich (oder Sie) kennenzulernen … und falls nicht, klappt es vielleicht ein anderes Mal mit dem Kennenlernen …

Mirko beschreibt sehr schön in seinem Eintrag “Java Troubleshooting in Produktion: Vorstellung von AppDynamics Lite” warum AppDynamics die richtigen Antworten auf fast alle Fragen in modernen verteilten Architekturen gibt.

Dabei ist ein wesentliches Versprechen von AppDynamics die Einfachheit. Einfache Installation, einfacher Betrieb und schnelle Ergebnisse. Das klingt ungewöhnlich, und fast schon unglaubwürdig. Dass dies aber tatsächlich so ist zeigen folgende ungekürzte Screencasts.

Die Installation von AppDynamics Lite, der kostenlosen Version der Monitoringlösung, ist wirklich kinderleicht. In diesem Screencast zeige ich die wenigen dafür notwendigen Schritte (Vollbildmodus ist unten rechts aktivierbar):

Direkt nach der Installation kann dann mit der Problemsuche begonnen werden. Im folgenden Screencast sind die Grundfunktionen erläutert und ich zeige wie man einer Problemursache auf den Grund gehen kann (Vollbildmodus ist unten rechts aktivierbar):

AppDynamics Lite ist sowohl für Entwicklungs- als auch für Produktionsysteme geeignet. Es lässt sich in kürzester Zeit installieren, benötigt keine Konfiguration und liefert schon in den ersten Minuten wertvolle Ergebnisse. Die kostenlose Lite Version ist auf appdynamics.com/free herunterladbar.

In einem kürzlich erschienen Artikel schreibt Gunther Dueck von IBM, dass man versuchen kann die “guten alten Zeiten” zu romantisieren, in denen alles viel besser und einfacher gewesen ist, aber am Ende wird man sich mit SOA, Cloud und Mobilen Apps anfreunden müssen – sie sind da und werden auch nicht wieder verschwinden.

Als “Feuerwehr” für Enterprise Anwendungen müssen wir natürlich auch mit diesen Gegebenheiten auseinandersetzen und wir sehen auch eine große Veränderung bei den Problemfelder, die wir für unsere Kunden im Java Web- und Enterprise Umfeld lösen müssen. Waren es bisher eher Code- und Design Probleme, wie schlecht konfigurierte Hibernate Mappings oder Memory Leaks, die ein System in die Knie gezwungen haben, so sind die es heute immer häufiger Probleme, deren Ursache in der Architektur einer Anwendung zu suchen ist – also Problemfelder die auf Grund von steigender Komplexität und hoher Abhängigkeit von Anwendungen zu externen Services resultieren. Zudem steigen auch die Anforderungen an Performance und Skalierbarkeit der Anwendungen – manchmal auch schneller als man es vorab geplant hatte. Eine Anwendung kann vielleicht problemlos 5.000 Anwender verkraften – aber schafft sie auch 100.000? Welche der 20 Services die benötigt werden ist die Ursache für eine schlechte Performance? Was passiert, wenn einer dieser Services nicht verfügbar ist?

Diese Fragen werden meistens erst in Produktion beantwortet. Treten dort Probleme auf, dann stellt sich die Anwendung häufig als “großer, dunkler Raum” dar, in dem die Suche nach der Ursache des Problems nicht einfach ist und in der Praxis lang und teuer werden kann.

Immer kürzere Entwicklungszyklen durch agile Entwicklungsmethoden, verschärfen die Situation noch zusätzlich. Die Halbwertszeit des Wissens über eine Anwendung liegt dann bei maximal 2-4 Wochen. Einige Internet Unternehmen wie Flickr bringen bis zu 10 Mal pro Tag eine neue Version Ihrer Anwendung in Produktion.

Wie können wir also die Performance und Stabilität solcher Anwendungen sicherstellen? Profiler sind für Produktion nicht geeignet – sie haben i.d.R. einen viel zu hohen Overhead und sind für Entwicklungsumgebungen bzw. den Entwicklerarbeitsplatz konzipiert. In diesen Umgebungen hat man allerdings kein Abbild der verteilten Produktionsumgebung, sondern eine lokale Installation, so dass Probleme, die unter Last oder Parallelität entstehen, so gut wie nicht nachgestellt werden können.

Klassische Monitoring und Application Performance Management (APM) Werkzeuge sind in vielen Fällen nicht für verteilte und hoch frequentierte Systeme konzipiert, so dass sie nicht die Daten liefern können, die wir für die Analyse der Probleme benötigen. Zudem adaptieren sie die Änderungen in Anwendungen nicht automatisch, was zu sehr hohen Aufwände für Instrumentierung und Konfiguration führt – oft enden diese Produkte dann als reines System-Monitoring Werkzeug, da ein Anwendungsmonitoring für viele, sich schnell ändernde Anwendungen garnicht möglich ist.

AppDynamics, ein Start-up aus San Francisco hat ein APM Tool entwickelt, das sie selber  “next generation performance management tool” nennen. Es wurde von Grund auf für Monitoring und Diagnose von verteilten SOA und Cloud Anwendungen in Produktion konzipiert. AppDynamics überwacht verteilten Java EE Applikationen ohne das man eine spezielle Instrumentierung oder Konfiguration benötigt. Es erstellt automatisch eine so genannte “Applikations Landkarte” (siehe Screenshot), die alle wichtigen Aufrufe (JMS, DB, Webservices, …) mit Anzahl und Antwortzeit anzeigt. So erhält man in wenigen Minuten eine Übersicht, über das Laufzeitverhalten seiner Applikationen. Dazu erhält man auch einen Callstack aller wichtigen Business-Transaktionen mit Details bis auf Methoden-Level. Hierzu verwendet AppDynamics eine patentierte Technologie, die fast ohne Bytecodeinstrumentierung der Anwendung auskommt. Dies führt zu einem niedrigen Overhead von maximal 2% und zudem zu einer Vermeidung von aufwendiger Instrumentierung und Konfiguration. Zudem werden nur die Informationen angezeigt, die benötigt werden – so wird die Datenmenge reduziert und die Analyse schneller und einfacher. Dazu verwendet AppDynamics eine intelligente Regelmaschine, die auf Basis von Statistiken und vorkonfigurierten Regeln ermittelt, welche Daten erfasst werden müssen. Innerhalb von weniger als 15 Minuten hat man AppDynamics installiert und erhält alle benötigten Informationen, um die Problemursachen zu analysieren.

Hört sich unrealistisch an? Habe ich auch gedacht, als ich zum ersten Mal mit dem AppDynamics Team geredet habe. Die gute Nachricht ist aber, dass es eine kostenfreie Version von AppDynamics gibt: AppDynamics Lite. Damit kann man langsame Antwortzeiten, SQLs, Fehler und Deadlocks in Produktion analysieren und sich selber einen Eindruck von dem Werkzeug machen. Die Lite Edition ist zwar gegenüber der kommerziellen Variante limitiert, aber oftmals ausreichend, um ein Problem zu analysieren. Das Tool ist in weniger als 15 Minuten einsatzbereit, so dass ich nur empfehlen kann es einfach mal runterzuladen und auszuprobieren:  http://www.appdynamics.com/free

Fabian, unser Competence Center Leiter Performance, zeigt in seinem Eintrag in zwei Screencasts wie man AppDynamics Lite in 5 Minuten installiert und danach mit Hilfe der Informationen echte Probleme analysieren kann.

Sogar der Performance-Tester selbst kann für solche Fehler anfällig sein. Ich kann hier aus eigener Erfahrung sprechen… Entweder, weil er ein bestimmtes Ergebnis wünscht oder erwartet, oder aus schlichter Routine heraus, kann er in Versuchung sein, seine gerade selbst ermittelten Zahlen zu schnell zu glauben. Anwendungssysteme und ihre Konfiguration sind oftmals sehr komplex, so dass man leicht kleine Änderungen mit möglicherweise großen Auswirkungen auf die Testergebnisse vergessen oder übersehen kann.

Dieser anscheinend unerschütterliche Glaube an die Gültigkeit von Zahlen kann noch viele andere ungünstige Folgen haben. Oftmals wird schon ein einzelner Datenpunkt hoffnungslos überanalysiert, indem z.B. mögliche  zukünftige Performance-Verbesserungen extrapoliert werden oder die Effekte auf ein n-Mal größeres System und so weiter. Falls dann weitere Tests diese Erwartungen nicht erfüllen, setzt manchmal eine hektische Suche nach der vermuteten versteckten Ursache der „falschen“ Zahlen ein, anstatt zu bedenken, dass man von Anfang an unvergleichbare Dinge verglichen hat. Ebenso werden manchmal bereits korrekt berichtete und archivierte Zahlen wiederentdeckt, aber ihr Kontext vergessen, was zu ebenso falschen Interpretationen, Schlüssen und Maßnahmen führen kann.

Meist ist es kaum möglich, erfolgreich gegen diese Zahlengläubigkeit zu argumentieren, darauf zu beharren, dass weitere Tests zur Bestätigung nötig sind und dass große Schwankungen ganz normal sind. Performance-Messungen als Teil der Qualitätssicherung in der Anwendungsentwicklung sind keine exakte Wissenschaft. Da die oberste Priorität normalerweise ist, „etwas ans Laufen zu kriegen“, sind die Vorbedingungen eines kontrollierten Experimentes wie in der akademischen Welt nur selten gegeben. Die Ergebnisse solcher Experimente werden aber oft genau so betrachtet und behandelt.

Als Performance-Tester sollte man sich bewusst sein, welche möglichen Auswirkungen die berichteten Testergebnisse haben können. Testen, besonders Performance-Testen, soll Unsicherheit durch Wissen ersetzen, aber der unvorsichtige Umgang mit Testergebnissen kann schnell zum entgegengesetzten Resultat führen. Meines Erachtens sollte die oberste Regel sein, nur Daten zu berichten, die man selbst verstanden hat, zu denen man stehen und die man verteidigen kann. Man sollte sich immer über die Belastbarkeit, Reichweite, Relevanz und Vergleichbarkeit der Zahlen im Klaren sein, die man berichtet, und diese Charakteristika ebenso berichten. Und es ist ratsam, explizit darauf hinzuweisen, falls eine Messung nur für einen bestimmten Testaufbau Aussagekraft besitzt und für weitere Hochrechnungen ungeeignet ist.

Falls eine Fehlinterpretation von Testergebnissen passiert, sollte man schnell, deutlich und mit Nachdruck die Sichtweise des Testers auf die Zahlen und ihren Kontext darstellen, um den möglichen Schaden zu begrenzen. Zahlen, die einmal in der Welt sind, nehmen gerne ein Eigenleben an. Wie bei Gerüchten ist es praktisch unmöglich, sie wieder einzufangen. Daher sollte man stets sorgfältig bedenken, was man wann berichtet.

Und ein letzter Rat: Als Performance-Tester sollte man sich immer einen skeptischen Blick auf die eigene Arbeit und auch auf die eigenen Instinkte bewahren. Andere Leute sollten Testergebnissen nicht blind glauben – und auch der Tester selbst sollte dies nicht tun.

Ursachenforschung

Bei Speicherproblemen ist das Mittel der Wahl fast immer ein HeapDump um festzustellen was genau den Speicher belegt.
Nachdem man nun einen solchen Dump in dem fabelhaften Eclipse MAT geöffnet hat, so erhält man zum Beispiel ein Bild wie dieses:

Ouch. 1.8 GB der 2GB sind von Sessions belegt. Ich filtere dafür üblicherweise nach “StandardSession” um die Apache Sessions einzeln zu sehen und mich leicht in diesen umsehen zu können. Besonderes Augenmerk lege ich darauf was relativ viel Speicher belegt (retained heap).

Schonwieder ouch… 10MB pro Session. Das kann nicht funktionieren. Nun es wäre möglich, daß ein unvorsichtiger Programmierer so viele Daten in die Session gelegt hat, doch dies stimmt nicht, wie wir leicht herausfinden können:

Interessant! Fast der gesamte Speicher einer Session wird also von AjaxStateHolders belegt. Also, was genau macht dieses Ding eigentlich?

Wie JSF und A4J arbeiten

Ich beschreibe das verhalten etwas vereinfachend. Bevor JSF das HTML für den Browser des Benutzers erzeugt baut es eine interne Darstellung auf. Für jede Seite (oder View) wird diese interne Darstellung (auch Component Tree genannt) erstellt und durch den JSF lifecycle geschleust. Jegliche Benutzerinteraktionen werden dabei verarbeitet. Gibt es zum Beispiel eine Auswahlkomponente mit 3 Einträgen, so werden diese 3 Einträge gelesen und an den Component Tree gehängt. Die Komponente selber hält fest welcher Eintrag ausgewählt ist.

Nun wollen wir nicht daß der Benutzer die Seite abschicken muss um seine Auswahl zu tätige, welches in einem Neuaufbau des Component Tree resultieren würde. Wir möchten dafür Ajax verwenden! Damit dies möglich wird muss sich A4J an den Zustand der Komponenten erinnern wie er war als die Seite erzeugt wurde. Die Komponente und die 3 Einträge sind also bekannt und wenn der Benutzer eine Auswählt wird der Zustand der Komponente verändert und der Teil der Seite aktualisiert auf dem die Komponente angezeigt wird. Dies nennt man teilweise Seitendarstellung (partial page rendering).

Wie funktioniert nun dieses “erinnern”? Ganz einfach: Es erzeugt einen AjaxStateHolder in der Benutzersession und hängt an diesen den Component Tree.

Es wächst

Ok, es ist also die aktuelle Seite und sein Component Tree. Das können zwar große Bäume sein, aber doch nur einer pro Benutzer? Dies ist leider nicht ganz richtig. A4J speichert mehr als nur einen View. Aber warum? Nun, Browser haben einen Knopf, der es erlaubt auf die vorherige Seite zurückzukehren. Klickt man diesen Knopf an, so wird aber nicht die Seite neu angefordert, sondern aus dem Browsercache dargestellt. Der Server weiß also garnicht daß der Browser die letzte Seite anzeigt. Benutzt man dann Ajax Funktionalität, so muss der Server den Zustand kennen der zu dem Zeitpunkt auf dem Server existiert hat. Woher soll der Server diesen Zustand noch kennen? Einfach: Dieser ist natürlich auch im AjaxStateHolder. Standardmäßig werden 16 Views gespeichert. Und weil man während einer Sitzung an dem gleichen View mehrmals vorbeikommen kann, werden jeweils 16 Varianten der Views erstellt.

Offensichtlich kann dies doch sehr viel werden. Und das pro User.

Ein Lösungsansatz

Leider gibt es keine Lösung. So funktioniert JSF und so funktioniert A4J.

Im Richfaces Bug Tracker gibt es auch ein Ticket zu dem Thema: RF-3878 – Session memory leak. Und die beste Antwort ist: Reduziere die Anzahl der gespeicherten Views.

<context-param>
 <description></description>
 <param-name>com.sun.faces.numberOfViewsInSession</param-name>
 <param-value>1</param-value>
</context-param>
<context-param>
 <description></description>
 <param-name>com.sun.faces.numberOfLogicalViews</param-name>
 <param-value>1</param-value>
</context-param>

Man verliert Teile der “Zurück” Knopf Funktionalität, gewinnt aber Unmengen von Speicher.
Die zweite Lösung ist die Component Trees drastisch zu reduzieren. Diese sind aber wahrscheinlich so groß weil es komplexe Strukturen und große Datenlisten gibt, welche sich sehr schwer reduzieren lassen können.

Ab heute gibt es für alle die Möglichkeit diesen Diskussionen teilweise beizuwohnen. Ab heute gibt es den codecentric competence center podcast.

Die Leiter der competence center, und ggf. auch geladene Gäste, setzen sich regelmäßig zusammen und diskutieren aktuelle Themen aus den jeweiligen Bereichen. Initial haben wir uns einen 2-wöchigen Rhythmus vorgenommen. Der erste Podcast behandelt die Themen “Story Points” und “Benennung von Java Klassen”. Langweilig? Ganz im Gegenteil! Wir hatten sehr viel Spaß bei der Diskussion der Themen.

Ich würde mich über Feedback über Inhalt, Gestaltung, Qualität, Länge, etc. im Kommentarbereich des Podcasts freuen. Wer möchte, kann den Podcast auch auf  iTunes abonnieren und bewerten.

Nach einiger Recherche im Internet und mehreren Interviews anderer Projekt-Teams von codecentric möchte ich heute einen aus meiner Sicht sehr einfachen, robusten und vor allem schnellen Weg vorstellen, PDFs mit iText zu generieren. Das oben genannte Ticket wurde mit diesem Ansatz in einem Viertel der Zeit umgesetzt und die Angst der Team-Mitglieder vor iText ist deutlich gesunken.

iText bietet viele Möglichkeiten, PDFs komplett über die API zu erzeugen; mit allen Linien, Bildern, festen Texten, Farben uvm. Dieser Ansatz wird jedoch schnell sehr komplex und erzeugt sehr langen und fehleranfälligen Quellcode. Einfacher ist hier die Erzeugung eines “Vordrucks” mit definierten Inhaltsfeldern. Dieser Vordruck wird in Form eines PDFs mit Formularfeldern gespeichert. Dieses Template-PDF kann jederzeit, z.B. im Adobe Reader, betrachtet werden und könnte so z.B. auch schon vor der Befüllung mit Daten mit dem Kunden abgestimmt werden.

Teil 1 – PDF-Formular erzeugen

PDF-Formulare lassen sich sehr einfach mit OpenOffice erzeugen. In meinem Beispiel habe ich OpenOffice Draw verwendet, der Ansatz funktioniert aber gleicherweise mit OpenOffice Writer oder Calc. Im jeweiligen Programm einfach ein neues Dokument anlegen und anschließend nach Belieben mit Texten, Farben oder Linien gestalten. Sobald das Layout fertig ist, müssen die Inhaltsfelder definiert werden. Dabei ist es hilfreich, wenn die Symbolleisten für Formular-Entwurf und Formular-Steuerelemente ausgewählt sind (Ansicht -> Symbolleisten). Mit diesen neuen Icons kann man unter anderem den Formular-Entwurfsmodus aktivieren. Jetzt kann z.B. aus den Formular-Steuerelementen ein Textfeld ausgewählt und in das Dokument eingefügt werden. Über einen Rechtsklick lassen sich die Eigenschaften des Textfelds definieren. Folgende Einstellungen sind interessant:

• Name : Dieser Name wird später im Java Code zum Befüllen des Feldes referenziert.
• Rahmen : Default ist 3D-Look – Normalerweise wird wohl ohne Rahmen besser passen.
• Hintergrundfarbe, Ausrichtung, Schrift : Hier kann das Layout bestimmt werden. Layout-Angaben im Java Code sind damit überflüssig.
• Text-Typ: Normalerweise einzeilig, möchte man jedoch im Java Code Text mit Umbrüchen einfüllen muss hier mehrzeilig ausgewählt werden.

Sobald die Formular-Felder keinen Rahmen haben, kann man diese im Dokument nicht mehr einfach erkennen. Hier hilft der Formular-Navigator.

Nach dem Layout und der Erstellung der Formular-Felder kann das Dokument in eine PDF-Vorlage exportiert werden. Die geht mittels Datei –> Exportieren als PDF. Im folgenden Dialog muss PDF-Formular erzeugen markiert sein.

Editing a formular in OpenOffice

OpenOffice - PDF Template

Generated PDF Template

Teil 2 – PDF-Formular mit iText befüllen

Zum Befüllen des PDF-Formulars nutze ich in meinem Beispiel iText in der Version 2.1.7, da in späteren Versionen eine verschärfte Lizenz verwendet wurde.
Zunächst wird das PDF-Formular eingelesen…

PdfReader pdfTemplate = new PdfReader(pdfTemplateFile);

… und ein Stamper mit einem OutputStream erzeugt.

ByteArrayOutputStream out = new ByteArrayOutputStream();
PdfStamper stamper = new PdfStamper(pdfTemplate, out);

Damit im erzeugten PDF keine Formularfelder mehr enthalten sind, muss dem Stamper dies über folgendem Aufruf mitgeteilt werden.

stamper.setFormFlattening(true);

Zum Abschluß können jetzt die Felder gefüllt werden…

stamper.getAcroFields().setField("name", "Daniel Reuter");
stamper.getAcroFields().setField("adress", "Merscheider Str.1 – 42699 Solingen");
stamper.getAcroFields().setField("dates", "2008\n2009\n2010\n");
stamper.getAcroFields().setField("titles", "JAX\nDevoxx\nJavaOne\n");

…und natürlich die Resourcen geschlossen werden.

stamper.close();
pdfTemplate.close();

Fazit

Aus meiner Sicht ein sehr einfacher und leicht verständlicher Ansatz. Sicherlich wird es Szenarien geben, in denen der beschriebene Weg nicht passt. Insbesondere bei dynamischen Layouts stößt man hier an die Grenzen. Dennoch würde ich versuchen, als Grundlage immer ein PDF Template zu verwenden.

PDF Result

Da wir uns starkt mit agiler Software Entwicklung beschäftigen, habe ich mich gefragt, was ein “Agiles Unternehmen” ausmacht. Also habe ich mal Google befragt und ein wenig nachgelesen. Eine gute Zusammenfassung findet man bei Business Dictionary:

Fast moving, flexible and robust firm capable of rapid response to unexpected challenges, events, and opportunities. Built on policies and processes that facilitate speed and change, it aims to achieve continuous competitive advantage in serving its customers. Agile enterprises use diffused authority and flat organizational structure to speed up information flows among different departments, and develop close, trust-based relationships with their customers and suppliers.

Grundsätzlich zusammengefasst sind “Agile Unternehmen” also die Unternehmen, die besonders schnell und flexibel auf sich ändernde Marktbedingungen reagieren können. In den meisten Artikeln, die ich gefunden habe werden Selbstorganisation und Interaktion zwischen Mitarbeitern und Abteilungen als Basis für agile Unternehmen gesehen. Aber was bedeutet das jetzt für die IT?

Aber zurück zum Artikel. Es geht um große ERP Systeme und das die meisten Unternehmen Schwierigkeiten haben auf die steigende Flexibilität und Geschwindigkeit des Business zu reagieren. Grund sind die hohe Komplexität der Systeme, teilweise schlechte Produktqualität, ein hohes Maß an Customizing an des Systemen und teilweise auch das Alter dieser Monolithen. Bleibt die Aussage: “ERP bremst Business!“.

Soweit so gut, viele der Aussagen sind bis dahing für mich durchaus nachvollziehbar und sehen wir auch täglich in unseren Projekten. Nicht nur bei ERP Systemen, sondern bei vielen Standardsoftware “Monstern” – beispielsweise auch im Bereich der Versicherungskernsysteme. Ich habe mich immer gefragt, warum man zunächst viele Millionen in Lizenzkosten investiert, dann merkt, dass der “Standard” eigentlich nicht zu den eigenen Prozessen passt und man nur 20% der Funktionen benötigt. Deshalb führt man auch erst mal ein mehrjähriges Customizing Projekt durch. Meistens hat man die Software danach soweit angepasst, das sie nicht mehr Release fähig ist oder jedes Upgrade wieder mit hohen Anpassungsaufwänden verbunden ist. Aber das beste kommt noch: ca. 20% muss man jedes Jahr für die Wartung der Standard Software zahlen – sprich: Alle 5 Jahre hat man die Software noch mal gekauft.

Leider liefert der Artikel nicht wirklich interessante Lösungsszenarien. Zunächst wird bemängelt, dass die Strategien der ERP Hersteller die großen Versprechen von SOA nicht gehalten haben – insbesondere, weil die SOA von den Herstellern fast ausschließlich technisch betrachtet wurden.

Eine mögliche Lösung wird in der Cloud und in Software as a Service gesehen – da hat mich der Artikel dann auch entgültig abgehangen. Wenn ich also mein “Monster” nicht mehr selber betreibe, sondern in der  “Wolke”, dann sind meine Business Probleme weg und ich bin auf einmal flexibel und schnell!? Da scheinen einige der der Experten doch eher im “Nebel” zu stehen.

Da ich mich seit einigen Wochen damit beschäftige das “Why” für unsere Agile Software Factory zu finden, hat mir dieser Artikel wirklich sehr geholfen.

Aus meiner Sicht liegt die Lösung für das Problem doch klar auf der Hand:

Wenn Agile Enterprise heißt, dass mann innovativ sein (First Mover) und schnell reagieren (Fast Follower) muss, dann kann die Lösung doch nicht in “Standard” und “Monolithen” liegen. Standard ist definitiv nicht innovativ und Monolithen sind in der Regel komplex und wenig flexibel anzupassen.

Aus meiner Sicht muss man bei der Umsetzung der Geschäftsprozesse auf individuelle Software setzen. Die genutzten Komponenten können aber sehr wohl Standard sein. Was ich damit meine ist, dass ich niemandem empfehlen würde eine Buchhaltungssoftware inidividuell selber zu bauen – hier ist durch gesetzliche Vorgaben etc. wenig Innovation und Individualität zu erwarten. Allerdings können sich die Prozesse rund um die Buchhaltung sehr wohl stark unterscheiden und zu einem Wettbewerbsvortei werden. Kunden können über Web und Mobile direkt eingebunden werden, Geschäftsvorfälle können automatisiert werden und andere, eigene Systeme können sich direkt integrieren. Insbesondere kann man “Insellösungen” vermeiden und dem Benutzer eine einheitliche Oberfläche und schnelle Bearbeitung in einem System anbieten.

Um schnell und flexibel zu sein, mit unbekannten Anforderungen umgehen zu können und das Risiko von inidividueller Entwicklung zu reduzieren, muss man auf agile Vorgehensweisen setzen. Mit schwerfälligen Wasserfallmethoden und Projekten mit Laufzeiten von mehreren Monaten oder Jahren bis man dem Business etwas Lauffähiges anbieten kann, wird man heute nicht mehr konkurrenzfähig sein.

Genau das ist unsere Agile Software Factory: Ein etablierters Vorgehensmodell auf Basis von Scrum und XP mit vielen Best Practices (“Agile”) und dem Einsatz von standardisierten Komponenten und Frameworks (“Factory”).

Bei den Komponeten setzen wir meistens auf Open Source, da die verwendeten Standards und offene Quellen zu einer verbesserten Integrierbarkeit und schnelleren Entwicklung führen – zudem ist man weniger von der “Politik” einzelner Hersteller abhängig. Alfresco im Bereich ECM, Pentaho für Business Intelligence, Liferay als Portal Lösung, OpenCms als CMS  oder Compiere im Bereich ERP und CRM sind nur Beispiele für Open Source Komponenten, die wir in die Anwendungen unserer Kunden integrieren. Die individuellen Prozesse und Anwendungen werden dabei auch auf Basis von etablierten Best Practices mit Open Source Frameworks wie Spring, Hibernate, Drools, jBpm oder Mule entwickelt. Immer auf Basis leichtgewichtiger, evolutionärer Architekturen!

Die agile Vorgehensweise sorgt dafür, dass das Business alle 2-4 Wochen neue und benötigte Funktionen zur Verfügung gestellt bekommt – und das in hoher Qualität durch automatisierte Unit-, Regressions- und Systemtest, sowie kontinuierlicher Integration, Pair-Programming und automatisierter Code- und Designüberprüfungen.

Mein Fazit: Wenn wir als IT auf sich schneller ändernde Business Anforderungen reagieren wollen (“Agile Enterprise”), dann müssen wir uns von großen “Standardsoftware Mostern” und langlaufenden Projekten trennen. Die Lösung für mich sind agile Projekte – allerdings auf Basis von standardisierten Anwendungsbausteinen und Frameworks.