Seit Freitag bin ich nun von der JAX zurück. Zusammengefasst war dies eine erfolgreiche Konferenz mit netten und vor allem interessanten Teilnehmern. Nach unseren Spring Power Workshop zusammen mit meinen Kollegen Eberhard Wolff und Mike Wiesner mit über 100 Teilnehmern folgte die Keynote von Rod Johnson mit einer anschließenden Q & A. Innerhalb der Q&A gab es viele interessante Fragen zu der Zukunft von Java allgemein und vor allem von Enterprise Java.
Parallel dazu began der Spring Day mit Interessanten Vorträgen rund um das Spring Framework sowie das Spring Portfolio. Ich hatte meine Session im letzten Slot, der Raum war bis auf sehr wenige Plätze komplett gefüllt. Eine Kopie meiner Folien befindet sich hier.
Am späten Abend hatten wir parallel zum JAX Ballroom eine BOF zu Spring Themen an der auch alle Speaker vom Spring Day anwesend waren.
Den Mittwoch und Donnerstag habe ich nur sehr wenige Vorträge besucht da mit unserem Stand und anderen Kollegen die man sehr selten sieht beschäftigt war.
Nun startet wieder das Frühjar mit etlichen Konferzen, auf den man leider nicht bei allen teilnehmen kann. Morgen gehts es gleich schon mal los mit JAX’08 auf der ich auch einen Vortrag und Workshop über Spring halte. Außerdem hält Rod Johnson eine Keynote über die Zukunft von Enterprise Java am Dienstag auf die ich persönlich sehr gespannt bin.
Nach der JAX geht es auch gleich Anfang Juni weiter mit der SpringONE. Die SpringONE dauert dieses Jahr lediglich 2 Tage was aber dem Inhalt in keiner Weise schadet. Im gegenteil, wir haben so viele Announcements und Neuerungen für die Konferenz so dass man gar nicht weiss an welchen Sessions man teilnehmen soll.
Darunter fallen unter anderem Spring 2.5 mit dem Ausblick auf Spring 3.0 für den Herbst, und natürlich Web Flow 2.0 was bis dahin released sein sollte. Außerdem gibt es komplett neue Projekte wie z.B. Spring Integration und natürlich unseren kommerziellen Offerings welche auch komplett neue Funktionalitäten erschließen. Dazu gibt es bereits die SpringSource Toolsuite als Beta für die Entwicklung von Java (vor allem Spring) Anwendungen sowie die Spring AMS (Application Managment Suite) als Release Candidate. Letzteres ist vor allem immer wieder ein Thema vor allem beim Betrieb, nämlich die Überwachung und Kontrolle einer Spring Anwendung.
Am 03 März 2008 findet in Stuttgart eine Spring Release Party statt. Auf der Party werden spannende Vorträge zu Spring, Spring .NET, Spring Security (ehemals Acegi) sowie Spring Web Flow / Spring Faces gehalten.
Zu den letzten beiden Themen werde ich einen Vortrag von 16.30 - 17.30 halten. Im Anschluss an dem Vortrag findet ein Code Camp statt an dem auch gehackt werden darf.
Weitere Informationen gibt es hier http://www.jugs.org/veranstaltung-03-03-08.html
Rod Johnson hat es bereits seit Anfang der Woche angekündigt . Interface21 firmiert sich zur Firma SpringSource um. Damit dürften die Fragen was Interface21 so macht der Vergangenheit angehören 
Seit dem 01.11 bin ich bei Interface21 - der Firma hinter dem Spring Framework - als Senior Consultant angestellt. Dort beschäftige ich mich mit Trainings und Consultings zum Spring Framework und speziell Spring Webflow. Auf die neuen Aufgaben bei dem sehr interessanten Arbeitgeber freue ich mich bereits jetzt schon.
Auf der W-JAX sind ich und die anderen Kollegen aus Deutschland (samt Jürgen Höller aus AT) anzutreffen.
Seit Spring 2.1, welches sich derzeit im Milestone 3 befindet existiert ein JMS Namespace. Durch den JMS Namespace soll die Konfiguration der einzelnen MessageListenerContainer, welche für das asynchrone Empfangen von JMS Nachrichten eingesetzt werden, vereinfacht werden. Meiner Meinung nach macht sich der Vorteil des Namespaces beim skalieren der Container Konfigurationen richtig bemerkbar.
Hat man zum Beispiel früher den Container durch folgende Bean definition konfiguriert
<bean id="container" class="org.springframework.jms.listener.DefaultMessageListenerContainer"> <property name="connectionFactory" ref="connectionFactory" /> <property name="messageListener" > <bean class="org.springframework.jms.listener.adapter.MessageListenerAdapter"> <property name="delegate" ref="messageBean" /> <property name="defaultListenerMethod" value="doExecuteRequest" /> </bean> </property> <property name="destination" ref="requestQueue" /> </bean>
dann fällt die neue Konfiguration sehr klein aus.
<jms:listener-container connection-factory="connectionFactory" container-type="default" destination-type="queue" acknowledge="auto"> <jms:listener destination="RequestQueue" ref="serviceBean" method="doExecuteRequest" id="echoListener1"/> </jms:listener-container> </code>
Will man auf mehreren Destinationen lauschen, so brauch man lediglich ein neues Listener Element innerhalb des listener-container aufnehmen. Dadurch werden intern zwei XXXXMessageListenerContainer Instanzen mit den jeweiligen MessageListenern erzeugt. Die Konfiguration würde dann wie folgt aussehen
<jms:listener-container connection-factory="connectionFactory" container-type="default" destination-type="queue" acknowledge="auto"> <jms:listener destination="RequestQueue" ref="serviceBean" method="doExecuteRequest" id="echoListener1"/> <jms:listener destination="RequestQueue2" ref="serviceBean" method="doExecuteRequest" id="echoListener2"/> </jms:listener-container>
Ein kleines Beispiel befindet sich im hier.
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.
Mit Spring 1.X war das asynchrone Empfangen von JMS Nachrichten noch nicht möglich. So musste man in diesem Bereich eine Message Driven Bean einsetzen. Der Nachteil der Lösung ist, das diese nur innerhalb eines Application Servers funktioniert. So muss man für eine Anwendung welche im J2SE und JEE Bereich verteilt wird, zwei unterschiedliche Implementierungen vorhalten.
Seit Spring 2.x existiert eine - meiner Meinung - sehr elegante Lösung für das Empfangen von asynchronen Nachrichten mithilfe von Spring Boardmitteln. Diese wird in der Spring Referenzdokumentation ausführlich dokumentiert. (siehe hier )
Der Vorteil der Lösung liegt auf der Hand, eine Anwendung welche mittels Spring MDPs Nachrichten empfängt kann im J2SE sowie JEE Bereich eingesetzt werden. Für die beiden Umgebungen ist lediglich eine Änderung in der Spring Konfiguration notwendig.
In einem Post innerhalb des developerworks unter hier wird vor dem Einsatz eines Spring MDP Listeners unter Websphere gewarnt. Da die Komponente eigene Threads erzeugt, welche nicht durch den Applikationsserver verwaltet werden. Die Aussage ist in der Form richtig, allerdings ignoriert der Beitrag das die Spring MDP Listener Komponente perfekt mit der Websphere CommonJ Abstraktion zusammenarbeitet. Somit erzeugt die Komponente keine “native Threads” im Websphere, da die Threadverwaltung nun in der CommonJ Abstraktion statt findet. Diese wird im Websphere Application Server konfiguriert und angelegt. Entgegen dem Bericht ist die Implementierung der Spring MDP JEE Konform, solange man einen DefaultMessageListenerContainer anstelle eine SimpleMessageListenerContainers einsetzt.
Einrichten des WorkManagers
Damit die Spring MDP Lister Komponente die CommonJ WorkManager Abstraktion einsetzt, muss zuerst der Workmanager in der Spring Konfiguration definiert werden. Dies geschieht über folgende bean Definition
<bean id="taskExecutor" class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor"> <property name="workManagerName" value="wm/WorkManager" /> <property name="resourceRef" value="true" /> </bean>
Durch die oben stehende Bean Definition wird aus dem JNDI Kontext die CommonJ WorkManager Implementierung abgerufen. Unter dem JNDI Namen “wm/WormNagaer” existiert eine default WorkManager Konfiguration innerhalb der ApplicationServers. Es können aber auch Problemlos eigene WorkManagers im Websphere Application Server angelegt werden. Durch die Eigenschaft resourceRef = true, wird der Bean mitgeteilt den Lookup als Resource durchzuführen, generell sollten im JEE Bereich Resource Referenzen verwendet werden, da diese während dem Deplyoment eine höhere Flexibilität bieten.
Konfigurieren des MessageListenerContainer
Die Konfiguration des MessageListenerContainers erfolgt mithilfe folgender Bean Definition
<bean id="container" class="org.springframework.jms.listener.DefaultMessageListenerContainer"> <property name="connectionFactory" ref="queueConnectionFactory" /> <property name="messageListener" ref="messageListener" /> <property name="destination" ref="requestQueue" /> <property name="taskExecutor" ref="taskExecutor" /> <property name="cacheLevel" value="0" /> </bean>
In der obenstehenden Bean Definition findet die Konfiguration des MessageListenerContainers statt. Die definierte Bean verweist über die Eigenschaft taskExecutor auf den zuvor definierten CommonJ WorkManager. Dadurch das der Konfigurierte Container keine Transaktionen verwendet muss die der CacheLevel explizit auf 0 gesetzt werden, andernfalls kommt es zu Fehler beim Verbindungsaufbau zum Queue Manager. Die anderen Eigenschaften des Containers sind in der Spring Dokumentation (siehe oben) beschrieben.