Agim Emruli

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.

Der zweite Tag began mit einer sehr amüsanten Keynote von Adrian Colyer dem CIO von Interface21. In dieser führte er zuerst in die unterschiedlichen Arten der Programmiersprachen ein. Einmal waren dies die typisierten Sprachen à la Java, dann stellte er die dynamisch typisierten sprachen á la Groovy dar. Die beste darstellung war aber auf jeden Fall die Vorstellung von DuckTyping. Adrian stellte das ganze sehr plastisch dar, wie seine eavluierung ducktyping ist. Weitere mit Sicherheit nicht so amüsante über Ducktyping finden sich hier.
Adrian stellt weiterhin das komplette Portfolio des Spring Ökosystems dar. Die sind natürlich das Spring Framework, Spring Webflow für das erstellen von Dialogabläufen in form von deklarativen Prozessen. Weitere Produkte sind Spring Security (bis Release 2.0 Aceig genannt), Spring OSGI zur Integration von Spring in OSGI, sowie Spring Batch für das ausführen von Batches im Java Umfeld.
Bei der Vorstellung von der Spring-IDE von Eclipse erwähnte Adrian auch, das in Vancouver, US auch ein neues Entwiclungszentrum von Interface21 entstehen soll. In diesem sollen Interface21 Entwickler und die Entwickler des Eclipse Mylyn Projektes zusammenarbeiten. Man darf also gespannt sein welches netten Innovationen aus diesem Labor heraus enstehen.
Adrian zeigt auch Fotos vom zukünftigen Entwicklungslabor in Southhampton sowie Bilder vom Labor in Florida.

Eric Evans

Nach der sehr lustigen und interessanten Keynote von Adrian übernahm Eric Evans, auf welchen beitrag ich mich persönlich bereits im Vorfeld gefreut habe. Eric stellte die Bedeutung von Modellen innerhalb von Softwareprojekten dar. Dabei zeigte er das Modelle nicht unbedingt irgendwelche UML Diagramme sein müssen oder auch können. Modelle sind die Abstraktion einer Themas für den entsprechenden Kreis. Dazu zeigte er einmal eine Karte von China auf. Die Karte stellte ein Modell für China und die umliegenden Gebiete dar, eine weitere Karte die er aufzeigte diente zur Navigation der Seefahrer. Beide Karten waren zwar im Prinzip Karten, aber diese stellten komplett unterschiedliche Abstraktionen dar. Bei den Karten zeigte Eric auch auf das bestimmte Themengebiete evtl. gar nicht der Realiät entsprechen. So war in der letzteren Karte das Größenverhätlnis von Gröndland nicht richtig dargestellt, aber nur dadurch Konten die Navigationlinien korrekt im Modell abgebildet werden.

Anschließend stellte Eric die provokante These in den Raum das ein Softwareprojekt nicht komplett “sauber” designt werden kann, statt dessen sollte man sich dabei auf die Kerndömane des System fokussieren. Eine Kerndomain ist der einzige Busniess Treiber für die Software selbst damit diese erstellt werden soll, generische oder fremde Soubdomains (z.B. Rechnungserstellung bei einem Tracking System) sollte nur mit dem notwendigen Aufwand designt und gebaut werden. Evtl. sollten diese dazugekauft werden.
Ich denke das entspricht auch der Realität ausserhalb der Softwareentwicklung wieder, ein Unternehmen besteht im wesentlichen auf dem Markt in dem es in der Kerndömäne entsprechende Prozesse definiert und sich dadurch Wettberwerbvorteile sicher. Generische Subdomains oder fremde Subdomains werden dann von Unternehmen gekauft oder eben selbst nur in dem maß verfolgt wie das für die Ausführung der Kerndömäne notwendig ist.

Anschließend zeigte Eric aus dem Projektleben heraus eine Problemstellung in der zwei unterschiedliche Softwareprodukte miteinander kommunizieren müssen. Eric zeigt dabei untrschiedliche Alternativen von der Neutentwicklung bis zum Hacking auf. Dabei stellte er die Vor und Nachteile dar.

