In einer kurzen Demonstration Session auf dem OOPSLA 2008 habe ich gestern ein interessantes Tool kennengelernt. Mit dem Testability Explorer von Google kann Java Code dahingehend untersucht werden, wie testable die Klassen sind. Der Testability Explorer wird von Misko Hevery von Google betreut, der auch die Session auf der OOPSLA gegeben hat.
Zusammengefasst ist der Testability Explorer ein Command Line Utility mit dem sich Packages innerhalb jar-Files scannen lassen. Für jede Klasse aus diesen Packages wird ein Score vergeben, der sich daran orientiert, wie gut sich die Klasse in einem Unit Test testen lässt. Anschliessend wird für alle Metriken ein HTML Report erstellt, in dem die vergebenen Scores und alle gefundenen Probleme einsehen lassen.
Der Score basiert nach Aussage von Hevery grob gesagt darauf, welche Anstrengungen notwendig sind um einzelne Methoden isoliert und mit Mock Objekten zu testen. In der Demonstration wurde die Funktionsweise des Testability Explorers an einem Servlet aus einer Bibliothek demonstriert, die Hevery selbst vor einigen Jahren implementiert hatte. In der Service Methode des Servlets, wurde der HttpServletRequest in einem grossen if-else Block und abhängig von verschiedenen Conditions an verschiedene andere Servlet Implementierungen delegiert. Dabei wurde jedesmal eine neue Instanz mit dem new Keyword erzeugt. Im ersten Testlauf hatte das angesprochene Servlet einen Testability Score von über 9000. Je höher der Score desto schwerer lässt sich der Code testen. Im ersten Schritt wurden alle lokalen Objekterzeugungen in Fields konvertiert und mehrere Constructors hinzugefügt um somit die Tür für beispielsweise Dependency Injection zu öffnen. Dieser Schritt brachte bereits eine deutliche Verbesserung der Testbarkeit.
In einem zweiten Refactoring wurde die Anzahl der statischen Methodenaufrufe minimiert, bzw. die Implementierung der aufgerufenen Klasse auf Instanzmethoden umgestellt. Gerade dann, wenn der Client gegen ein Interface arbeitet und dort Instanzmethoden aufruft, wird das Testen um einiges leichter. Ein weiteres Problem der Servlet Klasse war die Verwendung eines zu breiten Scopes der verwendeten Objekte. Es wurde ein Repository Objekt in das Servlet hineingegeben, auf dem dann eine getPool().getConnection() aufgerufen wurde um mit der Connection weiter zu arbeiten. Das Problem dabei ist, dass dabei sehr viel mehr Schritte notwenig sind um für das Connection Objekt einen Mock Ersatz bereitzustellen. Um eine MockConnection zu erhalten, müssen ebenfalls das Repository und der Pool ”gemocked” werden. Eine entsprechende Mitteilung lässt sich sehr schön im Testreport des Testability Explorers ablesen. Die Lösung für das Problem an dieser Stelle war die direkte Verwendung und Übergabe der Connection im Constructor anstelle des kompletten Repository Objekts.
Der Testability Explorer untersucht unter der Haube jedoch nicht nur die statischen Probleme im Sourcecode. Vielmehr wird der Java Bytecode untersucht um weiterhin Probleme durch inkorrekte Verwendung von statisch globalem Objekten zu finden. Wie das genau funktioniert, konnte Hevery jedoch aufgrund von Zeitmangel nicht vorstellen. Das Open Source Projekt wird auf code.google.com gehostet und steht jedem zur Verfügung. Das es noch nicht sehr weit verbreitet ist, kann man unter anderem daran erkennen, dass Plugins für IDE's und Continuous Integration Server fehlen. In einem unserer nächsten Projekte will ich den Testability Explorer jedoch austesten und in diesem Rahmen ein Hudson Plugin schreiben. Ich denke gerade in Projekten mit vielen Junior Entwicklern ohne ausreichende TDD Erfahrung, kann der Testability Explorer schon sehr früh Metriken liefern, wie gut sich der Code des Teams testen lässt. In der Regel stösst man nämlich erst sehr viel später auf Probleme der Testbarkeit. Nämlich dann wenn die Testabdeckung einzelner Klassen oder Pakete zu niedrig ist. Soweit wie Google zu gehen, die ein Check-In von Code zurückrollen, wenn die eingecheckten Klassen nicht testbar genug sind, werden wir in unserem Team aber nicht gehen.
Security – Philosophie, Patterns und praktische Beispiele
So oder so ähnlich würde der ins Deutsche übersetzte Titel meines ersten Tutorials von der OOPSLA 2008 lauten. In fast vier Stunden hat Munawar Hafiz von der Universität of Illinois, uns in die Welt der Security Patterns eingeführt. Hafiz arbeitet mit Ralph Johnson (der von der Gang of Four) zusammen und hat an etlichen Publikationen über Security Patterns mitgearbeitet.
In seinem Tutorial geht es darum, verschiedene Patterns für die Sicherheit in Software Applikationen klassifizieren und anwenden zu können. Insgesamt hat Hafiz auf seiner Webseite mehr als 90 Patterns beschrieben und klassifiziert. Das Tutorial ist in zwei Teile aufgeteilt. Im ersten Teil demonstriert er zunächst welchen Einfluss Security auf die Software Architektur hat. Das ganze wird am Beispiel von sendmail durchgegangen. Zunächst stellt er Probleme von sendmail vor und zeigt wie diese mit qmail und postfix besser implementiert wurden. Hierbei geht er leider zu sehr ins Detail wie ich finde. Zwar werden bereits im ersten Teil einige Sicherheits Pattern vorgestellt (chroot jail, compartmentalization, secure pre-forking, single threaded facade, checkpoint system, content dependent processing etc.) aber er stellt die Architektur der drei genannten Mail Transfer Agents zu detailliert vor. Die Zeit wird später im zweiten Teil des Tutorials fehlen.
Nach einer kurzen Pause, lässt Hafiz die Teilnehmer an einem kleinen Spiel teilnehmen. Er lässt zwei Gruppen bilden. Dann verteilt er Blätter, die ein paar kurze, fiktive Geschichten aus der realen Welt enthalten. Zum Beispiel geht es um ein Army Camp, das von einer Seite aus beschossen wird, von der man keinen Angriff vermutet hat oder ein Königreich das für jederman zugänglich war und dessen König plötzlich ermordet wurde. Für jede Geschichte bildet eine Gruppe jeweils die ”Angreifer” und eine Gruppe die ”Verteidiger”. Jede Geschichte schliesst mit einer Frage an die ”Attacker” und die ”Security Experts” ab, in etwa ”Warum ist es vorher zu keinem Angriff auf den König gekommen”? Die Thematik wird dann in die Welt der Software übertragen und ein Security Pattern vorgestellt. Leider bricht Hafiz bereits nach 5 Geschichten ab, da er meint dass sich auf dem letzten Tutorial auf der OOPSLA 2007 alle am Ende gelangweilt hätten. Ich finde diese ”Übung” jedoch auflockernd und lustig.
Anders als erwartet, werden die verleibenden Security Patterns, die im Handout Material in Slides abgedruckt sind, nicht vorgestellt. Sehr schade wie ich finde. Der Pattern Katalog von Hafiz beinhaltet sehr viele gute Patterns, die sich auch in die Welt von Java und J2EE übernehmen lassen. Stattdessen beendet er das Tutorial, indem er in 30 Minuten durch eine Unmenge an Slides zu Buffer Overflow und SQL Injection durchrennt. Beide Problematiken sind mir zumindest ausreichend bekannt. Ich würde dieses Tutorial an erfahrene Entwickler und Architekten nur bedingt weiterempfehlen. Es wird sehr umfangreich auf Mail Transfer Agents der Linux Welt eingegangen und die eingentlich spannenden Patterns aus dem Security Catalogue nur kurz angerissen.
In seinem Tutorial geht es darum, verschiedene Patterns für die Sicherheit in Software Applikationen klassifizieren und anwenden zu können. Insgesamt hat Hafiz auf seiner Webseite mehr als 90 Patterns beschrieben und klassifiziert. Das Tutorial ist in zwei Teile aufgeteilt. Im ersten Teil demonstriert er zunächst welchen Einfluss Security auf die Software Architektur hat. Das ganze wird am Beispiel von sendmail durchgegangen. Zunächst stellt er Probleme von sendmail vor und zeigt wie diese mit qmail und postfix besser implementiert wurden. Hierbei geht er leider zu sehr ins Detail wie ich finde. Zwar werden bereits im ersten Teil einige Sicherheits Pattern vorgestellt (chroot jail, compartmentalization, secure pre-forking, single threaded facade, checkpoint system, content dependent processing etc.) aber er stellt die Architektur der drei genannten Mail Transfer Agents zu detailliert vor. Die Zeit wird später im zweiten Teil des Tutorials fehlen.
Nach einer kurzen Pause, lässt Hafiz die Teilnehmer an einem kleinen Spiel teilnehmen. Er lässt zwei Gruppen bilden. Dann verteilt er Blätter, die ein paar kurze, fiktive Geschichten aus der realen Welt enthalten. Zum Beispiel geht es um ein Army Camp, das von einer Seite aus beschossen wird, von der man keinen Angriff vermutet hat oder ein Königreich das für jederman zugänglich war und dessen König plötzlich ermordet wurde. Für jede Geschichte bildet eine Gruppe jeweils die ”Angreifer” und eine Gruppe die ”Verteidiger”. Jede Geschichte schliesst mit einer Frage an die ”Attacker” und die ”Security Experts” ab, in etwa ”Warum ist es vorher zu keinem Angriff auf den König gekommen”? Die Thematik wird dann in die Welt der Software übertragen und ein Security Pattern vorgestellt. Leider bricht Hafiz bereits nach 5 Geschichten ab, da er meint dass sich auf dem letzten Tutorial auf der OOPSLA 2007 alle am Ende gelangweilt hätten. Ich finde diese ”Übung” jedoch auflockernd und lustig.
Anders als erwartet, werden die verleibenden Security Patterns, die im Handout Material in Slides abgedruckt sind, nicht vorgestellt. Sehr schade wie ich finde. Der Pattern Katalog von Hafiz beinhaltet sehr viele gute Patterns, die sich auch in die Welt von Java und J2EE übernehmen lassen. Stattdessen beendet er das Tutorial, indem er in 30 Minuten durch eine Unmenge an Slides zu Buffer Overflow und SQL Injection durchrennt. Beide Problematiken sind mir zumindest ausreichend bekannt. Ich würde dieses Tutorial an erfahrene Entwickler und Architekten nur bedingt weiterempfehlen. Es wird sehr umfangreich auf Mail Transfer Agents der Linux Welt eingegangen und die eingentlich spannenden Patterns aus dem Security Catalogue nur kurz angerissen.
Erster Tag auf der OOPSLA
Mit einem Tutorial hat die OOPSLA nun für mich gestern begonnen. Wir hatten uns bereits sehr früh am Morgen in der Hotel Lobby verabredet. Während unserer Zeit in Nashville schlafen wir direkt Downtown im Marriot Courtyard Hotel in der 4th Avenue. Obwohl dieses Mariot nach Aussage eines Kollegen nur 3 Sterne hat, sind die Zimmer sehr gut. Leider konnte ich nicht besonders gut schlafen, da es Samstag Nacht um das Hotel herum sehr laut ist. Aufgrund der vielen kleinen Bars und Nachtclubs in der Nähe, sind bis früh um vier Leute auf den Strassen unterwegs und es geht oft lauftstark zu. Aber gut.
Nach einem mittelmässigen und mit $14 zu teurem Frühstück im Hotel, ging es ab zur OOPSLA. Das Nashville Convention Center ist nur 5 min Fussweg vom Marriot Courtyard in der 4th Ave. entfernt. Nach Vorlage unserer ausgedruckten Registrierungsbestätigung, bekam jeder eine Tasche von der OOPSLA, ein Shirt, eine CD, diverses Material über die Konferenz sowie ein Badge mit dem Namen drauf und den ganzen kostenpflichtigen Tutorials, für die man sich angemeldet hat. Das program der OOPSLA ist relativ unübersichtlich aufbereitet wie ich finde. Es gibt Tutorials, die dreieinhalb Stunden dauern und kostenpflichtig sind. Es gibt die regulären Sessions während der Hauptkonferenz, die parallel angeboten werden und zwischen 45 und 60 Minuten dauern. Zusätzlich gibt es noch Demonstrations, Lightning Talks, Workshops und Onward Events. Die separat gebuchten Tutorials wiederzufinden, ist ja noch relativ einfach. Aber einen optimalen Zeitplan für alle Sessions und Demonstrations die man sehen will zu erstellen, ist die Hölle. Glücklicherweise werden alle Demonstrations an mehreren Tagen angeboten, so dass man die Möglichkeit hat, eine parallel laufende Demonstration noch einmal später zu sehen. Schön finde ich, dass man im Vergleich zur Java One spontan entscheiden kan, in welche Session man gehen will. Auf der Java One ist der Platz begrenzt und man muss sich vorher für Panels anmelden.
Die OOPSLA Konferenz ist deutlich kleiner als die Java One. Ich würde schätzen, dass rund 2.000 Entwickler, Architekten und Manager die OOPSLA besuchen. Auf der Java One tummeln sich im Schnitt zwischen 10.000 und 20.000 Besucher. In meinem ersten Tutorial waren nur 9 Zuhörer. Es geht eher familiär zu. Schön finde ich das Tutorial Lunch, dass allen Besuchern der Tutorials zugänglich ist. In einem grossen Ballsaal, wird ab 12 Uhr Mittag serviert. Es sind jeweils Tische für 10 bis 12 Personen eingedeckt. Man trifft also ”zwangsläufig” auf andere Teilnehmer zum socializing. Ein Frühstück mit Kaffee und Kuchn wird auf der OOPSLA ebenfalls angeboten. Die Atmosphäre ist sehr locker. Man kommt mit anderen Besuchern sehr schnell ins Gespräch. Die meisten Entwickler, Architekten oder Consultants kommen aus der Java Welt. Aber auch zu .NET, C, C++ oder anderen Sprachen werden Veranstaltungen angeboten. Schauen wir mal, wie die Tutorials und Sessions so ablaufen.
Nach einem mittelmässigen und mit $14 zu teurem Frühstück im Hotel, ging es ab zur OOPSLA. Das Nashville Convention Center ist nur 5 min Fussweg vom Marriot Courtyard in der 4th Ave. entfernt. Nach Vorlage unserer ausgedruckten Registrierungsbestätigung, bekam jeder eine Tasche von der OOPSLA, ein Shirt, eine CD, diverses Material über die Konferenz sowie ein Badge mit dem Namen drauf und den ganzen kostenpflichtigen Tutorials, für die man sich angemeldet hat. Das program der OOPSLA ist relativ unübersichtlich aufbereitet wie ich finde. Es gibt Tutorials, die dreieinhalb Stunden dauern und kostenpflichtig sind. Es gibt die regulären Sessions während der Hauptkonferenz, die parallel angeboten werden und zwischen 45 und 60 Minuten dauern. Zusätzlich gibt es noch Demonstrations, Lightning Talks, Workshops und Onward Events. Die separat gebuchten Tutorials wiederzufinden, ist ja noch relativ einfach. Aber einen optimalen Zeitplan für alle Sessions und Demonstrations die man sehen will zu erstellen, ist die Hölle. Glücklicherweise werden alle Demonstrations an mehreren Tagen angeboten, so dass man die Möglichkeit hat, eine parallel laufende Demonstration noch einmal später zu sehen. Schön finde ich, dass man im Vergleich zur Java One spontan entscheiden kan, in welche Session man gehen will. Auf der Java One ist der Platz begrenzt und man muss sich vorher für Panels anmelden.
Die OOPSLA Konferenz ist deutlich kleiner als die Java One. Ich würde schätzen, dass rund 2.000 Entwickler, Architekten und Manager die OOPSLA besuchen. Auf der Java One tummeln sich im Schnitt zwischen 10.000 und 20.000 Besucher. In meinem ersten Tutorial waren nur 9 Zuhörer. Es geht eher familiär zu. Schön finde ich das Tutorial Lunch, dass allen Besuchern der Tutorials zugänglich ist. In einem grossen Ballsaal, wird ab 12 Uhr Mittag serviert. Es sind jeweils Tische für 10 bis 12 Personen eingedeckt. Man trifft also ”zwangsläufig” auf andere Teilnehmer zum socializing. Ein Frühstück mit Kaffee und Kuchn wird auf der OOPSLA ebenfalls angeboten. Die Atmosphäre ist sehr locker. Man kommt mit anderen Besuchern sehr schnell ins Gespräch. Die meisten Entwickler, Architekten oder Consultants kommen aus der Java Welt. Aber auch zu .NET, C, C++ oder anderen Sprachen werden Veranstaltungen angeboten. Schauen wir mal, wie die Tutorials und Sessions so ablaufen.
Auf zur OOPSLA
In dieser Woche bin ich auf einer Konferenz in Nashville mit dem lustigen Namen OOPSLA. Auf dieser Konferenz, die einmal im Jahr stattfindet, geht es hauptsächlich um Aspekte der objektorientierten Programmierung. Allerdings finde ich, dass die meisten Sessions Aspekte aus der Java Welt aufgreifen. Der Name Java Konferenz ist demnach nicht ganz falsch. OOPSLA kann von der Vielfalt der Java Talks und Sessions jedoch nicht anderen reinen Java Konferenzen wie Java One oder Javoxx mithalten.
Die eigentliche OOPSLA 2008 beginnt erst am Dienstag. Heute am Sonntag und morgen am Montag werden lediglich kostenpflichtige Tutorials angeboten. Diese dauern jeweils zirka 4 Stunden und ich hoffe, dass man dabei ein wenig in die Tiefe gehen wird. Meine Firma hat mich für 4 Tutorials meiner Wahl eingetragen. Es geht darin jeweils um Security Patterns allgemein, Spring OSGI, Google Guice und Google Berry sowie um effective Java. Ich werde darüber später ausführlich berichten. Von Dienstag bis Donnerstag gibt es dann die Hauptkonferenz. Dort finden sehr viele, einstündige Sessions zu diversen Themen statt. Jeder der den einmaligen Entry Fee für die OOPSLA bezahlt hat, kan daran teilnehmen.
Da es bisher noch nicht soviel über OOPSLA zu schreiben gibt, noch ein paar Anmerkungen zur Einreise in die USA. Unser Flug ging mit Continental Airlines von Stockholm nach Newark und von dort nach Nashville. Bereits in der Schlage des Abfertigungsschalters wird von der Airline eine erste Security Überprüfung vorgenommen. Da ich als Deutscher mit deutschem, bordeauxfarbenem Reisepass und von Schweden aus fliegend, etwas aus der Reihe fiel, kam ich besonders in das Visier Continental Airlines Security Mitarbeiter. In schneller Abfolge wurden diverse Fragen gestellt: ”Wer hat das Gepäck gepackt”, ”Wo befand sich das Gepäck seit dem”, ”Hat Ihnen jemand etwas mitgegeben”? Ich musste sogar meine schwedische ID-Kort zu meinem Reisepass dazu zeigen. Beides wurde ausführlicher als bei schwedischen Reisenden überprüft.
Genauso unfreundlich war das die US Border Control (Homeland Security). Man musste jeweils den rechten und linken Zeigefinger auf ein Pad legen und es wurde ein Bild mit der Webcam gemacht. Da ich vergessen hatte, die Rückseite meines Visa Waiver irgendwas auszufüllen, rief mich der Homeland Mitarbeiter lautstark zurück, dummerweise ohne dabei in meine Richtung zu schauen so dass ich einige Sekunden brauchte um zu realisieren, dass er mich meinte. Ich schätze nicht viel länger und er hätte mich unsanft zurückholen lassen.
Die letzte Neuerung für mich war dann die Security Kontrolle auf dem Newark Airport. Man muss wie in Deutschland alle Hosentaschen leeren und den Gürtel ablegen. Zusätzlich müssen die Schuhe ausgezogen werden. Dann muss man in eine Art Fotobox steigen, die den abschreckenden Namen Sentry II trägt. Darin wird man dann von allen Seiten mit Luftdruck angepustet um Spuren von Explosives zu entdecken. Eine Computerstimme sagt vorher ”Firing Gun” - irgendwie kontra-produktiv wie ich finde. Ein System zum Aufspüren von Waffen, dass Firing Gun sagt.
Die eigentliche OOPSLA 2008 beginnt erst am Dienstag. Heute am Sonntag und morgen am Montag werden lediglich kostenpflichtige Tutorials angeboten. Diese dauern jeweils zirka 4 Stunden und ich hoffe, dass man dabei ein wenig in die Tiefe gehen wird. Meine Firma hat mich für 4 Tutorials meiner Wahl eingetragen. Es geht darin jeweils um Security Patterns allgemein, Spring OSGI, Google Guice und Google Berry sowie um effective Java. Ich werde darüber später ausführlich berichten. Von Dienstag bis Donnerstag gibt es dann die Hauptkonferenz. Dort finden sehr viele, einstündige Sessions zu diversen Themen statt. Jeder der den einmaligen Entry Fee für die OOPSLA bezahlt hat, kan daran teilnehmen.
Da es bisher noch nicht soviel über OOPSLA zu schreiben gibt, noch ein paar Anmerkungen zur Einreise in die USA. Unser Flug ging mit Continental Airlines von Stockholm nach Newark und von dort nach Nashville. Bereits in der Schlage des Abfertigungsschalters wird von der Airline eine erste Security Überprüfung vorgenommen. Da ich als Deutscher mit deutschem, bordeauxfarbenem Reisepass und von Schweden aus fliegend, etwas aus der Reihe fiel, kam ich besonders in das Visier Continental Airlines Security Mitarbeiter. In schneller Abfolge wurden diverse Fragen gestellt: ”Wer hat das Gepäck gepackt”, ”Wo befand sich das Gepäck seit dem”, ”Hat Ihnen jemand etwas mitgegeben”? Ich musste sogar meine schwedische ID-Kort zu meinem Reisepass dazu zeigen. Beides wurde ausführlicher als bei schwedischen Reisenden überprüft.
Genauso unfreundlich war das die US Border Control (Homeland Security). Man musste jeweils den rechten und linken Zeigefinger auf ein Pad legen und es wurde ein Bild mit der Webcam gemacht. Da ich vergessen hatte, die Rückseite meines Visa Waiver irgendwas auszufüllen, rief mich der Homeland Mitarbeiter lautstark zurück, dummerweise ohne dabei in meine Richtung zu schauen so dass ich einige Sekunden brauchte um zu realisieren, dass er mich meinte. Ich schätze nicht viel länger und er hätte mich unsanft zurückholen lassen.
Die letzte Neuerung für mich war dann die Security Kontrolle auf dem Newark Airport. Man muss wie in Deutschland alle Hosentaschen leeren und den Gürtel ablegen. Zusätzlich müssen die Schuhe ausgezogen werden. Dann muss man in eine Art Fotobox steigen, die den abschreckenden Namen Sentry II trägt. Darin wird man dann von allen Seiten mit Luftdruck angepustet um Spuren von Explosives zu entdecken. Eine Computerstimme sagt vorher ”Firing Gun” - irgendwie kontra-produktiv wie ich finde. Ein System zum Aufspüren von Waffen, dass Firing Gun sagt.
Buchkritik: Pro Java EE Spring Patterns
In regelmäßigen Abständen gibts vom Manager meiner Abteilung eine Email, ob denn irgendjemand Bücher bestellen will. Ich habe mich diesmal für ein neues Werk aus dem Apress Verlag mit dem imposanten Namen „Pro Java EE Spring Patterns“ entschieden. Rechtzeitig vor dem Urlaub auf Rhodos, fand das gut 300 Seiten dicke Buch den Weg auf meinen Schreibtisch.
Um es gleich vorweg zu nehmen, das Buch ist für Java Entwickler und Architekten mit Spring Erfahrung eher eine Enttäuschung. In den ersten beiden Kapiteln wird kurz auf die Entstehung der n-Tier Applikationen und des Spring Frameworks eingegangen. Wer keine Lust auf die x-te Einführung in Dependency Injection, Spring AOP und Spring MVC hat, kann gleich zu Kapitel 3 vorblättern. Die restlichen Kapitel 3 bis 6 beschreiben verschiedene Patterns aus dem Java EE und Spring Bereich. Jedes Kapitel geht dabei auf Entwicklungsmuster aus den Schichten Presentation,- Business und Integrations,- und Cross Cutting Concern Tier ein. Das finale Kapitel soll an einem fiktiven Applikationsbeispiel die Anwendung der verschiedenen Patterns demonstrieren. Dazu später mehr.
Die erste Enttäuschung ist Kapitel 3, welches Patterns aus der Präsentationsschicht beschreibt. Namentlich sind das Front Controller, Application Controller, Page Controller, Context Object, Intercepting Filter, View Helper, Composite View, Dispatcher View und Service to Worker. Der Aufbau und die Vorstellung jedes Patterns ist so aufgebaut, dass zunächst die Problemstellung anhand einer Java Anwendung aus dem Versicherungsbereich vorgestellt wird. An dieser Anwendung hat der Autor von „ Pro Java EE Spring Patterns“ wohl selbst mit entwickelt. Die Applikation scheint leider etwas an den Haaren herbei gezogen. Eine Handvoll JSP Dateien mit else-if Blöcken als Ersatz für verschiedene Controller Actions traue ich selbst der schlechtesten Web-Anwendung nicht zu. Wie dem auch sei, die e-Insurance Webapplication muss immer als schlechtes Beispiel herhalten, bevor mit Hilfe eines Patterns gezeigt wird, wie es besser mit J2EE und Spring geht.
Leider stellen die meisten der genannten Pattern der Präsentationsschucht dabei keine neuen Erkenntnisse dar, sondern lediglich die von Spring propagierte Vorgehensweise für die Implementierung. Das Page Controller und das View Helper Pattern ist also nichts weiter, als eine ganz normale Implementierung mit Spring MVC. Intercepting Filter stellt nicht invasive Möglichkeiten vor, mit einem Servlet Filter oder einem Spring MVC Interceptor Cross Cutting Concerns wie Tracing zu implementieren. Das Context Object Pattern propagiert die nicht direkte Verwendung von Klassen aus der Servlet API zur besseren Wiederverwendbarkeit der Controller Klassen. Auch keine neue Information. Für mich interessant sind lediglich Erwähnung und kurze Integrationsbeispiele mit zwei Opensymphony Produkten (Sitemesh und Clickstream) sowie Apache Tiles.
Weiter geht es mit der Business-Schicht in Kapitel 4. Hier werden die Pattern Service Locator, Business Delegate, Session Facade, Application Service und Business Interface vorgestellt. Leider auch wenig neue Informationen für Entwickler mit mehrjähriger Erfahrung im Java Bereich. Service Locator für enkapsulierte JNDI Zugriffe - ein alter Hut. Business Delegate als Proxy für Zugriffe einer Schicht in die jeweils andere, entspricht der Standard Implementierung mit Spring. Business Interface stellt eine Methode vor, um in EJB Remote Interface und Bean Implementierung synchron zu halten
Weitere Anwendungsfälle werden in Kapitel 5 für die Integrationsschicht vorgestellt. Dieses Kapitel ist völlig überflüssig. Es werden drei Pattern vorgestellt, die meiner Meinung nach seit Spring 1.x bekannt sind. Data Access Object (DAO), Procedure Access Object (das gleiche wie DAO nur mit Stored Procedures) sowie Web Service Broker (Implementierung eines Webservices auf Basis von Spring jeweils mit Apache Axis 2 und Burlap). Bereits hier sollte spätestens klar werden was „Pro Java EE Spring Patterns“ eigentlich ist. Man nehme die Spring Dokumentation, suche sich die besten Kapitel heraus und ordne jedem Kapitel ein Pattern aus der Java Welt zu. Das Ergebnis wird unter „Pro Java EE Spring Patterns“ in neuer Aufmachung verkauft. Spring Einsteiger sollten besser „Spring 2.0 im Einsatz“ von entwickler.press sowie „Expert Spring MVC und Web Flow“ von Apress lesen. Alte Hasen werden in „Pro Java EE Spring Patterns“ nicht wirklich viel neues entdecken.
Bleiben noch die letzten beiden Kapitel von „Pro Java EE Spring Patterns“ zu erwähnen. Kapitel 6 „Exploring Cross Cuting Design Patterns“ ist nichts weiter als ein Abriss über Acegi Security, AOP und die Implementierung von Transaction Handling mit Spring AOP. Kapitel 7 beschreibt eine fiktive Order Management Anwendung unter Verwendung einiger weniger der vorgestellten Anwendungsmuster. Das letzte Kapitel ist relativ kurz und beschäftigt sich hauptsächlich mit der agilen Planung der Projekt-Iterationen und der Einrichtung des Maven Projekts unter einer Eclipse basierten IDE.
Fazit: das Buch ist definitiv nicht für Entwickler mit Erfahrung im Bereich Spring. Die vorgestellten Patterns entsprechen zu großen Teilen der Art, wie man Spring Anwendungen standardmäßig implementiert. Anfänger lesen besser andere Einführungsbücher für das Spring Framework. „ Pro Java EE Spring Patterns“ ist für das Kennenlernen von Spring zu oberflächlich. Ein Buch das glücklicherweise mein Arbeitgeber bezahlt hat.
Abonnieren
Posts (Atom)