Neues von der SpringOne
Obwohl ich nicht vor Ort bin, hier die Neuigkeiten aus der Keynote im Überblick:
Labels: ROO, SpringOne, SpringSource Tool Suite, tc Server
SpringOne 2008
Die SpringOne 2008 fand wieder in Antwerpen statt. Die größte Neuigkeit aus Sicht von SpringSource war, dass Peter Cooper-Ellis nun für uns arbeitet. Er hat vorher mehr als 10 Jahre zuständig für die WebLogic-Division bei BEA. Ich hatte das Vergnügen, den letzten Abend der Konferenz länger mit ihm zu reden und er macht einen sehr guten Eindruck. Es ist schon spannend, welche Qualität von Leuten wir im Moment anziehen.
Inhaltlich gab es vor allem Updates für die neuen Versionen der verschiedenen Spring-Projekte und Spring-Projekte. Mein Kollege Mike Wiesner (Senior Consultant, SpringSource Deutschland) berichtete über Spring Security 2.0, der einen wesentlichen Schritt zu einer vereinfachten Konfiguration darstellt. Ich selber habe einen eher ungewöhnlichen Vortrag gehalten, weil es um Architekturen ging. Dabei habe ich beleuchtet, wie man mit Spring durch verschiedene Konfigurations-Mechanismen grob-granulare Komponenten definieren kann.
Interessant fand ich vor allem den zweiten Tag, der im wesentlichen im Zeichen der SpringSource Application Platform stand. In der morgendlichen Keynote sprachen Adrian Colyer (unser CTO) und Rob Harrops, der Leiter des Application-Platform-Projekts, darüber, wie die Application Platform Probleme im Bereich Modularisierung, Dynamik usw. lösen kann. Die nächste Session, die ich besuchte, war von Sam Brannen. Er sprach darüber, wie man eine WAR-Web-Anwendung zunächst mit relativ wenig Aufwand so modifizieren kann, dass die Logik in einem anderen OSGi-Bundle liegt. Dadurch ist es möglich, die WARs von den vielen JARs, die sonst im WEB-INF/lib stecken, zu befreien und vor allem können mehreren WARs die Logik-Komponenten verwenden. Dabei muss man lediglich dem WAR ein OSGi-konformes META-INF/MANIFEST.MF geben. Die letzte Variante ist dann, die Web-Komponente als OSGi-Web-Bundle zu deployen - das macht vor allem die Konfiguration von Spring-Web-Anwendungen wesentlich einfacher.
Rob Harrop sprach dann über den internen Aufbau der SpringSource Application Platform. Dabei erwähnte er auch, dass ein wesentlicher Input für die SpringSource Application Platform die typischen Probleme beim Betrieb von Anwendungen ist und gerade hier ist noch deutlich mehr in der Zukunft zu erwarten. Übrigens werden die Erweiterungen, die die SpringSource Application Platform beim OSGi-Programmiermodell macht, intern auf "normale" OSGi-Konfigurationen etc. abgebildet.
Ingesamt gab es auf der SpringOne nicht die großen Überraschungen, sondern eher einen tieferen EInblick in die vielen neuen Technologien, die wir in letzter Zeit rausgebracht haben. Also hat es sich - wie jedes Jahr - auch diesmal gelohnt.
Labels: Peter Cooper-Ellis, SpringOne
Vortrag über Spring-Architekturen
Ein Video von meinem Vortrag über Spring-Architekturen auf der Spring One gibt es
hier. Viel Spaß beim Angucken!
Labels: Spring, SpringOne
Nachlese Spring One: Announcements
Nach den ausführlichen Berichten über einige Session hier nochmal die wichtigsten Neuigkeiten von der Spring One:
- Das Spring Framework ist in enger Kooperation mit IBM auf WebSphere zertifiziert worden
- Interface21 wird Entwicklungszentren in Southampton (UK) für Spring, Vancouver (Kanada) für Tools und Melbourne (FL, USA) für Web-Technlogien aufbauen. Dadurch wird es wesentlich mehr Produkt-Entwickler geben und dadurch auch wesentlich mehr Innocvation in diesen Bereichen.
- Interface21 wird zusammen mit Tasktop Technologies am Eclipse-Projekt Mylyn arbeiten. Ziel ist eine Task-orientierte IDE, die Tasks zum Beispiel aus Bug-Trackern wie Bugzilla, Trac oder JIRA importieren kann und dann die Arbeit in der IDE an diesen Tasks ausrichtet.
- Spring Batch wird das nächste Mitglied in Spring-Produkt-Portfolio. Batch Anwendungen war bisher ein Bereich, in dem zwar Java-Entwicklung stattgefunden hat, aber es gab bisher keine Frameworks in diesem Bereich.
Ich glaube, diese Announcements zeigen deutlich, was wir mit dem 10 Mio $ Investment anfangen werden und welche Innovationen wir in der Pipeline haben.
Labels: Interface21, Spring, SpringOne
Spring One: A Fast Hop into Real Object Oriented Apps
Ben Alex ist auch die Entwickler von Acegi (Spring Security) und sprach in diesem Vortrag über ROO. ROO ist eine Domain Driven Design Implementierung und es steht für Real Object Oriented.
Die Persistenz-Layer nutzt transparente Persistence und der Name des Layers ist Repository. Es gibt eigene Finder. Validierung und Logik ist im Domain Model. Viel von dem Code wird generiert. Generierung hat natürlich einige Probleme wie das erneute Generieren, die Qualität des generierten Codes, Versionskontrolle usw.
ROO kommt aus konkreten Projekt-Szenarien. Es legt die Priorität auf die Implemeniterung des Domänen-Modells. Und das ganze soll möglichst gehen.
Eine ROO-Anwendung ist mit einem Maven Archetype leicht zu erstellen. Danach kann man Properties für die Datenbank editieren. Als nächstes erzeugt man dann die Domänen-Objekte. Diese enthalten zum Beispiel die Logik für gültige Werte in Form von asserts. Daraus wird das Hibernate-Mapping erzeugt. Und auch passende Oberklassen für die Integrations-Tests. Dadurch werden dann auch die Datenbank-Tabellen erzeugt. Der Generator überschreibt die generierten Files nicht.
Die Persistenz verlässt sich auf transparente Persistenz, d.h. man kann es nicht mit JDBC verwenden, was explizite Save-Operationen nutzt. Finder sind in eigenen Klassen, die man dadurch leicht injizieren kann und austauschen kann. Dazu bietet es auch ein eigenes Mocking-Framework an. Und es werden auch Oberklassen für die Integrations-Tests erzeugt.
Es gibt eine Fassade, um die Logik in den Domänen-Objekten auch als Serivces zu exportieren. Ben wies dann darauf hin, dass Domänen-Objekte keine DTOs sind. Für die Konvertierung wird Dozer genutzt. Ein Domänen-Objekt ist nicht unbedingt ein DTO, so dass mehrere Domänen-Objekte in einer Fassade zusammengefasst werden. Dadurch hat man keine Explosion von Typen.
ROO-Anwendungen sind auch automatisch JMX-fähig, so werden die Hibernate-Statistics exportiert und auch eigene Informationen zum Beispiel über die DAOs.
Woolworth in Australien verwendet ROO schon. Dort gab es dann auch die Anforderung, komplexere Datenbank-Schemata zu unterstützen. Außerdem musste Dozer angepasst werden. Ein externes Review der Projekte war positiv und die Projekte war on Time und in Budget. Außerdem sind ROO-Applikationen konsistent.
Ben hat den Vortrag auch schon auf der Spring Experience gegeben,
hier kann man ein Blog-Eintrag darüber lesen.
Labels: Ben Alex, ROO, SpringOne
SpringOne: OSGi, a New Foundation for Enterprise Apps
Adrian Colyer (CTO von Interface21) sprach dann über OSGi. OSGi ist die Open Service Gateway Initiative. Es definiert Bundles mit fest definierten Sichtbarkeiten und sie können Services anbieten. Die Services werden in der Service Registry registriert und man kann sich an sie binden. Services können zur Laufzeit neu hinzukommen und auch wieder verschwinden. OSGi kommt von der OSGi Alliance. Es kommt eigentlich aus dem Embedded Bereich und war daher leichtgewichtig und dynamisch von Anfang an. Open Source Implementierung sind Equinox (als Basis von Eclipse), Felix (Apache) und Knoplerfish. Neben Eclipse benutzt IBM es in WebSphere und Lotus. BEA und Oracle sowie JOnAS sind darauf basiert. BEA und Oracle hat Committer im Spring OSGi Projekt.
Was gibt es uns also? Zum Beispiel Management der Sichtbarkeit von Services: EIn Bundle ist eine Black Box, man kann nicht hineingucken, auch nicht mit Reflection oder Class-Loading-Tricks. Also muss man explizit entscheiden, welche Packages man exportiert, auch optional mit Versionierung. Dadurch kann man Anwendungen grobgranular aufteilen z.B. in MVC-Bundles, Service-Bundles, Repository-Bundles usw. Die kann man dann individuell updaten und neue hinzufügen. Und man kann auch mehrere Versionen gleichzeitig aktiv haben.
Für den Betrieb kann man alle Bundles sehen und über die OSGi-Console adminstrieren. Man kann zur Laufzeit neue Typen haben oder Services.
Ein Bundle ist im wesentlichen ein JAR. Es hat kein komplexes Packaging, die Konfiguration ist einfach in META-INF/MANIFEST.MF . Es gibt Support für das Build und Bundling nutzten in Maven 2. Mit Export-Package kann man besimmte Pakages exportieren. Um welche zu nutzen, muss man Import-Package verwenden. Per Default bekommt man dann die neuste Version dieser Package. Man kann auch Packages als optional markieren.Die Bundles haben einen einfachen Lifecycle. Beim Aktivieren kann man mit einem Bundle-Activator definieren, welcher Code beim Startup ausgeführt wird. Außerdem zeigte Adrian die API der Service Registry.
OSGi ist eine gute Basis für Enterprise-Anwendungen - aber es sollte einfach sein. Innerhalb eines Bundles gibt es feingranulare Komponenten, die zusammengebracht werden müssen und zum Beispiel dekoriert werden müssen. Und auch de Services, die von Bundles angeboten werden, müssen irgendwie zugreifbar sein - und man muss irgendwelche Dinge als Serivces exortieren. Und man muss OSGi-Komponenten in Servern wie Tomcat, WebSphere, WebLogic oder Oracle Application Server.
Dann übernahm Costing Leau, der Spring-OSGi-Chef-Entwickler. Ziel ist es, die Vorteile von OSGi einfach für Enterprise-Anwendungen zur Verfügung zu stellen. Mit Spring sollen die Bundles konfiguriert werden, d.h. die Aufteilung in Bundles sollte änderbar sein. Es soll außerdem helfen, Services anzubieten oder zu verwenden. Spring-OSGI soll daher ein POJO-Programmiermodell auf Basis von OSGi bieten. Neben Interface21 sind auch BEA und Oracle Committer. Es gibt außerdem Input von der OSGi-Alliance, von BEA, Oracle und IBM sowie Eclipse Equinox oder Felix.
Die Module des Spring-Frameworks werden als OSGi-Bundles installierbar sein. Mit dem OsgiApplicationContext gibt es einen speziellen ApplicationContext für OSGi. Dieser bietet zum Beispiel die Möglichkeit, Ressourcen mit den richtigen Techniken einzulesen. Außerdem gibt es passende Aware-Interface zum Beispiel für den Bundle Context. Der ApplicationContext kann deklarativ erzeugt werden, d.h. man muss ihn nicht explizit erzeugen.
Bundles können in einer beliebigen Reihenfolge installiert werden. Dabei kann es passieren, dass ein Bundle erstmal warten muss, bis ein anderes Bundles zur Verfügung steht. Erst wenn die Abhängigkeiten zur Verfügung stehen, wird die Anwendung starten. In diesem Prozess werden keine Threads blockiert.
Es ging dann um Service Dynamics. Services können aktiviert werden und verschwinden - was tut man dann? Wie sieht der Code dafür aus? Zunächst kann man Services einfach durch eine Deklaration exportieren. Analog kann man auch Services als POJOs importieren. Das ist im Prinzip dasselbe wie ein Exporter und eine ProxyFactoryBean für eine Technologie wie Hessian. An den References zu den Services kann man auch definieren, an wieviele Instanzen man sich binden will. Wenn man mehrere Instanzen eines Service hat, findet automatisches Rebindung statt, d.h. wenn eine Instanz ausfällt, wird automatisch eine andere genutzt. Hier gibt es auch noch spannende Probleme: Wenn man mehrere Service-Instanzen hat, muss man eine Collection verwenden, der dynamisch Elemente hinzugefügt oder entfernt werden können - weil sich eben die Mege der Services ändert. Sowas gibt es im JDK nicht, was ein Problem ist. Außerdem gibt es ja zustandsbehaftete Services - wie geht man damit um? Wenn die Instanz ausfällt, muss man dann etwas tun. Dazu kann man einen Listener definieren, der aufgerufen wird, wenn ein Service auftaucht oder entfernt wird. Dieser Listener kann auch ein POJO sein, es muss nur Methoden haben, die passende Parameter übernehmen.
OSGi hat einige definierte Services wie Logging zum Beispiel. Aus der Administrations-Konsole kann man zum Beispiel auch Konfiguration dynamisch ändern, was dann in die Spring-Konfiguration eingeführt werden können.
Im Bereich des Testing gibt es das Problem, dass die Bundles und der OSGi-Container gestartet werden muss, was dauern kann. Es gibt daher den ConfigurableBundleCreatorTests, der den OSGi-Container startet usw. Innerhalb des Tests kann man zum Beispiel Maven-Dependencies in dem OSGi-Container installieren lassen.
Wie geht es weiter? Erstmal wird 1.0 releast. Dann gibt es Web-Support mit Spring MVC und Spring Web Flow Support, also erst nach 1.0. Ein weiteres Thema ist die Integration von Repositories wie zum Beispiel mit Maven oder Ivy. Natürlich soll es dann noch enge JMX-Integration geben, um zum Beispiel Komponenten dynamisch hinzuzufügen oder zu entfernen.
In der Zusammenfassung sprach Adrian noch über Class-Loading-Probleme zum Beispiel mit Hibernate und es gibt eine OSGi-Enterprise-Expert-Group, die OSGi für typische Enterprise-Szenarien und damit Spring-Szenarien optimieren soll.
Labels: Adrian Colyer, Costin Leau, Spring, Spring-OSGi, SpringOne
Spring One: Keynote Eric Evans
Eric Evans sprach dann über Making Models Matter. Eric hat den modernen Klassiker "Domain Driven Design" geschrieben.
Ein Modell ist nicht ein UML-Diagramme oder Teile des Codes. Es ist abstrakter. So kann man zum Beisplel eine alte Karte als ein geographisches Modell sehen - die alte chinesische Karte zeigt China in der Mitte und andere Plätze sind nur wenig detailiert und kleiner dargestellt. Auf einer modernen Karte sind dide Größen richtig, aber eine amerikanische Karte hat trotzdem die USA in der Mitte. Aber auch die Karte ist verzerrt: Grönland ist zum Beispiel zu groß (Mercator-Projektion), aber eine gerade Linie ist auch in der Realität eine gerade Linie, so dass es für Schiffs-Navigation günstig ist.
Ein Modell ist also ein System von Abstraktionen, die ausgewählte Aspekte einer Domain beschreiben und benutzt werden kann, um Probleme in dieser Domäne zu lösen. Darauf basierte eine ubiquitäre Sprache: Eine Sprache, die sich am Domänen-Modell orientiert und von allen Team-Mitgliedern benutzt wird, um die Aktivitäten der Mitarbeiter mit der Software zu verbinden.
Eric plädiert dafür, sich auf die Kern-Domäne zu fokussieren. Sie ist der Teil, der überhaupt dazu führt, dass man das System schreiben will. Die Kern-Domäne ist dann auch meistens der Grund, warum man die Anwendung nicht einfach kauft oder outsourct. Es ist eine Anwendung der 80-20-Regel: 80% des Werts kommen von 20% des Systems (oder sogar weniger).
Er berichtete dann aus einem Projekt: Zwei Systeme erbrachten die Supply Chain und die Anwwendungen wurden immer mehr miteinanderer verwoben. Neue Features sind schwierig. Ein Plan des Kunden war es, das System durch ein sauber System zu implementieren. Dazu solle in 3 Jahren abgelöst werden. Im ersten Jahr sollen die generischen Funktionen gebaut weden, dann die Legacy abgelöst werden und dann im dritten Jahr sollte es neue Feature geben. Erics Vorhersage war, dass im zweiten Jahr Dinge problematisch werden, weil das neue System schwierig abzulösen sein wird, weil es eben gewachsene Lösungen enthält. Außerdem wird es während der Ablösung weiterentwickelt, wodurch die Komplexität noch schwieriger wird. Dadurch wird die Anwendung nur eine Portierung der alten Anwendung, weil der Stress zunimmt und man die alte Funktionalitäten nicht sauber implementierne kann. Zudem wird das System sehr teuer sein und keine neuen Funktionalitäten haben - was politisch schwer zu verkaufen ist.
Die Firma will eigentlich die neuen tollen Features aus Jahr 3, was als letztes implementiert wird. Also: Man baut diese Sachen direkt in das alte System ein. Dadurch kann man die neuen Features während der Projektlaufzeit in das System einbauen und die Features aus Jahr 3 direkt umsetzten. Man muss dabei Teile der alten Anwendung refactoren, um das System passend erweitern zu können. Das kann dann aber auch in einen Hack ausarten, in dem man dann einfach nur die neuen Funktionalitäten "irgendwo" implementiert. Und das ist, was dann häufig einfach gemacht wird. Das geht aber nur bis zu einem gewissen Maße, bis man die Software nicht mehr wirklch ändern kann. Das Problem ist, dass viele Entwickler Dinge aufräumen wollen. Dadurch werden die Hacker, die sich auf die Kern-Domäne fokussieren, belohnt, weil sie mit der sauberen Infrasttuktur produktiver werden und gleichzeitig auf dieser Infrastruktur nicht besonders saubere Anwendungen bauen, dadurch die Infrastruktur "verschmutzen" und gleichzeitig den meisten Geschäftsnutzen erzeugen.
Also: Nicht alle große Systeme werden sauber designt sein. Das ist eine schlichte Realität - man muss lernen, sie zu akzeptieren. Also: Was soll man sauber designen? Natürlich die Kern-Domäne.
Und: Es gibt immer mehrere Modelle. Er führte dann den Begriff des Kontext ein: Das ist die Umgebung, in der ein Wort oder eine Aussage eine Bedeutung bekommt. Also macht ein Modell nur in seinem Kontext Sinn und man kann Dinge von einem Kontext in einen anderen übersetzen. (Context Map) Man kann eine Darstellung des Models von einer anderen Darstellung des Models entkoppeln, indem man einen Anti-Corruption-Layer einzieht, der das eigene System von der Darstellung in den anderen Systemen entkoppelt.
Zurück zu dem 3-Jahre-Projekt: Man baut also primär die neuen Features und baut eine kleine Infrastruktur, um das zu unerstützen und löst das Legacy-System nicht ab. Das Legacy-System wird durch einen Anti-Corruption-Layer abgekoppelt, das übrigens aufwändiger zu implementieren sein kann, als die eigentlichen Features. Der Aufwand ist dann aber immer noch geringer als bei den anderen Lösungen. Und man bekommt dadurch auch eine Antwort auf das Problem, dass Präzisions-Designs zerbrechlich sind - man muss sie durch die Anti-Corruption-Layer "sauber" halten.
Labels: Domain Driven Design, Eric Evans, SpringOne
Spring One: Keynote von Adrian Colyer (CTO Interface21)
Die Keynote von Adrian Colyer heißt "Talking Technology". Die machte er interessanterweise ohne Folien - bei 2000 Folien auf der Konferenz kein Wunder.
Er fing damit an, dass durch die abnehmende Bedeutung von Standards jetzt wieder eine offener Wettbewerb standard. Dadurch wird Innovation gestärkt. Und es gibt neue Herausforderungen wie Multi Core und Parallelität. Oder die Eleganz von Programmierung, was auch ein Thema des Domain Driven Designs von Eric Evans ist. Und neue Sprachen wie Ruby und alte wie Erlang oder Scala (das auf der JVM lauft). OSGi als neues Modell für das Deployment von Anwendungen. Also ist es eine gute Zeit, um ein Techniker zu sein.
Ziel von Spring ist: Simple and Powerful. Durch JRuby und dynamische Typisierung gibt es einige neue Möglichkeiten - Duck Typing ist eine weitere Möglichkeit. Man kann darunter die entsprechende Typisierung verstehen - oder eine tippende Ente. Letzteres führte er detailierter aus - mit eine Enten-Handpuppe.
Es gibt eine dunkle Mateie der Java-Anwendungen: Wenn man alle Web-Anwendungen anschaut und die Anzahl der Java-Entwickler, dann stellt man fest, dass es mehr Entwickler gibt als für die Anwendungen notwendig. Die restlichen Anwendungen sind Batch-Anwendungen, die durch Spring Batch zum ersten Mal wirklich unterstützt werden.
EIn weiteres Thema war der AspectJ-Unterstützung in IntelliJ. Und das Eclipse-Mylar-Projekt (es heißt jetzt Mylyn, anegelehnt an einen Begriff auf der Biologie). In diesem Kontext ging er auch noch einmal auf die Bedeutung von Spring IDE ein. Mylar ist eine Task-orientierte IDE. Man bekommt die Tasks aus JIRA, Bugzilla oder aus einem lokalen Repository. Dann sagt man der IDE, an welchem Task man gerade arbeitet. Es merkt sich dann, wodran man arbeitet und blendet andere Sachen aus. Wenn man nun eine andere Task bearbeitet, bekommt man entsprechend eine andere Ansicht. Der Entwickler von Mylyn ist Mik Kersten und Interface21 wird mit ihm in Bezug auf dieses Thema koopierieren. In Vancouver wird es daher einen weiteres Entwicklungs-Zentrum geben.
Das Ziel der Interface21-Produktions-Entwicklung ist es, permanentes Lernen zu ermöglichen. Es gibt konkrete Herausforderungen - die Räume sind da, aber man muss sie mit Leuten bestzen und eine Arbeits-Umgebung schaffen.
Technisch ging er auf Sprng Web Services, den Object XML Mapper (OXM) und WS-Security mit Acegi (Spring Security). Spring Security war sein nächstes Thema mit der exporbitanten Flexibilität und dem Umfangreichen Support für verschiedene Security-Technologien.In Spring Security (Acegi wird umbenannt) wird es auch bald eine Unterstützung für XML-Namespaces geben, was gerade bei Spring Security einen wesentlichen Vorteil hat. Spring OSGi ist ebenfalls ein wichtiges Thema - im Moment aber deutlich cutting Edge. Durch OSGi gibt es eine Strukturierungs-Möglichkeit mit grobgranularere Elementen als bei Spring. Man kann dann auch OSGi-Module in Zukunft in verschiedene Sprachen implementieren. Oder auch Spring Modules - ein weitere wichtiges Projekt. Natürlich benötigen wir dafür mehr Mitarbeiter - was bedeutet, dass wir natürlcih im Moment einstellen.
Die Projekte werden analog zu Eclipse in einem Release-Train organisiert, werden also zeitgleich herauskommen. Dann übergab Adrian an Eric Evans.
Labels: Adrian Colyer, Interface21, Spring, SpringOne
SpringOne: Keynote Rod Johnson
Rod beginnt mit der Keynote. Als erstes führt er Mark Pollack ein, ein Core Spring Developer. Interessanterweise ist die Demo auf Spring.NET. Inhaltlich ist es eine typische Spring-Anwendung mit DAOs, die als Web Services angeboten werden. Auch XML-Schema (bekannt aus Spring 2.0) sind verfügbar und natürlich auch Transaktionen und Performance-Monitoring mit AOP. Spring.NET bietet außerdem das AdoTemplate (analog zum JdbcTemplate) und ein NHibernateTemplate. Auch Remoting ist vorhanden.
Rod ging dann auf das Venture Capital ein. Die Analogie für ihn ist ein doppelter Espresso. Mit den 10 Mio $ Venture Capital kann man einiges anfangen: Raketenabwehr bauen, Tuberkulose auf den Philipinen bekämpfen usw. Aber was macht Interface21 mit den 10 Mio $? In Spring investieren natürlich. Spring ist das de Facto Programmier-Modell im Enterprise-Java-Bereich. Die Idee ist nun, die Werte von EInfachheit und Mächtigkeit in andere unnötig komplexe Bereiche zu bringen - es wird nicht einfach in jedem Bereich eine eigene Spring-Technologie geben, nur um eine Spring-Technologie zu haben. Außerdem muss man die Qualität von Spring als wesentlichen Faktor weiterhin erhalten.
springframework.org war im Februar die 4. wichtigste Java-Seite laut Alex, mittlerweile ist es die 3. wichtigste. Spring ist außerdem ein wichtiger Punkt bei Job-Anzeigen. Die Qualität ist ebenfalls belegbar: Forrester hat uns das bestätigt und auch Firmen wie Headaway Software, die sich auf Software-Metriken spezialisiert haben, unterfüttern das. Das meiste Geld wird daher in Produkt-Entwicklung gehen. Das bedeutet Spring Web (Web Flow + MVC) und Spring Core werden statt jeweils einem Entwickler dann von drei Entwicklern (Spring Core) und fünf Entwickler (Spring Web) weiter entwickelt. Das ist natürlich eine deutliche Vergrößerung.
Spring wird ein Ökosystem, d.h. es gibt eine Menge Firmen, die ishc mit Spirng beschäftigen. Er stellt eine Analogie zu Eclipse dar: Durch einen zentralen Marktplatz gibt es eine Möglichkeit, sich zu standardisieren und auf dieser Basis zu verbessern. Spring hat genauso wie Eclipse viele Extension Points, mit denen die Basis mit eigenen Dingen erweitert werden kann. BEA beispielsweise verwendet Spring als zentrale Technologie. In WebLogic 10 ist jede EJB und jede Java EE Komponente auch eine Spring Bean. Hauptgrund war, dass WebLogic so schneller zur Marktreife gebracht werden konnte. Und natürlich bietet BEA dadurch ein einfaches Programmier-Modell für die Entwickler an. Ein anderes Produkt ist der WebLogic Event Server. Es fokussiert auf Systeme mit vielen Events aus verschiedenen Streams - Anwendungen, die sonst mit C++ entwickelt werden. Spring und Spring OSGi sind die bevorzugten Programmier-Modell in diesem Bereich. Auch Oracle Fusion basiert auf Spring, wie Thomas Kurian (SVP bei Oracle) in seiner JavaOne-Keynote dargestellt hat. Das Oracle Developer Depot, eine Anwendung für das Herunterladen von Samples, basiert ebenfalls auf Spring. Die JavaSpaces-Implementierung Gigaspaces hat ebenfalls nativen Support für Spring. Vorteil ist dabei, dass der Entwickler POJOs schreiben kann, die dann per JavaSpaces verteilt werden. Dabei kann man das bekannte Spring-Remoting-System verwenden. Mit IBM haben wir im letzten Jahr zusammen gearbeitet, um Spring auf WebSphere zu zertifizieren - was für viele große Kunden sehr wichtig ist. Dahinter steckt eine Menge Arbeit mit Tests auf den verschiedenen Plattformen, die es so gibt. Fokus war dabei die Transaktions-Verarbeitung.
Das sollte die 10 Mio $ rechtfertigen - außerdem haben wir einige nicht-technische Leute eingestellt. Dazu zählen Richard McKern (Sales Director, Americas), Amyli McDaniel (Juristin), Greg Southey (Manager in UK), Sigrid Haberkorn (Vertrieb in Deutschland), Missy Warnkin (Asisstenz) und Neelan Choksi (COO). Das bedeute, dass wir die Anzahl technischer Leute mehr als verdoppelt haben. Das Venture Capital kommt von Benchmark, eine Firma die schon in Red Hat, JBoss und MySQL sowie eBay und Second Life investiert haben. Betreut wird es von Peter Fenton, der auch der Meinung ist, dass man eine Open Source Community nicht kaufen kann - was bedeutet, dass Interface21 auch in Zukunft die Community pflegen wird. Ingesamt ist dadurch die Basis gelegt, um die Technologie durch eine entsprechende Business-Seite zu ergänzen.
Interface21 wird eine neue Zentrale in den USA haben. Dort ist Interface21 näher an den Partnern und den Investoren. Das neue Zentrum für Entwicklung ist Southampton in UK. Dabei wird die Entwicklung zentralisiert, um dort gemeinsam zu arbeiten, was der Kommunikation zugute kommt.
Neben Training und Consulting wird in Zukunft Support wichtig werden. Dies wird sowohl die Entwickler als auch den Betrieb und das Management zugute kommen.
Seit der letzten SpringOne haben wir auch unser Portfolio erweitert: Spring OSGi, Spring Batch, Spring Java Config und ROO sind hinzugekommen.
Rod sprach dann noch über einige Projekte, so zum Beispiel Spring Batch. Es gibt immer noch eine Menge Mainframes und es gibt Milliarden Dollar, die in diese Bereich investiert werden. Interessanterweise gibt es in Java EE einfach keine Lösung für Batches - und auch im Open-Source-Bereich gibt es nichts. Die Entwicklung findet zusammen mit Accenture statt.
Spring Web Flow kann benutzt werden für komplexe Abläufe in Web-Anwendung, ist aber nicht abhängig von einer bestimmten View-Technologie, Web-Framework oder gar der Servlet-Umgebung. Seit 1.0.3 wurde Spring Web Flow vor allem im Bereich JSF erweitert. Ben Hale zeigte dann eine Demo zu Spring Web Flow und JSF mit grafischer Darstellung in Spring IDE.
Spring IDE war dann auch das nächste Thema. Die Demonstration von Christian Dupuis zeigte den neuen Beans Explorer und die Integration in den Project Explorer. Spring IDE 2.0 wird möglicherweise schon Montag rauskommen. Spring IDE wird dabei auch Springs neue XML-Namespace unterstützen und dort auch die Möglichkeit zum Beispiel für Classname-Completition geben. Cool ist vor allem auch die Möglichkeit, Spring AOP Pointcuts zu visualisieren. Das geht sowohl mit Pointcuts in der XML-Konfiguration wie auch mit der @Aspect-Notation. Sogar die neuen Konfigurations-Möglichkeiten aus Spring 2.1 und Spring JavaConfig werden unterstützt.
Genau dort setzte Rod dann an: Einige User wollen halt Annotations-basierte Konfiguration - also bauen wir das ein. Die Idee ist, dass die Klassen nach solchen Annotationen durchsucht werden und dann die Bean entsprechend konfiguriert werden. Neben @Component werden auch @Aspect und @Repository entsprechend ausgewertet. In der Spring-Konfiguration gibt es dann nur noch eine EInstellung, welche Klassen gescannt werden sollen. Spring kann Annotationen und XML-Konfiguration mischen - es muss kein Widerspruch sein.
Labels: Interface21, Rod Johnson, Spring, SpringOne
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