Bei einer kompletten Neuentwicklung sind die größten Nachteile das die Entwicklung erst z.B. 2 Jahre braucht um die Funktionalität der alten Lösung zu implementieren. Erst im dritten Jahr können anschließend die neuen Features implementiert werden. Hierbei stellte auch Eric die Probleme in den Vordergrund, während bei einer kompletten Neuimplementierung Anfangs eine große euphorie herrscht, sind die Projektbeteiligten in der Regel nach der Migration sehr gefrustet, da lediglich eine Code Portierung statt gefunden hat und eine neuen Features implementiert wurden.

Bei der Hacking Lösung besteht das Problen darin das die Features des neuen Systems nun überall verstreut ist, dies wäre zu einem die beiden bestehenden System zum anderen die “gehackten” Verbindungen. Die Lösung besteht indem man sich auf die Kerndomäne der neuen Features konzentriert und für die Kommunikation zu den beiden System einen “Anti-Corruption-Layer” einsetzt. So kann die Kerndomäne im neu zu erstellenden System sauber in einem isolierten Bereich implementiert werden.
Dabei ist es auch nicht unüblich das die Implementierung des Anti-Corruption-Layers aufwändiger als die Implementierung der Kerndomäne ist.

Bei der Implementierung eines Anti-corruption-Layers ist auch die Pflege einer Context-map notwendig, da ein Wort bei den (in diesem Beispiel 3) unterschiedlichen Modellen auch unterschiedliche Bedeutungen haben kann.

Also wäre Lösung der Problemstellung der weitere Betrieb der beiden Alt-Systeme, die neu zu erstellenden features werden in eine Kern-Domäne implementiert, diese wiederum kommunieren über einen Anti-Corruption-Layer mit den beiden Alt-Systemen. Mittels eines Kontextmap werden die drei unterschiedlichen Modelle konsistent gehalten.

Alles in allem war der Talk von Eric sehr interessant, ich denke vor allem wenn man sein Buch gelesen hat, sind die Talks eine nette Ergänzung dazu.

Spring Beyond the Obvious - using Spring in complex enterprise projects

Alef Anderesen und Joris Kuipers stellten in diesem Talk die unterschiedlichen Probleme bei einer Anwendung während dem Deployment dar. Dabei stellt Joris erstmal dar wie man einen Applicationcontext innerhalb einer EAR Datei für alle Module verwenden kann. So kann man zum Beispiel beim Einsatz von Hibernate, welches in zwei unterschiedlichen Projekten verwendet wird, die SessionFactory auf EAR Ebene im ApplicationContext konfigrurieren. So lassen sich Ressourcen und evtl. Konfigurationsduplikate vermeiden. Joris hat zu diesem Thema bereits einen Blog geschrieben welcher hier zu lesen ist. Anschließend widmete sich Joris dem Problem wie man eine Anwendung über mehrere Stages verteilen kann (Test/Integration/Produktion). Das Ziel dabei ist es Application Context Konfigurationen zu haben welche für alle Stages und weitere Konfigurationen zu haben welches nur für eine Stage gelten (Datasources, Transaktionsmanager).
Die Lösung besteht darin, indem man alle Stages spezifsichen Konfigurationen im classpath pflegt und die Logik für das laden der Konfigurationen implementiert. So kann man zum Beispiel im ClassPath folgende Struktur anlegen

/src/resources/test/applicationContext.xml
/src/resources/inte/applicationContext.xml
/src/resources/prod/applicationContext.xml

Nun überschreibt man beim ContextLoader die Methode createWebApplicationContext() in welcher die Konfigurationsdateien geladen werden. Dabei muss die Implementierung zum Beispiel durch ein System Paramter die Pfadnamen an die entsprechenden Stages anpassen. Anschließend muss man beim ContextLoaderListener die Methode createContextLoader überschreiben, damit der selbst implementierte ContextLoader anstelle des ContextLoaders verwendet wird.

An dieser Stelle merkt erkennt man die hohe Flexibiliät des Spring Framework. So kann man mit wenigen Zeilen Code seine komplexe Staging Strategie in das Framework einbinden. Das Spring sowas nicht out-of-the-box mitliefert ist dahingehend verständlich, weil jedes Projekt doch sehr spezifsiche Anforderungen an das Deployment einer Anwendung hat.

Insgesamt war das ganze eine sehr gelungene Session, in dieser Joris für sehr komplexe Problemstellungen elegante Lösungswege präsentiert hat.

