Rod Johnson: Spring 2.0 and Beyond
In diesem Talk gab Rod einen Überblick über Spring 2.0 und die zukünftige Weiterentwicklung von Spring.
Eine interessante Neuigkeit: Es wird ein Spring-Batch-Framework geben. Batch-Verarbeitung ist ein sehr wichtiges Gebiet für Enterprise-Anwendungen und ist bisher im Java-Sektor eher ignoriert worden. Daher ist das eine sehr interessante Neuigkeit, mit der Spring seine Anwendbarkeit im Enterprise-Sektor unterstreicht. Mir ist an dieser Stelle kein anderes Produkt bekannt, dass sich diesem Bereich widmet.
Ein weiteres interessantes Gebiet sind Grid-Anwendungen. Dazu zählen Infrastrukturen wie GigaSpaces, Terracotta oder Coherence. Letzteres wurde vor kurzem von Oracle gekauft, was die Wichtigkeit dieser Technologie unterstreicht. Spring ist hier ein Enabler: Durch die Technologie-Unabhängigkeit von Spring wird es möglich, andere Technologien zu nutzen und nicht mehr einen monolithischen Server. Alle Grid-Lösungen verwenden aus diesem Grunde Spring als Programmier-Modell. Das zeigte Rod mit einigen Folien, die direkt von GigaSpaces kamen, und auch Folien von BEA, die ähnliche Aussagen für das Upscaling von Anwendung von Tomcat auf WebLogic enthalten. Spring kann zum Beispiel auch eigene Scopes für Spaces verwenden.
Eine weitere Umgebung, die für Spring interessant wird, ist Java ME. Dazu muss man Spring noch ein optimieren, um den Speicher-Verbrauch zu reduzieren. Interface21 ist auch an Java EE 6 beteiligt. Die neue Version wird Profiles definieren, die unterschiedliche Anwendungsbereiche von Java EE abdecken sollen. Und dynamische Sprachen: So kann man zum Beispiel das Spring-AOP-Modell zusammen mit dynamischen Sprachen verwenden.
Dann ließ er 2006 Revue passieren: Acegi, Spring 2.0 und Spring Web Flow haben finale Versionen geliefert und es gibt die erste Version von Spring Web Services. Forrester findet heraus, dass eine Mehrheit der Enterprise-Java-Nutzer Spring verwneden. Und natürlich das Pitchfork-Projekt als EJb-3-API-Implementierung: Es wird in WebLogic genutzt, dem einzigen großen Java-EE-5-zertifizierten Server.
Voca und das Europäische Patentamt sind life gegangen: Voca ist eine Firma, die praktisch den gesammten Zahlungsverkehr zwischen Banken in UK abwickelt - noch mehr mission critical wird es nicht. Und beim europäischen Patentamt ist es die Anwendung zum Dursuchen der Patente.
Spring OSGi ist das nächste große Thema: BEA und Oracle hat Committer und es gibt daher deutliches Interesse. Application Server nutzen sowieso verstärkt Open Source, das ist ein weiterer Hinweis in diese Richtung. Spring OSGi findet sich auch schon in
diesem Posting.
Außerdem wird Spring zu einem Portfolio: Da es immer mehr Projekte gibt, ist das ein logischer Schritt. Es bedeutet auch, dass die Projekte zusammen releast werden in Rahmen des "Release Trains".
Man sieht: Spring hat noch sehr viele interessante Bereiche, die es unterstützen kann. Es bleibt also spannend!
Neue Auflage meines Spring-Buchs
Mein Spring-Buch gibt es jetzt in der zweiten Auflage. Mehr Informationen finden sich beim
Verlag. Ich habe das Buch sehr umfassend überarbeitet, so zum Beispiel die neuen AOP-Features, die JPA-Unterstützung, EJB 3, Spring Web Services und Spring OSGi. Die Beispiele und weitere Informationen finden sich in Kürze unter
http://www.spring-buch.de/.
Fazit des Spring Days
Montag ist der Spring-Day gewesen, der mittlerweile ein fester Bestandteil der JAX-Konferenz ist. Ziel war es, den Besuchern sowohl etwas über die neuen Technologien wie Spring-OSGi, Acegi und Spring 2.1 mitzuteilen, wie auch über die Architekturen, die man mit Spring typischerweise implementiert. Das Interesse des Publikums war gewohnt groß und es gab einige interessante Vorträge. Auch in der Hauptkonferenz waren noch einige Spring-Vorträge - unter anderem auch von mir - doch dazu später mehr.
Labels: JAX, Spring, Spring Day
JAX Spring Day - Die Spring Value Proposition im Kontext der Java EE 5 - Christian Dupuis
Über diesen Vortrag hatte ich schonmal
hier gebloggt.
JAX Spring Day - Spring und MDA - Gegensatz oder Ergänzung? - Peter Friese, Jürgen Höller
Diese Session ist ein Art Show-Down: Welcher Ansatz ist besser? Zunächst gab es ein Problem-Statement. Es gibt komplexe Systeme, komplexe Technologien, komplexe Anforderungen und den bekannten hohen Zeit- und Kostendruck. Also ist das Problem vor allem die Komplexität.
Zur Lösung kann man die Technologie vereinfachen. Dadurch soll wieder die Konzentration auf die Fachlichkeit möglich sein. Beispiele dafür sind Vereinfachungen wie Hibernate vs. EJB 2.x CMP / BMP. Andere Möglichkeiten sind Ruby on Rails oder Grails. Oder eben harmonisierende (Meta-)Frameworks wie Spring oder Keel. Die andere Möglichkeit ist die Anhebung des Abstraktionsgrads durch Model Driven Software Development.
Jürgen übernahm dann die Darstellung der Spring-Position. Es soll höhere Produktivität durch die Konzentration auf das Wesentliche ermöglichen und klare Strukturen des Anwendungscodes durch Separation of Concerns ermöglichen. Dadurch ist der Anwendungscode "natürlich" testbar und man kann den Anwendungscode von der konkreten Laufzeitplattform entkoppeln. Zu den Lösungsansätzen von Spring gehört Dependency Injection und AOP. Dadurch kann man Separation of Concerns sowohl in Architektur als auch im Code erreichen. Spring abstrahiert von dnr konkreten Runtime-Services zum Beispiel beim Transaktions-Handling und Drittprojekte wie Hibernate sind konsistent integriert. Der manuell zu erstellende Code wird minimalisiert - durch unchecked Exceptions oder Templates.
An der Stelle habe ich dann den Stand von Interface21 aufgebaut und ich kam zurück, als Peter Friese zeigte, wie man modellgetrieben eine Anwendung bauen kann. So kann man in UML Abhängigkeiten zwischen Services modellieren, die dann durch Springs Dependency Injection miteinander verdrahtet werden.
Abschließend die Bewertung: Bei MDSD gibt es eine homogene, vorgegebene Architektur. Die Entwickler müssen nicht alle Aspekte von Spring in- und auswendig kennen. Dadurch entsteht höhere Produktivität.
Bei "Spring Pur" steht der Code im Mittelpunkt. Der Java-Source-Code ist das zentrale Artefakt. Eingehende Kenntnisse sind notwendig. Auf der anderen Seite ist man agiler: Man kann leichter refactoren.
Letztendlich ist es auch ein Kultur. Die Entwickler kommen mit den Modellen zurecht - oder eben nicht. Und Jürgen entwickelt Code-zentriert - was für einen Framework-Entwickler wohl eher typisch ist. Und mit Spring ist es möglich, sehr leicht auch code-zentiert Anwendungen zu entwickeln. Aber auf der anderen Seite ist Konsistenz auf diese Weise schwer zu erreichen. Durch ein MDSD-Vorgehen ist das leichter erreichbar.
Labels: JAX, mdsd, Spring, Spring Day
JAX Spring Day - Sicherheitsarchitekturen mit Spring: Das Acegi-Framework - Mike Wiesner
Mein Kollege Mike Wiesner sprach dann über Acegi, die Spring Security Lösung. Zunächst sammelte er Anforderungen an ein Security-Framework, also zum Beispiel, dass man Authentifizierungen aus verschiedenen Quellen benötigt und Web Request absichern muss. Außerdem sollte es instanzbasierte Sicherheit geben, also besimmte Benutzer dürfen nur bestimmte Objekte sehen oder ändern.
Mike zeigte dann, wie JAAS mit LoginModules und CallbackHandlern Authentifizierung unterstützten. Die CallbackHandler gibt man dem LoginModul mit, damit dads LoginModul die Daten von Benutzer erheben kann. Sehr schön das Code-Beispiel, bei dem der CallbackHandler natürlich ein instanceOf hat. Acegi hat AuthenticationProvider für verschiedenen Technologien. Dabei übergibt man dem AuthenticationProvider die Authentifizierungs-Informationen. Das ist wesentlich einfacher und auch natürlicher: Man übergibt einfach Namen und Passwort an Acegi.
Der nächste Vergleich war bei der Absicherung von Web-Requests. Bei der Servlet-Spezifikation ist die konkrete Ausgestaltung container-abhängig und die URI-Filter sind begrenzt. Bei Acegi ist es container-unabhängig. Es gibt mächtige URI-Filter und verschiedenen Authentifizierung (z.B. HTTP-Basic).
Beim Service-Layer bietet JAAS nur die programmatische Überprüfung der Constraints oder aber man nutzt die EJB Security Constraints, was einen dann aber an EJB bindet. Acegi macht es so, wie es eigentlich sinnvollerweise sein sollte: Security ist ein Aspekt und wird mit AspectJ oder Spring AOP eingewebt.
Die Sicherheit bei einzelnen Objekt-Instanzen kann man bei JAAS nur programmieren. Das ist nicht nur aufwändig, sondern man kann es auch vergessen, was dann Sicherheitslücken hinterlässt. Und testen kann man es auch nur schwerlich. Bei Acegi kann man Access Control Lists mit AOP integrieren - und auch eigene Advices hinzufügen.
Dann gab es eine Beispiel für eine Web-Anwendung, die mit Acegi abgesichert wird. Die Anwendung ist eher einfach und soll nur zeigen, wie man sie absichert. Bei der Authentifizierung ist schon erkennbar, dass man durch die feingranularen Objekte innerhalb der Anwendung sehr flexibel ist. Man kann an jeder Stelle eine andere Option wählen oder gar eine eigene Klasse implementieren. Also kann man zum Beispiel wählen, ob man sich mit Benutzername und Passwort authentifizieren will oder mit einer anderen Option oder ob man gar eine ganz andere Möglichkeit nutzen will.
Bei der Autorisierung gibt es den AccessDecisionManager, der verschiedene Voter koordinieren. Die Voter entscheiden anhand einer bestimmten Eigenschaft (zum Beispiel die Rolle des Benutzers), ob der Zugriff OK ist oder nicht. Durch den AccessDecisionManager kann man dann mehrere Voter koordinieren, so dass dadurch mehrere Autorisierungs-Technologien koordinierbar sind.
Die Integration in die Web-Anwendung geht über Servlet-Filter. Dabei wird nur ein Servlet-Filter in der web.xml konfiguriert und der delegiert dann an verschiedene Filter, die in Spring konfiguriert werden.
Die Filter haben unterschiedliche Funktionen. So zeigen sie bei einer Exception die Authentifizierungs-Seite an oder sie verbieten den Zugriff auf die Seiten.
Für die Autorisierung kann man auf den JSP-Seiten bestimmte Dinge ausblenden. Acegi kann außerdem auch Code zu friedenstellen, der die Security-API der Servlets verwendet: Es stetll dann eine passende Authentifizierung zur Verfügung stellt.
Sicherheit ist ein Aspekt. Das bedeutet, dass der Sicherheits-Code von dem eigentlich Code getrennt sein sollte. Dadurch wird die Geschäftslogik unabhängig von Acegi, man kann Security für Test leicht abschalten usw. Acegi bietet die Wahl zwischen Spring AOP und AspectJ. Spring AOP ist einfach zu konfigurieren, geht aber nur für Spring-Beans und man kann es leicht umgehen, indem man die Objekte statt mit Spring mit new erzeugt. AspectJ hat eine umfangreichere Konfiguration, eine feinere Granularität und es ist auch ohne Spring nutzbar. Es kann nicht umgangen werden, weil die Aspekte in den Code eincompiliert werden.
Bei Instanz-basierter Security kann mit Acegi definieren, dass bestimmte Benutzer nur bestimmte Operationen dürfen. Dabei kommen Access Control Lists zum Einsatz, die für jedes Objekt, jede Operation und jeden Nutzer definieren, ob der Zugriff erlaubt ist. Sie können aus der Datenbank ausgelesen werden und können auch anhand von Regel "berechnet" werden.
Testen und Security ist auch ein interessantes Thema: Wenn ein Nutzer zu viele Rechte hat, wird er sich nicht melden, damit man das fixen kann. Acegi bietet einem an, die Business-Logik ohne Sicherheit zu testen. Umgekehrt kann man die Security testen, ohne die Business-Logik zu testen. Dadurch kann man getrenntes Testen durch Code-Trennung vornehmen.
Am Ende kam dann noch der Ausblick: Spring Security 1.1 kommt sehr bald, RC1 im Mai 2007. Es wird einen eigenen Acegi-XML-Namespace geben. Außerdem kommen hierarchische Rollen und mehr zum Thema Single Sign On.
JAX Spring Day - Domain Driven Design mit Spring - Christian Dupuis
Leider kann ich zu dem Talk nichts sagen, weil ich anderweitig beschäftig war...
JAX Spring Day - Technologien sind keine Architektur - Papick Garcia Taboada
Dass Technologien keine Architektur sind zeigte Papick mit einer XML-Analogie: XML kann Sprachen darstellen, aber sagt nichts über die konkret verwendete Sprache. Technologien sind analog eine Meta-Sprache, mit der man bestimmte Architekturen ausdrücken kann. Aber: Technologien machen Spaß - Architekturen nicht. Java EE 5 definiert ein "All in One"-Paket, da es eine Architektur, ein Programmiermodell und eine Infrastruktur vorgibt.
Als Gegensatz dazu gibt es Enterprise Java Next Generation mit Dependency Injection, leichtgewichtigen Containern usw. Dadurch hat man viele Technologien und Frameworks, mit wenig Einschränkungen, vielen Ideen und vielen Freiräumen. Die Technologien sind aber nicht aufeinander abgestimmt (was ich persönlich so nicht glaube), die Best Practivces sind auf einzelne Layers begrenzt und es ist keine Architektur vorgeschrieben.
Also muss man seine eigene Architektur definieren, die eigenen Anforderungen kennen und daraus eine umsetzbare und vermittelbare Architektur bauen. PowerPoint ist keine Architektur, 500 Seiten Word liest niemand und ein Wiki hat keine Struktur. Zutaten für eine Architektur ist Component Based Architectur, SOA - und Performance... Soll man nun eine Architektur technologieneutral definieren? Und wie finde ich raus, ob eine Technologie zur Architektur passt? Und wer schließt die Lücke? Der Architekt, der keine Technologien kennen, oder der Entwickler, der die Technologie nicht versteht?
Also benötigt man einen Super Software Architekt, der die Architektur definiert, Technologien und Ideen verbindet und die Vorgehensweise definiert, Tolls einführt, Coaching und Training durchführt und Begeisterung und Entwicklungskultur etabliert.
Haben verschiedene Architekturen Gemeinsamkeiten? Es geht immer um Divide and Conquer, das Zerlegen großer Herausforderungen in kleinere.
Was sind Komponenten? Spring definiert zum Beispiel welche. Typischerweise haben sie einen Zustand, einen Lebenszyklus, man kann die Abhängigkeiten managen und es gibt gemeinsame Dienste. Also entsteht Zwiebelsoftware mit mehreren Schichten. Eine Alternative sind die Module, mit denen man die Software in einzelne unabhängige Teile aufteilen kann. Die können mehrere "klassische" Schichten umfassen.
Die Module können Abhängigkeiten haben und diese sollten Versionsnummern haben. Die Implementierung der Module kann man hinter Interfaces verstecken, die man dann mocken kann (für Tests zum Beispiel). Und die Abhängigkeiten kann man nach Laufzeit und Compile-Zeit unterscheiden. Außerdem gibt es transitive Abhängigkeiten und dadurch möglicherweise auch unabsichtlich zirkuläre Abhängigkeiten. Die führen dann dazu, dass man im Extremfall das System nicht mehr compilieren kann.
Für die Compile-Time-Abhängigkeiten gibt es dann Maven, für die Runtime-Abhängigkeiten Spring. Das ganze sollte man dann mit Continuous Integration kombinieren, um die aktuellen Sachen auch wirklich zu bauen und den Entwicklern zur Verfügung zu stellen.
Die Subsysteme kann man dann nach technische Infrastruktur, Business Logik und Application Assembly unterscheiden. Man kann dann schon sehr früh Subprojekte nach den technischen Abhängigkeiten strukturieren. Dabei kann man die Technologien in eigene Projekte wie ti-hibernate kapseln. Diese Module enthalten auch eigene Möglichkeiten zur Modularisierung der Konfigurationen.
Er wies dann auf
Antidoto, sein eigenes Open-Source-Framework für die Modularisierung auf Basis seiner Ideen.
JAX Spring Day - Spring OSGi - Martin Lippert, Gerd Wütherich, Bernd Kolb
Dieser Vortrag hat - nicht ganz zu unrecht - den Untertitel "Plattform der Zukunft". Er beginnt mit einer Einführung in OSGi. OSGi ist ein dynamisches Modul-System für Java. Ein Modul (genannt Bundle) besteht aus mehreren Packages. Es gibt Abhängigkeiten zwischen den Modulen und Module können versioniert sein. Außerdem kann man bestimmte Teile der Bundles (public API) exportieren und damit die Sichtbarkeiten einschränken. So kann man zum Beispiel die Implementierungs-Klassen verbergen und nur die Interfaces exportieren. Dadurch kann man das Chaos, das sonst im Classpath leicht herrscht, lösen.
Module können dynamisch zur Laufzeit installiert, gestartet, gestoppt, deinstalliert und aktualisiert werden. Dadurch gibt es natürlich Probleme, wenn man zum falschen Zeitpunkt auf ein Modul zugreift, zum Beispiel wenn es deinstalliert ist.
OSGi definiert außerdem Services. Bundles können die Services veröffentlichen oder ihn verwenden. Die Services können zur Laufzeit kommen und gehen.
OSGi wird seit 1999 von der OSGi-Alliance betreut. Es hat seinen Fokus auf Leichtgewichtigkeit und Dynamik. Es war früher für Embedded Systeme gedacht, mittlerweile wird es auch für Client- und Server-Systeme genutzt. Es gibt verschiedene Implementierung, so Eclipse Equinox, Apache Felix, Knopflerfish, ProSyst mBedded Server Equinox Edition. Kommerzielle Implementierung gibt es von ProSyst und Knopflerfish Pro.
OSGi wird heute schon bei Eclipse genutzt, bei Server-Side Eclipse und bei eRCP. IBM nutzt es bei WebSphere Application Server 6.1, beim Lotus Notes Client und bei Jazz (Team-Kollaborations-Unterstützung für Eclipse). BEA und Oracle sind interessiert. JBoss hat einen Prototyp für eine OSGi-Umstellung. Und auch Adobe baut an solchen Sachen. Außerdem gibt es einen JSR, der OSGi in der Java-7-Plattform integrieren will.
Spring-OSGi ist eine Brücke zwischen Spring und OSGi. Spring-Anwendungen können dann mit OSGi implementiert werden. Es unterstützt Equinox, Felix und Knopflerfish. Dabei soll man die dynamischen Features von OSGi nutzen können. Spring selber muss man dann auch in OSGi-Bundles aufteilen.
Dabei darf sich die Komplexität nicht erhöhen, es sollte beim POJO-Programmiermodell bleiben. Außerdem muss das OSGi-Service-Modell integriert werden: Spring-Beans sollten zu Services werden können und umgekehrt. Und Testing außerhalb des OSGi-Containers muss natürlich auch möglich sein. Und man muss natürlich auch alle anderen Spring-Features nutzen können.
Bundles haben dabei jeweils einen eigenen ApplicationContext. Der wird von Spring-OSGi beim Aktivieren des Bundles automatisch erzeugt und beim Deaktivieren zerstört. Die Konfiguration liegt im Bundle (einem JAR oder Verzeichnis) im Unterverzeichnis META-INF/spring. Die Spring-Beans können mit dem osgi-XML-Namespace als OSGi-Service exportiert werden und die Services können auch in Spring importiert werden. Dadurch kann man den eigenen Code - schon fast traditionell bei Spring - von der OSGi-API unabhängig halten. Außerdem kann man so "public" Spring-Beans, die als OSGi-Services exportiert werden, und "private" Spring-Beans definieren.
Da OSGi dynamisch ist, kann man mit einem Service-Listener auf das Hoch- oder Runterfahren eines Services reagieren. Und auch Zugriff auf Properties aus einem OSGi-Bundle oder Zugriffe auf Bundles sind machbar.
Es schloss sich ein Beispiel an. Ein OSGi-Bundle ist ein Order-Service, der andere ein Customer-Service. Die haben beide ein einfaches Java-Interface als Schnittstelle. Man kann sie auf der OSGi-Konsole installieren, starten, monitoren usw. Und man kann natürlich die Implementierung zur Laufzeit gegen eine andere austauschen. Die Bundles kann man auch über das Internet herunterladen.
Spring-OSGi 1.0M1 wurde am 5.4.2007 veröffentlicht. Es enthält den osgi-XML-Namespace. Es unterstützt auch die Integrations-Tests. Es fehlt Unterstützung für Web-Anwendungen und es gibt einige Probleme mit ClassPath-Problemen. Das Release soll dann zusammen mit Spring 2.1 kommen.
Man kann mit Spring-OSGi Standalone-Server-Applikatione bauen. Er läuft dann auf Basis von OSGi und kann Jetty als Http-Service und Servlet-Container enthalten. Oder man deployt OSGi als Teil des WARs. Eine Servlet-Bridge sorgt dann dafür, dass Requests an die "richtigen" Bundles weitergeleitet werden.
In beiden Fällen werdne die Anwendungen aus Bundles zusammengesetzt. Spring kann inklusive Remoting usw. genutzt werden. Auch auf dem Client (Eclipse RCP) kann man Spring verwenden. Also zum Beispiel kann man dann Dependency Injection für die Extension Points verwenden und damit Views injecten.
In einem aktuellen Projekt benutzten sie Equinox in einem produktiven System. Der Client basiert auf Eclipse-RCP und Spring. Der Server nutzt Spring und OSGi innerhalb von Tomcat.
Labels: JAX, Spring, Spring Day, Spring-OSGi
JAX Spring Day - Spring 2.1 - Jürgen Höller
Als ersten Speaker auf dem Spring Day kam Jürgen Höller zu Wort, seines Zeichens distinguished Engineer und Spring Chef-Entwickler.
Spring 2.1 wird Java 6 und Java EE 5 unterstützen. Es wird kein JDK 1.3 Support mehr haben - die letzten beiden Releases werden unterstützt. Zu JDK 1.6 wird zum Beispiel JDBC 4.0 unterstützt und JSR-223 (Rhino-Scripting). Andere Spring Releases unterstützen schon JDK 1.6.
Spring 2.1 unterstützt Java EE 5 z.B. EJB 3, JTA 1.1, Java Mail 1.4 etc. Ältere Releases unterstützen auch schon JSR 250 (@PostConstruct, @PreDestroy, @Resource). @Resource weißt auf einen Spring-Bean nach Namen oder JNDI.
Bei den Annotationen wird dann auch Autowiring unterstützt (@Autowired). Dazu muss man autowire="annotation" in die Konfiguration schreiben. Dadurch soll Autowiring by Type attraktiver werden, weil man es durch die Annotation besser konfigurieren kann.
@Required zur Markierung benötigter Abhängigkeiten ist jetzt durch depdency-check="annotation" oder default-dependency-check="annotation" konfigurierbar.
Weitere Annotationen werden möglicherweise später auch unterstützt. Und Jürgen reagiert hier auch gerne noch auf Input.
Spring unterstützt jetzt auch Aspectj-Loadtime-Weaving. Das nutzt auch die LoadTimeWeaver wie JPA, dadurch kann man es in einem ApplicationContext einfach aktivieren. Außerdem gibt es auch das beanName-Pointcut-Element für Aspect-Pointcut-Ausdrücke. Dabei werden die Beans durch den Namen des Spring-Beans ausgewählt. Dadurch kann man zum Beispiel mit bestimmten Spring-Bean-Namen bestimmte Pointcuts aktivieren. Dadurch kann man nun wirklich sehr leicht zwischen Spring AOP und AspectJ wählen.
Nächstes Thema ist JMS. In Spring 2.0.3 wurde z.B. für den DefaultMessageListenerContainer die maxConcurrentConsumers-Eigenschaft eingebaut, um die Anzahl der gleichzeitigen Consumer begrenzt. Im Spring 2.1 kommt nun auch Unterstützung für JCA 1.5. Dadurch kann man den JCA-Adapter, den es zum Beispiel auch für JMS-Provider gibt, im Spring ApplicationContext laufen lassen. Auch ein ApplicationContext kann jetzt ein JCA Resource Adapter werden. Das kann dann mit JMX gemanaged werden und man kann dort recht viel machen - die JDO Integration in J2EE lief ja auch über JCA.
Spring 2.1 hat den JPA-Support noch etwas verfeinert. Jetzt wird TopLink, Hibernate, Open JPA unterstützt und bestimmte Erweiterungen wie flush mode='never' werden einheitlich unterstützt. Die JPA-Implementierung bieten zwar alle diese Erweiterungen an, aber eben jeweils mit unterschiedlicher API oder Konfiguration. Spring vereinheitlicht das.
Außerdem wird die WebSphere-proprietäre Transaktions-API unterstützt. Dazu zählt zum Beispiel auch die Unterbrechung (Suspension) von Transaktionen. Die dabei verwendete API ist die offizielle von IBM freigegebene.
Eine wesentliche Innovation in Spring 2.0 waren die XML-Namespaces. In Spring 2.1 kommt ein jms-Namespace hinzu, der die Konfiguration der MessageListenerContainer ermöglicht. Möglicherweise gibt es in 2.1 auch ein jpa- und ein web-Namespace, der vielleicht aber auch erst in Spring 2.2 kommt.
Labels: Interface21, JAX, Jürgen Höller, Spring, Spring 2.1, Spring Day
Neuer Kollege....
Mike Wiesner ist jetzt bei Interface21 Deutschland, siehe auch
hier. Er verstärkt uns mit seinem Spring- und AspectJ-Know-How und seinem Acegi-Kenntnissen. Er schreibt gerade an dem ersten deutschen Buch zu dem Thema und wird unter anderem auf der JAX-Konferenz dazu sprechen.
Open Source Infrastruktur
Vor kurzem gab es in der c't einen Bericht zum Thema "One Laptop per Child", siehe
hier. Für interessiert gibt es
hier auch die Software und eine Emulation zum Herunterladen. Die Idee des Projekts ist , dass man auch in den Entwicklungsländern und Schwellenländern den Kindern Zugang zu Laptops und damit zum Internet gibt. Einige interessante Lösungen (Mesh-Netzwerk-Zugang, schwarz/weiß-Displays wegen hoher Umgebungshelligkeit usw.) sowie der niedrige Preis (100$) machen das ganze technisch recht spannend.
Für mich ist dieses Projekt allerdings Anlaß, über etwas anderes zu schreiben: Mehr oder minder klar ist, dass für ein solches Projekt nur eine Software wie Linux genutzt werden kann - unter anderem wegen des Preis des Laptops, der wohl kaum Geld für Software-Lizenzen übrig lässt. Aber es gibt noch ein anderen Grund: Es ist wohl kaum im Interesse einer Regierung, sich von der proprietären Software eines ausländischen Herstellers abhängig zu machen, um sie dann auch noch allen Kindern zugänglich zu machen - und dafür auch noch zu bezahlen. Solche Grundsätze waren auch ein Grund dafür, Java Open Source zu machen.
Meiner Ansicht nach bedeutet das für den Bereich von Software-Infrastrukturen (Betriebssysteme, Datenbanken, Frameworks), dass Open Source ein Wettbewerbsvorteil ist, weil man dem Hersteller weniger ausgeliefert ist und auch das Risiko ist kleiner: Wenn der Hersteller insolvent werden sollte oder anderweitig in Schwierigkeiten kommt, hat man die Sourcen der Software immer noch zur Verfügung und kann sie weiter entwickeln. Das ist bei proprietärer Software zwar auch oft Teil der Verträge, aber bei Open-Source-Software kommt hinzu, dass es eine Community von Leuten gibt, die das Produkt kennen, so dass man auch tatsächlich weiter an der Software entwickeln kann - Sourcen ohne Hintergrundwissen nützen wenig.
Neben den Kosten ist also auch dieser Risiko-Aspekt wichtig - und bei Spring glaube ich, dass ein Erfolg nur möglich war, weil es Open Source ist und zwar von Anfang an. Ein kommerzielles Framework hätte nie die Verbreitung gefunden, vor allem, weil man es auch nicht "einfach so" einsetzten könnte - man muss ja Lizenzen zahlen. Da Spring vor allem gegen eigen-entwickelte Jave-EE-Frameworks angetreten ist, hätte man wohl in diesem Bereich nie einen solchen Erfolg erreicht, wenn Spring nicht Open Source gewesen wäre und man es nicht so leicht hätte ausprobieren können.
Ein anderer wichtiger Aspekt ist, dass Spring kein Commoditizing vorhandener Ansätze ist. Oft entsteht in Open-Source-Projekten ein - oft wesentlich besserer - "Nachbau" bekannter Software: Also ein Betriebssystem oder eine Datenbank. Spring hingegen ist ein Java-Framework, das in seinem Umfang von keiner anderen Lösung erreicht wird. Es macht also nicht eine vorhandene Lösung billiger verfügbar, sondern es definiert überhaupt erst diese Art von Produkten.
Meiner Ansicht nach ist Open Source also ein sehr interessanter Ansatz, der in Zukunft im Bereich Infrastrukturen sicher noch viel wichtiger werden wird, als es jetzt schon der Fall ist. Und zwar nicht aus ideologischen, sondern aus rein kommerziellen Gründen. Und es macht vieles interessanter - siehe auch
diesesr Blog-Eintrag von Rod Johnson, CEO von Interface21.
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
