Neue Informationsquelle
Floyd Marinescu, der Mann hinter
TheServerSide.Com, hat eine neue Informationsquelle aufgemacht:
InfoQ. Es geht über Java hinaus und damit meine ich nicht nur .NET, sondern zum Beispiel auch agile Methode, SOA oder Ruby. Einen Blick ist es wert!
Interview...
...ja, ich gebe auch Interviews, zum Beispiel für die
JAX-Letter. Wenn's denn interessiert...
Neues Produkt von Interface21
Wie man
hier und
hier nachlesen kann, hat Interface21 ein neues Produkt: Eine Unterstützung von
JSR 250. Dabei geht es um einige Annotationen, die in Java EE 5 verwendet werden und unter anderem für Dependency Injection genutzt werden, also zum Beispiel
@Resource. Damit bietet auch Spring dieses Konfigurationsverfahren an.
Dieser Schritt bedeutet nicht, dass Spring das EJB 3 Modell übernehmen wird. Die Konfiguration von Dependency Injection über Annotationen, wie sie in EJB 3 vorgenommen wird, ist nicht der Weisheit letzter Schluss, weil so die Komponente selbst ihre Konfiguration kennt. Eigentlich sollte (trivialerweise) die Komponente von außen konfigurierbar sein und nicht die Konfiguration in sich tragen. Java EE geht hier den Weg, dass
@Ressource nur einen Namen aus einem JNDI-Kontext enthält, so dass dadurch die Konfiguration von außen durch Änderungen im JNDI-System möglich ist. Was allerdings passiert, wenn man die Komponenten in einer Java SE Umgebung ohne JNDI zum Beispiel zum Testen laufen lässt, ist offen. Hier ist Spring eleganter, da der Code vollständig von Konfiguration frei ist und auch kein JNDI benötigt.
Noch erstaunlicher (aber auch nicht Teil von JSR 250) sind die
@Interceptor Annotationen von EJB 3. Sie sollen aspektorientierte Programmierung (AOP) einführen. AOP dient eigentlich dazu, ein Querschnittsbelang wie z.B. Tracing oder Security allen Klassen hinzuzufügen, für die dies notwendig ist. Mit EJB 3 muss man leider die Klassen selbst mit der Annotation
@Interceptor versehen, was das Prinzip ad absurdum führt: Die Klasse soll ja gerade frei von dem Belang sein. Ich habe auch schon Code gesehen, der dann in dem Interceptor schaut, ob die Klasse bzw. Methode eine Annotation hat. Das kann man statisch entscheiden und muss es nicht bei jedem Methodenaufruf tun, denn so entsteht ein unnötiger Overhead. Natürlich sind Spring AOP und AspectJ zu solchen Optimierungen in der Lage und auch die Definition einer Reaktion auf eine Annotation ist wesentlich einfacher.
Elemente wie
@PostConstruct oder
@PreDestroy hingegen sind vielleicht keine so schlechte Idee: Sie legen fest, welche Methode am Ende des Lebenszyklus aufgerufen werden sollen bzw. nach dem Erzeugen der Objekte.
Ingesamt geht es hier also um das, worum es bei Spring schon immer gegangen ist: Freiheit. Die Nutzer von Spring können nun auch JSR 250 Annotationen verwenden, wenn sie dies wollen. Ob das wirklich einen Vorteil bringt, ist eine andere Frage...
PS: Code-Beispiele gibt es
hier.
Das Interface21 Geschäftsmodell
Was ist eigentlich das Geschäftsmodell von Interface21? Auf den ersten Blick könnte man denken, dass es relativ offensichtlich und einfach ist: Wir haben ein erfolgreiches Open Source Projekt (Spring), darauf basierende andere erfolgreiche Open Source Projekte (das Acegi Security Framework, Spring Web Flow, Spring Web Services) und z.B. auch Know How und Einfluss im Bereich AspectJ. Also bieten wir in diesen Bereichen Consulting und Training an.
Dieses Modell ist klassisch für Open Source. Es kommt aus dem Bereich der Infrastruktur-Software wie Betriebssystemen, Datenbanken usw. Die Idee ist, dass der Hersteller selbst am besten dafür sorgen kann, dass die Software in Produktion auch funktioniert bzw. Nutzer am besten trainieren kann. Das ist mit Sicherheit ein wichtiger Teil des Interface21 Geschäftsmodells.
Mit Spring gibt es aber auch einen anderen Aspekt: Spring ist in erster Linie ein Programmiermodell. Das bedeutet, es definiert, wie man Software schreibt und bietet eine Abstraktion über die Dienste der Infrastruktur (Application Server usw.). Daher beeinflusst es auch die Architektur und überhaupt das Vorgehen im Projekt - die nicht völlig offensichtlichen Auswirkungen im Bereich Testen habe ich zum Beispiel in einem Vortrag auf der JAX dargestellt. Das ist ein wichtiger Unterschied zu Datenbanken, Application Servern oder Betriebssystemen, die das Programmiermodell bei weitem nicht so stark beeinflussen.
Aus genau diesem Grund bieten wir auch Consulting zum Thema Architektur und zu anderen Themen im Enterprise-Umfeld. Dabei kommt uns auch Spring wieder zur Hilfe: Da es Open Source ist, müssen wir kein Vertrieb für Lizenzen machen. Auch nicht, um Spring-bezogenes Consulting zu verkaufen: Wir sind ja gerade mit einem breiteren Leistungsspektrums im Enterprise Bereich aufgestellt und machen nicht nur Spring. Wobei die Qualität von Spring natürlich außer Frage steht und es kann eigentlich jedes Projekt von Spring profitieren: Spring bietet eben für praktische alle typischen Herausforderung im Enterprise-Umfeld eine Lösung z.B. durch die Integration anderer Frameworks.
Wegen des radikal modularisierten Aufbaus von Spring haben wir gleichzeitig die Möglichkeit, genau jene Teile von Spring in einem konkreten Projekt zu verwenden, die dort einen Vorteil erbringen. Die dann anzuwendende Migrationsstrategie ist eine weitere interessante Sache.
So sind wir recht offen und unabhängig. Das liegt mir auch persönlich sehr am Herzen, denn von orthodoxen Ansätzen gerade im Enterprise Java Bereich gibt es genug.
Unsere Unabhängigkeit ist auch recht offensichtlich: So bieten wir auch zu Hibernate Trainings an, obwohl wir dieses Produkt nicht selber entwickeln. Da wir aber zum Beispiel mit der Integration von Hibernate in Spring einen Berührungspunkt mit Hibernate haben und das auch auf einer nicht-trivialen technischen Ebene, arbeitet hier Spring in einer anderen Funktion für uns: Wir können auf Spring als Referenz für unser Know-How verweisen. Dies gilt auch allgemeiner: Wer eine solche umfangreiche und gute Lösung für Enterprise Java Probleme wie Spring entwickelt, kann sicher auch unabhängig vom Spring-Framework Lösungen für typische Probleme bei Enterprise Anwendungen aufzeigen. Und genau das wollen wir tun!
Neue MacBooks...
Apple hat jetzt die neuen MacBooks als Nachfolger der iBooks vorgestellt. Eigentlich schöne Geräte mit einer höheren Auflösung und einem immer noch kompaktem Format. Ich bin ein Fan von wirklich mobilen Geräten wie z.B. dem 12" Powerbook, das ich jetzt einige Zeit nutze.
Ein MacBook kommt mir allerdings nicht in's Haus, denn die Erfahrungen mit den iBook Gehäusen, die offensichtlich genauso gestaltet sind wie jetzt bei den MacBooks, sind einfach schlecht. Die Powerbooks und jetzt MacBooks Pro haben hier wesentlich mehr zu bieten. Gerade Qualität in diesem Bereich ist bei mobiler Nutzung eine wichtige Sache und die iBooks haben mich hier enttäuscht, immerhin habe ich zwei kaputt bekommen. Außerdem haben die neuen MacBooks ein Display mit glänzender Oberfläche, was ich auch für eine totale Unart halte.
Also muss ich wohl zu einem MacBook Pro greifen, wenn ich mein Powerbook ersetzten will, und dann zu einem 15" Gerät. Das bedeutet weniger Mobilität, dafür aber ein Slot für Erweiterungskarten (z.B. UMTS) und mehr Bildschirmauflösung. Schade, dass Apple nicht ein 13" MacBook pro baut, vielleicht dann noch in dem schicken schwarzen Design...
Back to the Future mit Smalltalk
Der letzte Vortrag auf den Entwicklertagen, den ich mir angeschaut habe, war "Aufbau dynamischer Web Anwendungen mit Smalltalk". Es ging um ein Framework, dass die OBJECT dynamics GmbH gebaut hat. Es enthält Host Connectivity, eine Rules Engine und eine Möglichkeit Web Oberflächen zu bauen, die nach dem AJAX-Prinzip arbeiten, wobei es dafür auch einen GUI-Editor gibt. Da kommen wir mit Java Rules Engines, JCA und JSF jetzt auch langsam hin. Schon erstaunlich, was man mit so "antiquierten" Technologien alles hinbekommen kann. Leider war der Vortrag nicht sehr gut besucht (<10 Leute), dafür umso interaktiver. Eine nette Abwechselung von dem ewigen Java / .NET usw. Sachen, die mir gut gefallen hat.
Entwicklertage
Heute bin ich also bei den Entwicklertagen in Karlsruhe. Schon beim Frühstück habe ich Alexander v. Zitzewitz von hello2morrow getroffen. Seine Session habe ich dann auch als erste besucht. Es ging um Architektur-Management mit SonarJ. Mit diesem Werkzeug ist es möglich, die Aufteilung in Layer einer Anwendung sicherzustellen, was ich auch schon ausprobiert habe. Interessant war für mich vor allem, dass in Hibernate jede Klasse im Mittel von 670 anderen abhängt und dass 54 der ingesamt 57 Packages in einem Zyklus sind, was die Änderbarkeit wahrscheinlich nicht positiv beeinflusst... :-)
Der zweite Vortrag war von Oliver Böhm über AOP und AspectJ. Er ging vor allem auf technische Aspekte wie Tracing, Monitoring oder Mitschneiden der Kommunikation mit anderen System. Die mitgeschnittenen Sachen kann man dann wieder für Tests verwenden. Ebenfalls zeigte er das Deklarieren von Fehler für das Einhalten von Layering und einen Aspect für Exception Logging. Vor allem interessant waren seine Erfahrungsberichte aus verschiedenen Projekten. Eine für mich überraschende Aussage war, dass der Schritt von OOP zu AOP so groß ist wie der von prozeduraler Entwicklung zu OOP. Meine Erfahrung ist eher, dass sich mit Spring das mehr oder minder automatisch ergibt, da man für Transaktionen, Sicherheit usw. eh AOP nutzt und dann der Schritt zu eigenen Aspekten oder Performance und Logging kein großer ist. Ich denke auch, dass Spring AOP eine niederigere Einstiegshürde hat als AspectJ. Gerade mit der Integration verschiedener AspectJ-Features in Spring 2.0 ergibt sich ein sanfter Migrationspfad von OOP über Spring AOP zu AspectJ (wenn man AspectJ braucht).
Future of Enterprise Java
In unserem Podcast findet sich jetzt eine Episode, an der ich nicht unwesentlich beteiligt war: Es geht um die Zukunft von Enterprise Java. Mehr gibt es
hier. Der Podcast ist allerdings in Englisch...
Java Magazin berichtet es auch schon
hier.
Nächster Termin: Entwicklertage Karlsruhe Freitag
Der nächste öffentlichkeitswirksame Termin in meinem Kalender sind die
Entwicklertage in Karlsruhe.
Aus gegebenen Anlass zitiere ich hier die oben genannte Web-Seite:
Ein Top-Thema wird in diesem Jahr sicherlich das OpenSource-Framework Spring sein. Als Sprecher konnte Eberhard Wolff, Autor des Buchs "Spring. Frameworks für die Java-Entwicklung" gewonnen werden.
JAX: Spring Power Workshop
Der letzte Tag der JAX habe ich damit verbracht, einen Spring Power Workshop durchzuführen. Der Workshop war recht voll und dementsprechend auch der Raum. Es gab dennoch einige Fragen aus dem Publikum, was ich recht wichtig finde, weil man nur so tatsächlich auf die individuellen Bedürfnisse der Teilnehmer eingehen kann. In dem Workshop ging es dann um Dependency Injection, AOP und die API Abstraktionen zum Beispiel für Hibernate oder JDBC, was schon mal ein guten Einstieg bringen sollte. Natürlich ist dies nicht vergleichbar mit dem 4-Tage-Training, das wir als Interface21 sonst als Spring-Einführung anbieten - das sollte wohl aber keiner erwartet haben.
JAX: Spring und Testen
Meine letzte Session auf der Hauptkonferenz war zum Thema "Spring und Testen". Diese Session war mir ein besonderes Anliegen, denn ich glaube, viele der Technologien in Spring haben sehr viel mit Testen zu tun und diese Zusammenhänge sind nicht immer offensichtlich. So ist es noch recht klar, dass Dependency Injection dazu führt, dass man Anwendungen besser Unit testen kann. Aber auch der Test einer Klassen-Kollaboration ist mit Spring viel einfacher und auch das Aufräumen der Datenbank wird hier gut unterstützt.
Nich völlig trivial ist, dass Spring auch bei fachlichen Tests unterstützt, da mit Spring die Anwendung in Services aufgeteilte wird, also z.B. DAOs, Geschäftsprozesse usw. Diese Services sind zumindest in einigen Fällen Implementierungen von Geschäftsprozessen, die dann durch Fit oder Fitnesse getestet werden können. Dort habe ich dann auch kurz mein Fit Integration
Spring-Fitnesse vorgestellt.
Wesentlicher Vorteil, den man ebenfalls in all diesen Test-Arten hat, ist, dass Spring umgebungsunabhängig ist: Man kann die Tests in einer einfacher Umgebung ohne Application Server lassen, was das Testing wesentlich vereinfacht.
Auch bei System Tests hat Spring Vorteile: Durch AOP kann man sehr einfach in der Anwendung Fehler suchen, indem man Tracing einbaut, oder man kann Performance messen, indem man einen passenden Interceptor einbaut.
Ingesamt glaube ich daher, dass Spring eine deutliche Vereinfachung beim Testen sein kann und zwar weit über Unit-Tests hinaus.
JAX: Keynote von Rod Johnson
In Rods Keynote ging es um das Thema "Escaping the Technology Cycle". Ausgangspunkt ist, dass wir mit Java anstreben, jene Probleme zu lösen, die vorher mit Main Frames gelöst worden sind. Java und Main Frames kommen aber von zwei unterschiedlichen Ecken: Bei Main Frames funktioniert alles wie dokumentiert und eine neue Version gibt es nur alle Jahrzehnte und auch dann bleibt alles stabil.
Als Java Beispiele nannte Rod auf der einen Seite Known Bugs: Er hat "damals" ein Applet für Netscape geschrieben und einem Manager vorgestellt. Dieser fragte, warum etwas auf eien bestimmte Art implementiert sei. Rod's Antwort war, dass das ein Work Around für ein Known Bug wäre. Der Manager kam aus dem Main Frame Bereich und hatte ein echtes Problem damit, dass es einen Fehler gibt, den man kennt, aber nicht fixt.
Ein anderes Problem sind die vielen Updates: Innerhalb für Main-Frame-Verhältnisse recht kurzer Zeit werden Technologien geupdatet und dabei wird z.B. bei EJB von 1.1 auf 2.0 und von 2.0 auf 3.0 in kurzer Folge das Programmiermodell mehrfach geändert, was dann zu hohem Aufwand bei der Migration führt. Es kann nicht sein, dass man für jede neue Technologie den Code ändern muss, wenn man wirklich profitieren will. Aktuell gehen ja schon hier in Bezug auf EJB 3 die ersten Sachen in dieser Richtung los...
Das bedeutet auch, dass als Lösung Standards wie eben beispielsweise EJB nicht reichen, um die Code Basis von diesen Änderungen frei zu halten. Trotzdem arbeitet Interface21 an Standards mit, ein Beispiel ist
SCA, wo es mal nicht nur um Java, sondern um SOA geht.
Wie dem auch sei: Hier geht es eben doch um Java und eine weitere Aussage war, dass ein guter Indikator dafür, was ein POJO ist, ein JUnit Test sein kann: Was man unit-testen kann, kann man auch als POJO bezeichnen.
Rod sieht auch Annotationen aus JDK 1.5 kritisch: Sie sind das neue tolle Spielzeug, dass jetzt überall verwendet wird. Ein sehr erstaunliches Beispiel ist AOP in Java EE 5 / EJB 3: Dort zeigt die Klasse selbst an, womit sie ergänzt werden soll. Das Ziel von AOP ist allerdings, Dinge zu zentralisieren, die sonst verteilt sind. Hier allerdings wird der Aspekt immer noch verteilt konfiguriert. Das ist zumindest ungewöhnlich...
JAX: Adrian Colyer / AOP with Spring for Enterprise Applications
Gestern abend sprach Adrian Colyer (ebenfalls Interface21) über "sein" Thema: AOP. Ein recht kurzweiliger Vortrag, in dem unterschiedliche Möglichkeiten für Security mit Acegi gezeigt wurden und dann auch Performance-Monitoring mit JAMon. Dazu kam die Möglichkeit, normale Java Objekte mit @Configurable durch Spring konfigurieren zu lassen.
Vor allem hat Adrian recht beeindruckend dargestellt, wie einfach man mit dem Aspekt-Werkzeugkasten typische Problem wie Security oder eben auch Monitoring lösen kann - und das nicht nur auf den Folien, sondern auch live. Und das alles auf eine kurzatmige und lustige Art und Weise.
Spring hat den 1. Preis beim JAX Innovation Award gewonnen!
Spring hat gerade den 1. Preis beim JAX Innovation Award gewonnen! Ein schöner Beweis dafür, dass Spring eine echte Innovation darstellt und als solche auch wahrgenommen wird.
Heise hat die Nachricht auch schon:
hier...
Dem Leser bleibt es überlassen, sich zu überlegen, wer Spring wohl nominiert hat...
Hinter den Kulissen von Spring
Jürgen Höller sprach dann vorgestern abend zu dem Thema "Hinter den Kulissen von Spring".
Dabei gab es erst mal Trivia: Spring hat neben der Bedeutung "Frühling", die mittlerweile vor allem genutzt wird, auch die Bedeutung "Feder" und es gibt auch "Spring into life". Im Moment hat Spring 30.000 Downloads/Monat.
Interessant ist auch der Blick in die Struktur von Spring: 99% des Codes kommt von 6 Committern, 80% von zwei (Rob Harrop und Jürgen Höller, beide von Interface21). Dadurch wird auch nochmal klar, welchen Einfluß Interface21 hier hat. Weniger ist hier einfach auch mehr: Es gibt zentralisierte Entscheidungen und dadurch kann man auch Design-Entscheidungen konsistent durchsetzen.
Ein wichtiges Werkzeug ist dabei
JIRA, mit dem man nicht nur Bugs reporten kann, sondern auch Vorschläge für neue Features und sogar die Roadmap kann man diesem Tool entnehmen. Der Hauptvorteil von Open Source ist, dass man auf diese Weise viele Submissions bekommt und auch sonst viel Feedback: Sei es neue Konzepte aber auch Code.
Mittlerweile ist rund um Spring ein ganzes Ökosystem entstanden mit Spring Web Flow, Spring Web Services, Spring Rich Client und dem Acegi Framework.
Jürgen setzte sich dann mit dem klassischen Applicatioin Framework auseinander. Im Gegensatz zu den monolithischen Ansätzen, die alle Probleme in der Anwendung zu lösen versuchen, versucht Spring hier einen Best of Breed Ansatz d.h. man kann aus den integrierten Frameworks das beste für einen bestimmten Zweck auswählen. Auch die Teile von Spring selbst kann man getrennt voneinander verwenden. Diese Separierung ist sehr wichtig und es oft bei der Entwicklung eine echte Herausforderung, so zum Beispiel bei den neuen XML Schemata im Dependency Injection Container für Spring 2.0, die zwar für spezifische Subsysteme wie AOP oder Transaktionsmangement verwendet werden sollen, aber gleichzeitig darf der Container nicht von diesen Subsystemen abhängig werden.
Ein weiterer wichtiger Punkt war, dass man durch Spring die Infrastruktur durch ein Update der Anwendung austauschen kann: Man kann die neuen Feature von Spring 2.0 verwenden, wenn man einfach nur die Anwendung mit den passenden JARs ausliefert - ein Update des Application Servers ist nicht nötig. Dieses Vorgehen ist wesentlich risikoärmer und in der Realität haben die meisten Betriebsabteilungen eine Ehrfurcht davor, ein Update eines Application Servers vorzunehmen. Man kann so etwas auch nur dann tun, wenn man vorher umfangreiche Tests macht. Spring geht hier sehr weit: Selbst Spring 2.0 funktioniert noch auf Java EE 1.2 und es gab auch schon einen Bug Report für Spring 2.0 M4, also eine brandneue Version von Spring, auf IBM Web Sphere 3.5 aus dem Jahre 2000, was nochmal zeigt welche breite Unterstützung von Plattformen Spring anbietet.
Heute @ JAX
Den heutigen Tag habe ich mit meinen beiden Sessions ("SOA - eine nicht-technische Betrachtung" und "Spring: Das neue J2EE?") verbracht und dann am Stand. Die beiden Sessions waren recht gut besucht und insbesondere bei dem SOA-Vortrag hatte ich das Gefühl, dass hier wirklich an einigen Stellen der Schuh drückt und ich bin auf das Speaker Panel zu SOA gespannt.
Zu viel mehr bin ich nicht gekommen - von daher keine Neuigkeiten von den Sessions. Die neue Lokalisation - die JAX zum ersten Mal in Wiesbaden - sind recht gelungen: Sie sind groß genug und es gibt nun ein Forum, an das die Hallen angrenzen, so dass man sich zwischen den Sessions ganz gut dort aufhalten kann und das lädt dann auch zum Besuch der Messe ein.
Heute abend gibt es dann noch den Vortrag "Hinter den Kulissen von Spring" für Jürgen Höller, in dem ich gerade sitze...
Spring Tag - Teil 2
Das JSF-Spring Framework, das vom Entwickler Andreas Kuhrwahl selbst präsentiert wurde, stellt eine interessante Verbindung zwischen JSF und Spring her und ist ein gute Vermittler zwischen dem Dependency Injection Mechanismus von Spring und JSF.
Michael Wiesner zeigt dann, wie man mit Acegi Anwendungen absichern kann. Gerade durch den Vergleich mit JAAS wurde deutlich, dass Acegi hier wesentlich flexibler und eleganter ist.
Ein interessanter Vortrag von Martin Lippert und Gert Wütherich schloß sich an: Es wurde gezeigt, wie man auf diese Art und weise ein grob-granulereres Komponentenmodell über die Spring-Beans legen kann und vor allem, wie man dann diese Komponenten individuell hoch- und runterfahren kann. Für Updates in Enterprise Systemen sicher eine interessante Sache. Dabei kam Code aus der Spring Sandbox zum Einsatz, der voraussichtlich in Spring 2.1 integriert wird - hier sieht man den Vorteil davon, wenn man Open Source konsequent lebt. Das ganze ist nicht Theorie, sondern soll in einer Bank produktiv eingesetzt werden.
Es folgten dann drei Case Studies. Mein Ziel war hier, einen Eindruck von der Vielfalt der Einsatzgebiete von Spring zu geben. Den Anfang machte Matthias Ernst, Entwickler bei coremedia, der bereits Spring ab der Version 0.9 eingesetzt hat. Coremedia entwickelt Software für Content Management und Digital Rights Management mit hohen Anforderungen an Skalierbarkeit. Zu den Kunden gehören z.B. TOnline (CRM) oder Vodafone (DRM für Klingeltöne). Er zeigt auf, an welchen Stellen im Produkt Spring eingesetzt wird. Dabei bescheinigte er Spring ein exzellentes Anwortverhalten bei Bugs oder Feature-Requests. Außerdem zeigte er auf, dass Spring die Flexibilität und überhaupt das ganze Design der Software positiv beeinflusst hat. Kritik gab es auch: Große XML-Konfigurationen sind schwer handhabar und Matthias wieß in diesem Zusammenhang auf verschiedene Projekte (u.a. sein eigenes hin), dass dieses Problem mit Annotationen angeht.
Oliver-Arne Hammerstein von Opitz Consulting sprach dann über die Entwicklung eines Ingenieurs-Systems für das Berechnen von Belastungen von Teilen aus dem Flugzeugbau. Hier gab es viele interessante Herausforderungen: Eclipse RCP integrieren, die Integration von C++ Code mit AspectJ, Persistenz eines komplexen Objekt-Modells mit Hibernate.
Den Abschluß der Case Studies bildete dann Christian Dupuis von Accenture, der von einem Projekt bei einer Bank berichtete. Nach der Darstellung der Vorteile endete er mit den Aussagen, dass Spring mittlerweile ein "de facto Standard" bei Accenture sei und sich außerdem Spring vorteilhaft auf die Motivation der Mitarbeiter auswirkt ("Es macht einfach Spaß") und auch auf die Code-Qualität ("Der Code des Spring Frameworks ist so toll - warum kann unser nicht auch so aussehen?")
Den Abschluß bildete das Speaker-Panel auf dem dann die Speaker sich den Fragen des Publikums stellten. Dort spielten technische Fragen eine wichtige Rolle, aber auch eher strategische.
Ingesamt ein runder Tag, der vor allem gezeigt hat, wieviel von Spring im deutsprachigen Raum passiert, und dass die Nutzer recht begeistert sind.
JAX Spring Day
Heute findet der JAX Spring Day statt. Den Auftakt bildete Jürgen Höller als CTO von Interface21 und Chef Entwickler von Spring. Er sprach über Spring 2.0 mit dem Fokus auf die neue Konfiguration und die anderen Neuigkeiten im Bereich AOP, @Configurable usw. Ingesamt ist es schön, die Informationen zu dem neuen Release direkt vom Entwickler zu bekommen und Jürgen ist seitdem auch in heißer Diskussion mit Konferenz-Teilnehmern.
Christian Dupuis von Accenture sprach dann über Spring Web Flow, mit dem man Abläufe in Web-Anwendungen direkt implementieren kann, und Spring IDE, dem Plug-In für Spring in Eclipse. Spring IDE bietet auch eine Unterstützung für Spring Web Flow, so dass es ein runder Vortrag war.
Aktuell läuft der JSF-Spring Vortrag von Andreas Kuhrwahl, dem Chef-Entwickler dieses Frameworks.
Man sieht also deutlich, wie stark die Spring-Community in Europa und im deutschsprachigen Raum ist und ich denke, wir geben den Teilnehmern einen guten Eindruck von Spring und den dazugeehörigen Projekten.
Außerdem haben 2 der bisher 3 Vortragenden Apple Notebook... :-)
Spring für den JAX Innovation Award nominiert
Das Spring Framework ist für den JAX Innovation Award nominiert worden und ist damit in der Runde der letzten 10, wie man
hier lesen kann. Das Ziel des JAX Innovation Awards ist es, den besten Beitrag aus dem europäischen Raum zum Thema Eclipse und Java zu finden.
Software Engineering Radio jetzt beim JavaMagazin
Das Software Engineering Radio wird jetzt auch auf http://www.javamagazin.de/ gefeaturt!
Warum ist Architektur schwierig?
Der Kommentar zum letzten Architektur-Posting zeigt schon ein wenig, warum das Entwerfen einer Architektur so schwierig ist: Es geht darum, die fachlichen Abstraktionen zu finden, was in den Bereich der Analyse hineinreicht. Man muss nämlich die fachlichen Anforderungen soweit verstehen, dass man sogar entscheiden kann, was die allgemeinen Begriffen in diesem Bereich sind.
Gleichzeitig muss man technische Realisierungen dieser Abstraktionen finden. Diese müssen dann den nicht-funktionalen Anforderungen genügen, was nicht immer einfach ist.
Man muss also sowohl Analyse und damit die Domäne als auch die Technik zumindest einigermaßen (oder besser sehr gut) verstehen.
Gleichzeitig muss eine Architektur, damit sie den Namen auch verdient, im gesamten Projekt einheitlich verwendet werden. Wenn dies nicht der Fall ist, muss man untersuchen, ob das auf prinzipielle Probleme hinweist - und gegebenenfalls die Architektur anpassen. An dieser Stelle verschwimmt dann auch die Grenze zwischen Architekt und Entwickler: Der Entwickler findet ein Problem in der Architektur, weil er etwas nicht entwickeln kann und baut dann etwas, womit er es kann. An dieser Stelle ändert er die Struktur der Software und damit die Architektur. Dadurch wird allerdings gleichzeitig auch die einheitliche Verwendung der Architektur so gefährdet.
Da die Architektur einheitlich verwendet wird, kann es außerdem auch sein, dass eine Änderung der Architektur schwierig und aufwändig wird. Daher ist der Entwurf einer Architektur eben auch risikobehaftet.
Was ist Architektur?
Bevor ich das Thema Architektur und Architekten weiter vertiefe, will ich mich zunächst an einer Definition versuchen, was Architektur überhaupt ist. Bevor man über etwas redet, sollte man definieren, was das etwas überhaupt ist. Meine Definition sieht folgendermaßen aus:
Die Architektur eines Software-Systems definiert, welche grundlegenden Abstraktionen in dem System verwendet werden und wie diese technische realisiert werden.
Für ein Geschäftssystem wären die Grundabstraktionen also sowas wie Geschäftsprozesse, Geschäftsentitäten usw. und die technische Realisierung könnte dann EJBs oder Spring-Beans sein. Bei der Abbildung auf Spring-Beans sei noch hinzugefügt, dass diese keine echte technische Abbildung ist. Die Spring-Bean kann nämlich (ohne Code-Änderungen) zu einem Web-Service oder (mit einem zusätzlichen Adapter) zu einer EJB werden. Dies ist gerade einer der Vorteile von Spring: Es gibt eine Implementierung, die auf verschiedenen technischen Infrastrukturen laufen kann.
Warum ist Architektur wichtig? Zum einen kann durch eine einheitliche Architektur die Wartung des Systems vereinfacht werden, da die Struktur überall gleich ist und man sich schnell zurecht findet. Aus demselben Grund kann die Produktivität der Entwickler steigen: Sie schreiben nur noch den fachlichen Code runter, und die Abbildung auf Technik entsteht anderswo, eben durch die Architektur-Entscheidungen.
Viel wichtiger ist aber , dass die Architektur die grundlegenden technischen Entscheidungen enthält und eine Änderung in diesem Bereich im laufenden Projekt schwer sein kann. Daher ist das Hauptrisiko nicht Wartbarkeit, sondern dass man hier eine falsche Entscheidung trifft, die später schwer revidierbar ist.
In Kürze wird es unter
http://www.se-radio.net/ übrigens auch einen Podcast zum Thema Architektur geben.
Gibt es Architekten?
Wie schon in einem der Kommentare zu einem der letzten Posts angesprochen, ist eine weitere interessante Frage, ob es überhaupt Software Architekten gibt. Ich erinnere mich noch recht gut an ein Zusammentreffen verschiedener Leute, unter denen recht viele waren, die den Titel auf der Visitenkarte haben. Die Begrüßungrunde erinnerte dann an eine Selbsthilfe-Gruppe: Der erste Teilnehmer begann seine Vorstellung mit "Ich heiße ... und ich entwickel Software.", was dann von den meisten anderen übernommen wurde. An sich verstehen Software-Architekten sich also oft als Entwickler. Das entspricht auch dem üblichen Karriere-Profil: Man fängt als Entwickler (sozusagen Fußvolk) an, dann kann man Architekt werden und wenn es gut läuft, wird man Projektleiter. Je weiter man sich dann entwickelt, desto weniger muss man vom Coden verstehen und desto mehr Geld gibt es (wenn es gut läuft).
Also ist ein Architekt nur ein teurer Entwickler, der erfahren ist und daher weniger coden muss, was an sich eigentümlich ist. Dafür darf er Enwicklern Vorschriften machen. Darin stecken auch gleich wieder mehrere Probleme. Wenn er nicht mehr selbst codet, kann er schlecht Vorschriften machen. Außerdem geht das ganze von einer Arbeitsteilung zwischen Vorarbeiter (Architekt) und Entwickler (Fußvolk) aus, die vielleicht im produzierenden Gewerbe funktioniert: Es gibt einen, der die anderen bei der Arbeit anleitet, weil er mehr davon versteht und die anderen arbeiten. Aber auch hier gilt, dass die Leute, die die Arbeit machen, vielleicht doch etwas von der Arbeit verstehen.
Meiner Ansicht nach sollte daher der Architekt aber eine kommunikative Rolle haben: Er sollte mit den Entwicklern sprechen und herausfinden, wo Probleme oder vielleicht auch gute Ansätze sind, um dann die Probleme zu lösen oder die guten Ansätze zu unterstützen. Dies ist eher eine helfende oder coachende Funktion, währen klassisch der Architekt eher die unwissenden Entwickler kontrolliert.
Überhaupt ist ein wesentliches Problem, dass Entwickler eben tatsächlich oft als Fußvolk gesehen werden. Ich empfinde das als problematisch und arbeite bei einer Firma, bei der selbst der CEO ein Entwickler ist. Und andere, sehr erfolgreiche Firmen wie z.B. Google schreiben sich auch auf die Fahnen, eher mit kleinen Teams mit wenigen Entwicklern zu arbeiten und nicht so sehr auf eine Differenzierung zwischen Entwicklern und Architekten zu setzen. Auch das Spring-Framework ist die Arbeit einiger weniger Entwickler. Wenige, sehr gute Entwickler können also ein recht gutes Modell sein.
Auch dies spricht dafür das man einem Architekten - wenn es ihn denn gibt - eine kommunizierende Rolle geben sollte, denn die Entwickler selber sind hoch qualifiziert und brauchen nicht unbedingt eine Aufsicht. Letzendlich bedeutet das auch, dass der Architekt nicht die Architektur bestimmt, sondern den Prozess zum Erzeugen einer Architektur moderiert. Oder?
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