Messaging and concurrency with Spring

Ich konnte diesen Talk leider nicht vollständig verfolgen, sondern bin erst gegen später dazu gestoßen. Jürgen Höller stellt in diesem Talk die unterschiedlichen Unterstützungen von JMS im Spring Framework vor. Dabei behandelte er zu einem das JMSTemplate welche für das versenden und synchronen Empfangen von Nachrichten verwendet wird, zum anderen die MessageListenerContainer welche für das asynchrone Empfangen von JMS Nachrichten verwendet werden. Dabei stellte er auch die Möglichkeit dar, wie man unterschiedliche Transaktionmanager verwenden kann (JTA, local JMS). Anschließend stellte Jürgen die neuen JMS Namespaces dar, welche in Spring 2.1 verfügbar sind. Mit den JMS Namespaces wird die Konfigurationen der MessageListenerContainer vereinfacht, dies macht sich vor allem beim Einsatz von mehreren Containern bemerkbar. Anschließend führte Jürgen durch die neue JCA Unterstützung für das Empfangen von JMS Nachrichten. Beim JCA Listener findet kein polling durch den Spring Container statt, vielmehr ist diese die Aufgabe des JCA Konnektor. So wird der Spring Container nur dann aktiv wenn wirklich eine Nachricht eintrifft.
Im Prinzip könnte man nun meinen das der Einsatz vom JCA Adapter immer besser ist. Ich denke das ist nicht immer der Fall, ein JCA MessageListener Container macht nur dann Sinn wenn ich auf einem J2EE Server deploye (der MessageListenerContainer wird dabei als RAR deployt), oder aber der JCA Connector wirklich für JCA optimiert ist, und nicht nur selbst ein pooling durchführt, wie es der derzeitige MessageListenerContainer auch macht. An dieser Stelle würde ich dann den MessageListenerContainer vorziehen, da dieser flexibel konfigurierbar ist.

IBM WebSphere & Spring - Together for some time now

Auf diese Session war ich besonders aufgrund meiner Vergangenheit mit Spring und Websphere sehr gespannt. Sara Mitchell wollte dabei in dieser Session die Zusammenarbeit von IBM und Interface21 erläutern. Das Ziel der Zusammenarbeit ist die Zertifzierung von Spring auf den Websphere Application Servern. Sara zeigte erstmal auf das in den vorherigen Websphere Application Server der Transaktionsmanager nicht veröffentllicht wurde, so konnte man mit Spring keine JTA Transaktionen pausieren und wieder fortsetzen. Mit dem neuen 6.0.x und 6.1.X Application Server soll sich dies ändern, Websphere liefert dazu einen WebsphereUoWTransactionManager mit, welcher mit Spring 2.1 eingesetzt wird. Dadurch unterstützt nun Spring 2.1 sämtliche Transaktionssemantiken (pausieren, fortetzen etc.).
Rod Johnson hat zu diesem Thema auch einen Blog geschrieben, welcher hier nachzulesen ist.
Anschließend hat Sara nochmals das Thema Spring MDP auf dem Websphere Applicaton Server besprochen. Spring MDPs werden nicht offiziel von IBM unterstützt, sie sagte aber selbst das einige Projekte bereits Spring MDP erfolgreich auf dem Websphere Application Server betreiben. Ich habe auch hierzu mal einen Blog geschrieben.
Ein weitere Punkt war JMX, zu diesem zeigte Sara ein Beispiel mit den entsprechenden Hinweisen wie diese zu verwenden sind. Weitere Informationen dazu befinden sich im (stark überarbeiteten) developerworks Artikel.
Den Rest der Session beschäftigte sich Sara mit EJB3 und Jax-WS, dabei bermerkte sie das IBM einen Feature Pack für Websphere 6.1 released hat, in welchem EJB3 unterstützt wird. Nach einer kurzen Vorstellung von Session/Stateless Beans sowie JPA unter Websphere war die Session Zeit auch schon vorbei. Mir persönlich hat der letzte weniger gefallen, da dies doch sehr stark am Thema vorbei gegangen ist.

Modeling without over-constraining

