Beim dritten und letzten Tag gab es (leider) keine KeyNote. Statt dessen sollten an diesem Tag die Sessions länger anhalten, so das auch evtl. Code Beispiel gezeigt werden können.


OSGi, a New Foundation for Enterprise Apps

In dieser Session, von Adrian colyer und Costin Leau ging es um das Thema OSGI (Open Service Gateway Interface). Ein weiterer Schwerpunkt der Session war natürlich Spring-OSGI welches sich gerade in der Version 1.0-m2 befindet. Während der ganzen session war der Saal sehr voll, was auf ein sehr starkes Interesse an diesem Thema zurückzuführen ist. Nach eine kurzen Begriffsdefinition ging Adrian auf die Merkmale von OSGI ein. OSGI definiert einzelne abgeschlossene Programmpakete als so genannte Modules. Innerhalb eines OSGI Ökosystems sind dabei die Module sehr stark voneinander isoliert, dies macht sich vor allem durch den dedizierten ClassLoader für jedes Modul bemerkbar.

Ein Modul kann mehrere Abhängigkeiten zu weiteren Modulen haben, oder aber eben auch von anderen verwendet werden. Die Auflösung der Abhängigkeiten erfolgt dabei durch den OSGI Container selbst. Als Entwickler müssen lediglich die Abhängigkeiten in einem Manifest.mf File definiert werden, anschließend kümmert sich der Container um die Auflösung der Abhängigkeiten.
Einer der (meiner Meinung nach) wichtigsten Merkmale ist mit Sicherheit der Versionierungssupport von OSGI. So können mehrere Versionen eines Modules gleichzeitig innerhalb eines OSGI Systemes betrieben werden. Dies war bis heute durch die klassischen J2EE Applikationsserver nicht möglich.
Die Installation eines Modules erfolgt im laufen Betrieb, dabei wird ein Modul zuerst deployt. Die OSGI Runtime überprüft nun ob alle Abhängigkeiten für diese Modul vorhanden sind. Falls dies der Fall ist, kann das Module durch die Administrationskonsole gestartet werden.

Anschließend übernahm Costin die Session und führte in das Thema Spring-OSGI ein. Spring-OSGI wird hauptsächlich von Interface21 entwickelt, weitere Entwickler kommen dabei aus dem Hause BEA und ORACLE. Costin ging auf die Schwierigkeiten während der Entwicklung von Spring-OSGI ein, durch die sehr hohe Dynamik innerhalb eines OSGI Systemes (“Services kommen und gehen”) gestaltet sich die Implementierung eines Anwendungsframeworks als schwierig.
Beindruckend an der Session (und an Spring-OSGI) ist allerdings, das sämtliche Schwierigkeiten welches diese hohe Flexibilität mit sich bringt, durch die Spring Integration gelöst werden. Ein weitere sehr Beindruckendes Thema war der Testsupport, durch die starke Modularisierung und deren Isolation macht es für den Integrationstest nur Sinn diesen innerhalb OSGI Containers durchzuführen. Für diesen Integrationstest stellt Spring-OSGI sehr mächtige Klassen bereit, welche z.b. das Starten und Stoppen eines Containers übernehmen. Es werden ebenfalls ad-hoc die zu testenden Module gebaut und im OSGI System installiert.
Den Abschluss der Session stellte die Roadmap dar, ein sehr wichtiger Meilenstein ist dabei die 1.0 Final Version. Anschließend soll der Web support für Spring Web/Spring Webflow ausgebaut werden.

Alles in allem bleibt das Thema Spring-OSGI sehr interessant, ich verfolge das zumindest mit sehr großer Vorfreude da bereits einige Use-Cases im Kopf zu diesem Thema rumschwirren.

A Fast Hop into Real Object Oriented (ROO) Apps

Ben Alex stellte in dieser Session das Real Object Oriented (ROO) Frameowrk vor. Bei dem ROO Framework welches derzeit nicht öffentlich ist, aber bereits bei mehreren Kunden (u.a. Woolworths Australien) im Einsatz ist handelt es sich um ein Anwendungsframework. Das Ziel des Frameworks ist die starke fokussierung auf das eigentliche Domain Modell (Domain Driven Design), die umliegenden Artefakte für das Domain Modell (Repositories etc.) sollen dabei so weit wie möglich generiert werden. Spezifische Artefakte wie z.B. Suchafragen sollen elegant in die generierten Artefakte integriert werden.
Nach einer kurzen theoretischen Einführung ging Ben Anhand eines Beispiels durch die (sehr spannende ) Session.

Am Anfang steht das Domain Modell
Zuerst wird das Domain Modell transaprent von irgendwelchen Querschnittsbelangen (z.B. Persistenz, Security) implementiert. Das ganze geschieht über herkömmliche POJO Klassen. Anschließend wird mit einem Maven Plug-in die Generierung durchgeführt.
Als Ergebnis entsteht zu einem ein Hibernate Mapping File, ein (generisches) Repository, und eine Finder Klasse. Als weiteres wird eine ServiceLayer Fassade generiert, welche zudem generierte DTO (Data Transfer Objects) entgegen nimmt und mittels einem Assembler (Dozer) in die entsprechenden Domain Objekte überführt (und natürlich zurück).
Anschließend wird das Domain Modell iterativ erweitert, nach jeder Iteration findet eines generierung statt. Nachdem das Domain Modell einen stabilen Stand erreicht hat, können nun die Finder Methode implementiert werden, dazu wird eine Abstraktion von ROO zur Verfügung gestellt. (Ähnlich der Hibernate Criteria API).
Ben ging dann noch auf weitere verschiedene Aspekte ein (Verwendung von DTOs etc.).
Am meisten hat mich die Einfachheit und Eleganz des Framework überrascht. Zu einem liefert das Framework einen stabilen Rahmen mit (Namen für die Finder etc.), zum anderen bietet es eine sehr hohe Flexibilität.

Das Framework wird (wie bereits oben erwähnt) bereits produktiv eingesetzt, leider hat Ben erst ab September für ROO Zeit so dass sich das erste Release noch hinziehen kann :-(

Zu dne letzten beiden Session kann ich leider nicht mhr viel schreiben, da ich diese aus anderen Gründen nur am Rande mitverfolgen konnte.