The ServerSide Java Symposium: Language oriented Programming Keynote
Martin Fowler und Neal Ford von Thoughworks sprachen in dieser Keynote über "Language Oriented Programming". Im Wesentlichen ging es um DSLs (Domain Specific Languages). Sie ist auch wichtig für die Kommunikation. Ihrer Meinung nach sollte man eine oder mehrere DSLs mit einer GPL (General Purpose Language) kombinieren, um eine Anwendung zu entwickeln. Language-oriented Programming ist eine Stil, bei der man Software aus einer Reihe von Domain Specific Language implementiert. Eine "Internal DSL" basiert auf der Syntax der Basis-Sprache, sei es Java oder Ruby. Lisp-Programmierer arbeiten zum Beispiel auf diese Weise. Ein Beispiel ist ihrer Meinung nach Ruby on Rails. Es scheint wie eine Erweiterung der Sprache um Features für die Implementierung von Web-Seiten. Ein anderes Beispiel sind Bibliotheken für de Erzeugung von Mock-Objekten wie jMock oder EasyMock. Würde man dort eine "normale" API nutzen, würde die Implementierung deutlich komplizierter werden.
Eine Regel ist "Behandle Code-Zeilen wie Sätze." Ein Satz ist dabei ein vollständig abgeschlossener Gedanke. Das sollte dazu führen, dass man den Code besser und flüssiger lesen kann. Lesbarkeit ist wichtig: Man schreibt Code nur einmal, aber typischerweise wird der Code 2,5 mal gelesen. EIn Beispiel wäre Car,describedAs().insulated().length(50) etc. Wenn man einen Methoden-Aufruf pro Zeile schreibt, wird das übersichtlich. Beispiel eliminiert man dabei die Setter und Getter (was aber zum Beispiel beim IDE-Support meiner Meinung nach zu einem Problem führt). Wenn man hier den Trick nutzt, dass das Objekt verschiedene Interfaces anbietet, so kann man dadurch die Methoden auf bestimmte Stellen einschränken. jMock soll dadurch sehr einfach benutzbar sein, weil man mit der Code Completion durch das Schreiben des Codes gut geleitet wird. Dann gab es ein Beispiel aus Groovy, bei dem man die vorhandenen Java-Klassen wie Date und Calendar eine hübsche API hinzugefügt hat. Ihrer Meinung nach sind XML-Dokumente ein Ergebnis davon, dass die Implementierung einer DSL mit Java nicht so einfach wie mit XML ist. Das ist ihrer Meinung nach eine DSL. Allerdings ist das XML dann nicht sehr lesbar - aber leicht zu parsen. Was bedeutet, dass man sie nicht einem Endanwender zeigen will.
DSLs kann man bauen mit Antlr, Yacc (JFlex/CUP), JavaCC oder SableCC. Interessanterweise fehlen hier die typischen Code-Generatoren wie Open ArchitectureWare, warum auch immer. Vor allem, weil die vorhandenen Werkzeuge laut Martin schwer zu erlernen sind. Seine Empfehlung ist Antlr, weil es dazu ein Buch und auch Tool-Support gibt.
Internal DSLs haben den Vorteil, dass man die volle Mächtigkeit der unterliegenden Sprache hat. Nachteil: Man muss eine Sprache mit Klammern benutzen, was Laien schwer zu vermitteln ist. Und man ist durch die Syntax und Semantik der Sprache eingeschränkt. External DSLs - also DSLs mit Generator - benötigen einen aufwändigen Translator und man hat keine Support für die Basis-Sprache.
Language Workbenches entstehen: Zum Beispiel von Intentional Software von Chares Simnonyi, Ex-Microsoft, Excel und Word-Projektleiter und Weltraum-Tourist. Dann gibt es Software Factories von Microsoft und die JetBrains-Ideen wie MPS von den Machern von intelliJ. Dieses neue Werkzeug macht es möglich, den Abstract Syntax Tree zu editieren. Die editierbare Repräsentation ist eine Projektion der abstrakten Repräsentation.
Aber entstehen dadurch nicht eine Sprache-Kakaphonie? Es ist genauso wie bei Framework und generell: Wenn die Abtraktion in der DSL nicht stimmt, dann wird das kompliziert. Außerdem muss man eh was lernen und es ist nur eine dünne Abstraktion über Frameworks. Meiner Meinung nach ist das nicht vollständig richtig, denn die jeweiligen Frameworks waren ein Problem für die Einarbeitung neuer Mitarbeiter.
Ziel ist es, Code zu schreiben, die ein Analyst lesen kann, aber nicht schreiben können muss. Technologien wie COBOL oder auch SQL; die dazu führen, dass man Code von einem Anwender schreiben lassen kann, haben das jedenfalls nicht geschafft.
Dieser Ansatz sehen sie als ein Wettbewerbsvorteil und möglicherweise als das nächste große DIng nach OOP.
Der Talk war recht interessant und zeigt, dass man sich wieder Gedanken über Sprachen macht. Inhaltlich gab es einige interessante Aspekt, aber DSLs sind ja schon länger ein Thema. Interessant ist eher, dass Martin Fowler und Thoughtworks sich so intensiv um das Thema kümmern. Sie sind auch sonst auf der Konferenz sehr präsent.
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: Der erste Tag
Neben der Keynote habe ich am ersten Tag keine weiteren Vorträge angehört - weil ich die ganze Zeit mit anderen Interface21-Mitarbeitern und Konferenz-Teilnehmern geredet habe. Heute gibt es die Keynot von Adrian Colyer und Eric Evans auf die ich gespannt bin.
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
Retrospektive und Zukunft
Lange Zeit habe ich nichts im Blog veröffentlicht. Kein Wunder, im Moment überschlagen sich die Ereignisse. Interface21 hat 10 Mio. $ Venture Capital von
Benchmark eingesammelt, die z.B. auch RedHat und JBoss finanziert haben. Das ist nicht nur ein Vertrauensbeweis, sondern gibt uns auch die Möglichkeit, größere Beträge in die Produkt-Entwicklung zu investieren. Die mussten wir bisher rein aus den Services finanzieren mussten. Der Erfolg, den wir ohne diese finanzielle Ausstattung bisher hatten, lässt auf viel hoffen, wenn das Venture Capital seine Wirkung entfaltet! Dann war die
JAX-Konferenz mit dem
Spring-Day, dem Spring-Power-Workshop und vielen Vorträgen von Interface21-Mitarbeitern (Rod Johnson, Jürgen Höller, Mike Wiesner und ich) hat in Wiesbaden stattgefunden. Auch außerhalb der Konferenz hatten wir eine Vielzahl von Vorträgen bei vielen Anlässen. Und so geht es weiter: Im Juni spreche ich bei der
JUG Cologne, bei der
Spring / Java User Group Switzerland in Zürich, beim
Server Side Symposium in Barcelona (dort treten auch meine Kollegen Rod Johnson und Adrian Colyer auf) und natürlich ist die
Spring ONE in Antwerpen, bei der wohl fast ganz Interface21 auftreten wird.
Das sind die aktuellen Ereignisse - wenn man den Horizont etwas weiter fasst und schaut, was passiert ist, seit ich vor etwas über einem Jahr zu Interface21 gegangen bin, ist das schon sehr spannend: Spring ist ein Öko-System geworden, das wächst und gedeiht - mit neuen Pflänzchen wie z.B. Spring OSGi oder Spring Web Service und mittlerweile schon etablierten Technologie wie z.B. Spring Web Flow und Spring Security (Acegi). Und das Interesse an diesen Technologien ist auch da. Spring ist also zu weit mehr als ein Framework geworden.
Interface21 ist deutlich gewachsen, sowohl in Deutschland als auch international. Wir passen dazu auch unsere Strukturen an, aber wir bleiben gleichzeitig unseren Werten treu, denn die sind die Basis des Erfolgs von Spring und Interface21. Und wir werden natürlich auch weiter wachsen und neue Leute einstellen - es bleibt also spannend!
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