In dieser Session ging Eric Evans auf die Thematik der Implementierung von Regeln innerhalb eines DDD getriebenen Projektes ein. Dazu zeigte er ein simples Beispiel aus einem seiner (vielen) Projekte. Bei dem Beispiel ging es darum, das ein Kunde eine komplette Verschiffung einer Sendung plannen kann. Eine Verschiffung besteht dabei aus einer Reise, welche wiederrum aus mehreren Abschnitten besteht. Nun stellt sich hierbei die Frage wie die fachlichen Regeln implementiert werden. Eric plädierte in diesem Beispiel für den Einsatz eine Specification Objektes. Das Spezifikation Objekte überprüft die fachlichen Invarianten ob diese gültig sind. In dem oben genannten Beispiel muss zum Beispiel überprüft werden, ob die vorgeschlagene Reise im Zeitrahmen liegt, welchen der Kunde eingegeben hat.

Eric zeigte dann noch weitere Alternativen für das Implementieren von Regeln innerhalb eines DDD getriebenen Projektes auf. Zum Beispiel können oder auch sollen Regeln in Aggregate implementiert werden. Ein Aggregat hat unter anderem die Aufgabe, die Konsistenz von sich und allen Referenzierten Objekten sicherzustellen. Eine weitere Möglichkeit besteht darin die fachlichen Regeln evtl. im Repository zu implementieren.

Eric konnte auf diese Frage keine allgemein gültige Antwort geben, sondern viel mehr Beispiele nennen, wie er in konkreten Fällen die Regeln implementiert hat. Den Abschluss stellte eine interessante Fragenrunde dar. Dabei ging es Hauptsächlich um die Verwendung von UML für das Modellieren, und wie sich Aggregate damit abbilden lassen. Alles in allem war dies ein sehr interessanter Talk, welcher leider ein wenig zu kurz geraten ist.

Architecture with Spring

In dieser Session ging Eberhard Wolff auf Architekturen mit dem Spring Framework ein. Dabei stellte er von Anfang an die (meiner Meinung nach korrekte) These auf, das Architekturen sich nicht vollständig aus einem Blue Print ableiten lassen. Viel mehr muss ein Blue Print auf die eigene Umgebung gemappt werden, und vor allem man muss selbst darüber nachdenken :-).
Anschließend ging Eberhard auf die Implementierung des Persistence Layers ein. Der Persistence Layer sollte über DAOs (oder auch Repositories) implementiert werden, das schöne unter Verwendung von Spring ist die Transparenz des Persistence Layers. So kann eine Persistence Layer Implementierung bei de Verwendung des Spring Framework im Prinzip ausgetauscht werden, ohne das der Anwendungscode etwas davon mitkriegt. Dies funktioniert durch Dependency Injection, aber auch durch die entsprechen Exception Translation durch das Spring Framework. Mittels der Exception translation erhält man bei jeder DAO Implementierung die entsprechenden DataAccessException anstelle der Persistenzspezifsichen Exceptions.

Anschließend ging Eberhard auf die Implementierung der fachlichen Logik ein. Die fachliche Logik kann zu einem komplett im ServiceLayer implementiert werden, zum anderen aber auch in den Entitäten selbst. Der Nachteile bei der Implementierung innerhalb der ServiceLayer (entspricht dem Transaction Script Pattern) liegt in der häufigen Code Duplikation und den evtl. sehr groß werdenden Implementierungen. Ein Vorteil bei dieser Implementierung ist, das Domäne Objekte einfacher exportiert werden können.

Eberhard zeigte anschließend wie sich die fachlichkeit in den Entitäten selbst implementieren lässt, dabei ging er auf die Vor und Nachteile ein. Dabei stellte er auch die Frage in dem Raum, warum man überhaupt DAOs braucht, und nicht die Persistenz Artefakte in den Domänenobjekten selbst implementiert. Die Implementierung von Persistenz Artefakten in die Domänenpbjekte ist nachteilig, da die (austauschbaren) Persistenz Artefakte am besten in DAOs ausgelagert implementiert werden.

Ein weiteres Thema war das Remoting innerhalb der Architektur, hier ging es darum welche ansätze es durch das Spring Framework gibt. Eberhard stellte dabei auch die Vor- und Nachteile dar, falls man seine Domänen Objekte exportiert.

Den Abschluss der Session bildete die Definition von Schichten, dazu stellte Eberhard die Möglichkeit vor über ApsectJ Pointcuts auf verschiedene Layer in der Architektur zu refernezieren.

Dies Jahr hatte ich das Glück bei der Spring One dabei zu sein. Es waren, wie letztes Jahr auch, circa 370 Besucher und eine Menge Speaker anwesend. Ich versuche mal die viele Erlebnisse in komprimierter Form darzustellen.

Die SpringOne wurde mit einer Keynote von Rod Johnson eröffnet. In der Keynote stellte Rod dar, wie Interface21 die kürzlich erhaltene Finanzspritze (10 mio. $) von Benachmark Captial, einem Investor in Open Source Projekte (Red Hat, MySQL, JBoss) einsetzen will. Ich denke ein großer Teil wird mit Sicherheit in die Produktentwicklung gehen. So sollen die Entwicklerkapazitäten in manchen Bereichen verfünffacht werden. Es wird zudem ein dediziertes Enwicklungslabor in Southhampton, UK geben. Ein weitere Entwiclungszentrum wird in Florida, US aufgebaut. Ich denke angesichts dieser Tatsachen kann man zukünftig noch schnellere Release Zyklen erwarten, wobei trotzdem zu sagen bleibt das bereits jetzt die derzeitige Geschwindigkeit und vor allem die Qualität mit Sicherheit als sehr gut zu bezeichnen sind.
Ein weitere Office wird in Sillicon Valley aufgebaut, in diesem wird unter anderem auch Rod Johnson selbst umziehen. Der Umzug von ihm ist Logistisch zu begründen, da die meisten Partner etc. von Interface21 sich dort befinden.
Als weiteres wurden die neuen Mitarbeiter von Interface21 vorgestellt, dies sind zu einem nicht-technische Leute für den Vertrieb und die operative, zum anderen ist dies Mark Pollack welcher in der Spring .NET Entwicklung beteiligt ist.
Mark stellt die (einfache) Entwicklung eines Webservices mit Hilfe von Spring .NET vor. Weitere Vorstellungen waren das Produkt Spring Webflow durch Ben Hale sowie die Spring IDE von Christian Dupuis.
Insgesamt war die Keynote sehr spannend, und konnte auf eine interessante Art den Benutzern einen Blick in die Zukunft von Interface21 und dem Spring Ökosystem geben.

Improving application design with a rich domain model

Im der anschließenden Session von Chris Richardson ging es um das Applikationsdesign mit einem Rich Domain Modell. Dabei zeigt Chris eine typischen Applikation auf welche mit dem Anemic Domain Modell entwickelt wurde. In der Beispiel Applikation ging es um die Durchführung eines Überweisung bei welcher zwei unterschiedliche Konten beteiligt sind. In der Konto Klasse wurd keine fachliche Logik selbst implementiert, diese dienten lediglich als Datencontainer (DTOs). In der Service Klasse waren allein für ein kleines und nicht vollständiges Beispiel bereits über 100 Zeilen Code enthalten, ich denke in der realität können dies durchaus auch tausende sein. Chris erklärte anschließend die Probleme welche mit der Implementierung auftreten (Lesbarkeit, Wartbarkeit, Flexibilität). Den Abschluss der Session stellt das Refactoring des Anemic Domain Modells in ein Rich Domain Modell dar.

Dazu wurden die Methoden zuerst in die Account Klassen selbst verschoben, anschließend wurde eine neue Klasse erstellt welche eine Überweisung selbst darstellt. Durch weitere Refactoring wurden verschiedene IF/ELSE Konstellationen durch Polymorphie ersetzt. Ein weitere Punkt war die Ersetzung von einfach Java Objekten (z.B. Date) durch fachliche Objekte (FachlicherKalender). Dadurch konnte ein erheblicher Teil der Logik welcher sich mit Datumsberechnungen auseinander setzt von den einzelnen Domain Klassen in den Fachlichen Kalender verschoben werden.

Best Practices using Spring Web Flow

In dieser Session stellte Erwin Vervaet, einer der beiden Entwickler neben Keith, verschiedene Themen rund um Spring webflow vor. Ein ganz zentraler Bestandteil ist dabei die Continuation Funktionalität. Da Zeil bei dem Einsatz von Continatuons ist die Ermöglichung eines Back und Refresh Buttons innerhalb von Spring Webflow. Der Benutzer soll dabei in der Anwendung selbst navigieren können.
Spring Webflow stellt dazu bereits eine out-of-the-box Implementierung zur Verfügung. Erwin führte die Vor und Nachteile beim Einsatz der Continations in Spring Webflow vor. Ein Nachteil ist dabei unter anderem der erhöhte Speicherverbrauch auf dem Server, da für jede Seite eine “Snapshot” der Flow Daten im Server gespeichert werden. der Vorteil ist die erhöhte Flexibilität beim Benutzer.
Anschließend stellte Erwin die weitere Repositories von Spring Webflow mit deren Vor und Nachteilen dar. Den Abschluss der Session bildeten die Integrationstest, welche mit Spring Webflow sehr elegantin Junit durchgeführt werden können.

Data Grids: Extreme Transaction Processing Infrastructure for Spring Applications

Brian Oliver stellte in dieser Session die Einsatzmöglichkeiten und Vorteile von Data Grids mit Coherence Data Grid dar. Nach einer kurzen Einführung folgte ein erstes Beispiel in dem mit einem zwei- zeilen Code die Verwendung des Grids vorgestellt wurde. Beindruckend ist hier das mit einer einzigen Zeile Code die Anwendung an einem Grid Teilnehmen kann. Mit einem weiteren call konnte man anschließend Daten in den Grid übergeben oder auch auslesen.
Anschließend wurde die Datenverteilung bei Verwendung von mehreren Memebern dargestellt. Bei einem Datagrid gibt es kein Master/Slave Pattern, das bedeutet das alles Member an einem Datagrid die gleichen Pflichten und Aufgaben wahrnehmen. Innerhalb eines Grids werden dabei die Daten unter allen Membern verteilt, dabei besitzt jeder Memeber einen sogenannten Backup Member.
Den abschluss stellte die weiteren Vorteile einen Data Grids dar. Insgesamt war die Session sehr interessant, man muss dabei auch aber sagen das die Session für dieses Thema schon fast zu kurz war.

Pragmatic SOA - Substance, not hype

In diese Session bin ich mit gemischten Gefühlen reingeganen. In letzter Zeit hatte ich doch einige SOA Vorstellungen von vielen Leuten gesehen, vor allem auch von den Vertrieblern der großen Produkthersteller. Diese konnten mich leider nicht ganz überzeugen. Aber Aufgrund der Tatsache das der Speaker ein gestandener Java Entwickler ist und es sich dabei um Arjen Poutsma handelt, welcher der Vater von Spring Webservices ist, konnte die Session eigentlich nur gut werden. Arjen stellte erstmal Webservices allgemein vor, dabei sprach er auch die derzeit vohandene fehlerhafte Meinung an, das Webservices nur über HTTP realisierbar sind. Webservices lassen sich zum Beispiel auch mit JMS oder per E-Mail übertragen, was in vielen Umständen vorteilhafter ist (asynchrone Übertragung etc.)
Anschließend folgt der Historische Überblick, wie man heute zu einer Server Orientierten Architektur gekommen ist. Dabei ist eine SOA Architektur in dem Sinne nichts neues, da es Services bereits schon immer gab. dies waren zum Beispiel früher die COM Komponenten innerhalb eines Microsoft Betriebssystems. Bei den heutigen Services spricht man häufig von Business Services, welche einen Geschäftsprozess oder zumindest einen Services mit einem Teil eines Geschäftsprozess implementieren. Arjen stellte anschließend mit einem Beispiel (Ausfüllen von Urlaubsformularen) die Implemenentierung eines fachlichen Services dar.
Den Abschluss der Session stellt der Wildwuchs an WS-* Spezifikationen dar. Arjen stellte dabei unterschiedliche Spezifikationen dar. Beindruckend ist hierbei das es die Organisationen geschafft haben z.B. für das WS-Adressing FÜNF! inkompatible Spezifikationen zu schaffen. In allen anderem Bereichen (security, Reliable Messaging) sieht das ganze leider nicht wesentlich besser aus.

Rundum war die Session sehr gelungen, da es Arjen wirklich geschafft hat ohne Technologien in das Thema einzuführen. Somit war die Session eine interessante Einführung in die Webservices und den Technologien mit welcher sich eine SOA aufbauen lässt.