Code-Metriken auf dem Prüfstand

Wie lässt sich die Qualität von Code bestimmen? Welche Kriterien sollen dafür hinzugezogen werden?
Eine mögliche Antwort könnte sein: „So gut wie die Abnahme-Testresultate des Kunden“… Stimmt, aber das würde erstens bedeuten, dass die Qualität des Codes erst gegen Ende des Projekts hin gemessen würde und dies auch nur als Momentaufnahme. Und zweitens, ein Abnahme-Test kann aus Zeit/Budget-Gründen nie das Gesamtsystem testen. Obwohl das eigentliche Testing einen sehr wichtigen Beitrag zum Erfolg eines Projektes beiträgt, ist es – was die Qualität des Codes betrifft – nicht unbedingt alles.

Eine der zentralen Herausforderungen, welche sich bei der Entwicklung von Software stellt, ist die, dass das gesamte System eigentlich nie in den Blick zu bekommen ist. Ein Entwickler sieht immer nur einen sehr kleinen Ausschnitt davon im Editor seiner Entwicklungsumgebung. Um es zu vergleichen… wie gut würde wohl ein Auto/Haus/Brücke/etc., wenn jeder der Beteiligten während des gesamten Entwicklungszeitraums den zu konstruierenden Gegenstand immer nur durch eine kleine Öffnung von sagen wir 20cmx20cm sehen würde? Ich möchte nicht als erster über die Brücke… :-) Und genau hier unterscheidet sich die Konstruktion von Software von der Konstruktion von anderen realen Dingen.

Die Frage, die sich also weiter stellt ist: „Wie bekomme ich eine einheitlichere Sicht auf die gesamte Codebasis, welche ein Softwaresystem ausmacht?“… und das bitte so, dass es die Entwickler in keinster Art und Weise stört. Genau in diese Presche springen Werkzeuge, welche Metriken und Codeüberprüfungen über den entwickelten Code erstellen. Sonar von Sonarsource ist so ein Werkzeug, welches a) Opensource ist und b) für Java-Projekte verwendet werden kann. Bei Namics haben wir im Januar ein Pilotprojekt gestartet, bei welchem von Beginn weg Code-Metriken erfasst und ausgewertet wurden. Diese Erfassung erfolgt automatisch und zeitgesteuert durch den Bamboo-Server , welcher als Continuous Integration Server bei Namics fungiert. Und es werden nicht nur Code-Metriken erfasst. Sonar bietet auch die Möglichkeit, neben Metriken den Code auch auf allgemein bekannte Programmierfehler hin zu überprüfen (Abschliessende Features siehe http://www.sonarsource.org/features/).

Das Fazit nach fast sechs Monaten fällt für mich durchwegs positiv aus. Die anfängliche Skepsis gegenüber einem weiteren Werkzeug, welches im Softwareentwicklungsprozess integriert ist, hat sich definitv „in Luft aufgelöst“. Wir haben die Codemetriken mind. nach jedem dreiwöchigen Sprint im Team (mit dem Kunden) angeschaut und Massnahmen ergriffen wo notwenig. Gefunden haben wir einiges… Neben klassischen Programmierfehler (z.B. in einer Klasse equals() nicht jedoch hashCode() implementiert) haben wir auch zyklische Abhängigkeiten in Java-Packages entdeckt, welche sich mit der Zeit in einem grösseren Entwicklungsteam einschleichen.

Qualität beginnt auf unterster Stufe und das ist der Code, welcher im Projekt geschrieben wird. Und über die Zeit (z.b. Codebasen, in welchen über mehrere Jahre entwickelt wird) fällt jedes System tendenziell auseinander (siehe zweite Regel der Thermodynamik). Dieser Entropy des Codes kann mit Werkzeugen durchaus etwas entgegengehalten, die Tatsache jedoch nicht aufgehalten werden (nicht umsonst werden Softwaresysteme immer wieder neu geschrieben). Mittels Metriken und Codestyle-Checks lässt sich jedoch eine gute Basis für gesunden Code und die weiteren höherliegenden Qualitäts-Massnahmen legen.

Wer interesse an Sonar hat, kann unter http://nemo.sonarsource.org Beispielprojekte einsehen.

Devoxx. Tag 4. Methodology meets Technology.

Der vierte Konferenztag startete mit einer sehr guten und unterhaltsamen Keynote der beiden Methodik-Koryphäen Ivar Jacobson und Robert C. Martin. Beide, Authoren von Methodik-Bücher, machen eine sehr selbstkritische Rückblende über die vergangenen 40 Jahren Softwareentwicklung, in denen auch sie Methodiken propagiert haben, welche sich letztlich nicht durchgesetzt haben.

Zitat aus dem Vortrag:
„Softwaredevelopment seems to be driven by fashions and fads“

Wie kommt das? Es hat sich gezeigt, dass sich die Universitäten (Forschung) nicht um die Praxis kümmern und dass die Praktiker sich kaum dafür interessieren, was an den Universitäten gearbeitet wird. Hinzu kommt jetzt das Übel der Methodik-Evangelisten, welche stets neue Methodiken „erfinden“, welche bestehendes mehr oder weniger neu verpacken, neu zusammenstellen und nur an unwesentlichen Punkten erweitern. Hier scheinen doch auch Ermüdungserscheinungen da zu sein, immer wieder neue Terminologien zu lernen, obwohl es im wesentlichen nichts neues gibt. Dies hat Ivar Jacobson und 20 anderen Schwergewichte (u.a. Ken Schwaber, Erich Gamma, Scott Ambler, Richard Soley, etc.) dazu bewogen, der Softwareentwicklung ein gutes theoretischen Fundament zu verpassen (welches allerdings erst noch zu finden ist) und hat dabei die SEMAT (Software Engineering Method and Theory) ins Leben gerufen. Ob und wie sich diese Initiative, bei der es zu beginn schwer war, dass sich alle Beteiligten auf den kleinsten gemeinsamen Nenner einigen konnten, durchsetzen resp. Akzeptpunkte bringen kann, wird sich erste noch zeigen.

Robert C. Martins (auch Uncle Bob genannt) Vortrag war eine typisch amerikanische Storytelling Vorstellung, deren Unterhaltunswert sicherlich sehr hoch war, sich inhaltlich jedoch auf ein/zwei Elemente hätte abspecken lassen können. Robert, mit seiner sehr grossen Erfahrung in Sachen Softwareentwicklung, hat die vergangenen 40 Jahre in 10 Jahresabschnitten revu passieren lassen und aufgezeigt, dass sich die wesentlichen Punkte in all denn Jahren nicht verändert haben. Methodiken kamen und gingen, Projekte scheiterten jedoch nach wie vor. Letztendlich appeliert er an die Entwickler, sich wirklich als „Professionals“ zu verhalten. Das heisst für ihn eben auch „Nein“ zu sagen. „Nein“ zu unrealistischen Zeitplänen, „Nein“ zu schnellen Hacks, etc.

Zitat aus seinem Vortrag: „To Go Fast, Go Well“

Und meint damit, dass sich Hacks, etc. aus welchen Gründen auch immer einfach irgendwann rächen, womit er in der Regel ja auch recht hat. Doch wer verstösst nicht ab und zu wieder gegen seine eigene Überzeugung (wegen Budget, wegen Zeit, etc.)…?

Ich denke, beiden haben im Kern ihrer Aussagen und Einschätzungen recht. Welcher Weg zu einer Verbesserung führt, wird sich noch weisen. Vielleicht ein bisschen von beidem… :-) Dass sich jedoch heute eine ganze Keynote nur um das Thema Methodik gedreht hat, zeigt auf, dass hier auch viel Handlungsbedarf besteht.

Ach ja… hier noch kurz was eher technisches… was aber prima in den Cloudcomputing-Hype passt…
Mit Glassfish in der Version 3.0, welche am 10. Dezember released wird, kommt eine sehr gute und schnelle Referenz-Implementierung, für die neue Spezifikation auf den Markt. Neben den vielen neuen API, welche jetzt zur Spezifikation gehören, hat mir vorallem ein Aspekt gefallen: Der Server kann in der neuen Version komplett über REST-API administriert werden. Hier denke ich, dass dies vorallem für künftige Laufzeitumgebungen (z.B. Amazon EC2, o.a.) sehr, sehr hilfreich sein wird.

Devoxx. Tag 2. Intelligence mit Facetten finden.

Der zweite Tag stand unter dem Motto „Facettensuche und Business Intelligence“.

Ein besonders gelungener Vortrag von Erik Hatcher von Lucid Imagination berichtet über Solr, sozusagen eine verbesserte Lucene-Suchengine. Warum verbessert? Nun, Solr basiert im Grunde genommen auf Lucene und erweitert diese in wesentlichen und in meinen Augen wichtigen Bereichen. Die wichtigsten sind hier aufgeführt:
– bietet ein HTTP-basiertes API für die Indexpflege
– eingebautet Caching- und Clustering-Funktionalitäten
– Master-Slave Replikation in sehr grossen Systemen (Americal Online repliziert weltweit solche Indexe und die sind nicht klein…)
– Facettensuche
– Verteilte Suche (für sehr grossen Implementationen)

Das Bauen einer guten Suchapplikation ist nach wie vor eine grosse Herausforderung. Obwohl viele Endanwender immer wieder „Es muss wie Google funktionieren“ sagen, ist es im Detail dann doch etwas komplexer und komplizierter. Erik propagiert in seinem Vortrag folgende Herangehensweise:

1. Gehe immer vom Benutzerfrontend aus

Was heisst das? Nun, zuerst muss klar sein, wie der Benutzer überhaupt die Suche bedienen soll/kann. Welche Möglichkeiten stehen ihm zur Verfügung? Dies hat schon mal einen grossen Einfluss auf die Grundkonfiguration eines Solr-Systems.

2. Anforderungen an den Index sammeln

Was soll denn indexiert werden? Binäre Dokumente wie PDF, Word, etc. Soll die Such case-sensitiv sein oder nicht? Müssen unterschiedliche Sprachen unterstützt werden (Stemming)? Wie oft ändern sich diese Daten?

3. Anforderungen an die Suche sammeln

Hier kommt einiges auch aus dem ersten Punkt dazu. Soll der Benutzer sich eher browsend (via Facetten) oder mit einer strukturierten Suche im System bewegen? Oder beides? Welche Anforderung bestehen bezüglich Sortierung und Filterung? Müssen gewisse Relevanzen (z.B. ältere vs. neuere Dokumente) berücksichtigt werden?

Diese Punkte haben einen enormen Einfluss auf das zu bauende System und sollten möglichst früh adressiert werden im Projekt.

Solr, aktuell in der Version 1.4, kann praktisch an allen Stellen erweitert werden. Das macht das System aus meiner Sicht sehr interessant und wird daher vermutlich längerfristig reine Lucene Implementierungen verdrängen.

Der zweite Vortrag handelt von Java Business Intelligence und dem OpenSource Tool Pentaho.
Matt Casters führt durch Pentaho, mit dem speziellen Fokus auf Pentaho’s Data Integration Komponente Kettle (ein von im initiiertes Open Source Project). Pentaho ist eine Open Source Business Intelligence Implementierung und besteht aus mehrere eigenständige Komponenten:
– Reporting,
– Analysis,
– Dashboards
– Data Integration
– Data Mining

Die Reportingkomponente (ehemals JFreeReport) dient der Erstellung von interaktiven und ad-hoc Reports in verschiedene Ziel-Formate (PDF, HTML, DOC, XSL). Ein Eclipse-basierender Report Designer vereinfacht die Erstellung von Reports. Die Analysis Komponent (mondrian) bietet OLAP (Relational OLAP) Funktionalität. Dashboards bietet eine Plattform für die Erstellung von Dashboards (auch Cockpits genannt), es lasen sich einfach interaktive Dashboards mit integriertem Monitoring of KPI’s erstellen. Sehr interessant ist die Data Integration Komponente Kettle, sie ist eine vollumfängliche ETL-Lösung (Extract Transform). Sie integriert und säubert Data von verschiedenen Quellen und Formate (35+ Datenbank Typen, Flat Files, XML, etc.), die dann in den anderen Tools zur Verfügung stehen. Die ETL Prozesse lassen sich mit Kettl Spoon graphisch erstellen und bearbeiten. Das Data Mining helft Muster in Daten zu erkennen, welche wiederum als Muster bei Kundensegmentierung verwendet werden kann. Alle Komponenten sind Open Source (Reporting und Data Integration LGPL) und lassen sich auch integriert in eigene Lösungen einsetzen.

Ach du schöne Open Source Welt…

Devoxx. Tag 1. Cloudcomputing.

Wie bereits im meinem früheren Post angekündigt, sind verschiedene Vertreter von Namics in Antwerpen an der devoxx. Dabei versuchen wir, die Schwerpunkte des jeweiligen Tages etwas zusammenzufassen und dies in einen Blogeintrag zu giessen. Der erste Tag stand – wie der Titel vielleicht verraten mag – unter dem Themenschwerpunkt Cloudcomputing.

Im ersten Vortrag von John M. Willis wurde das Thema aus historischer Sicht (wobei hier die Historie zum Glück nicht so lang ist) etwas aufgearbeitet. John hat die Geschichte von Gridcomputing zum Cloudcomputing sehr schön zusammengefasst, wobei hier noch angfügt werden muss, dass John ursprünglich aus dem IT Operation kommt. Aus seiner Sicht wurde bereits seit einger Zeit das Agile Manifesto auf die Entwicklung von Software angewandt, jedoch die IT Operation davon komplett aussen vor gelassen wurde. Agil entwicklen ja… aber agil betreiben… lieber nicht oder noch nicht. Agile Operation existiert in den Firmen eigentlich noch gar nicht. Ein witziges Beispiel hier war die eines Pharmakonzerns, in dem die Forschungsabteilung kurzfristig massive Rechenpower benötigt hätte, dessen Beschaffung intern jedoch 8 Wochen gedauert hätte. Was haben die Forscher gemacht? Sie haben sich die Rechenpower einfach bei Amazon EC2 mit ihrer persönlichen Kreditkarte innerhalb von 8 Minuten beschafft. Und dass der Markt dies fordert und wünscht, zeigen die Zahlen von Amazon auf eindrückliche Art und Weise (bis zu 200’000 neue Instanzen werden pro Tag eingerichtet und gestartet), alles vollautomatisch und via Webservices gesteuert. Agile Operation – dass soll jetzt Cloudcomputing richten. Wo nur bleibt dann da das Agile Budgeting?

Im zweiten Vortrag erklärte Chris Richardson, wie robuste Applikationen für die Amazon EC2 gebaut werden können. Er führte anhand eines Beispiels Applikation durch die unterschiedlichen Services der EC2. Elastic IP Addresses in Kombination mit Elastic Loadbalancer und Autoscaling und die verschiedene Zonen führen zu einem hochverfügbarem System (99.95%). Die S3 Datastore, die Simple Query Service (SQS) bietet mit dem Cloudfront eine effiziente globale Content Delivery Infrastruktur. Amazon implementiert die volle Pallette einer sogenannten Infrastructure as a Service (IaaS). Der nächste Layer wäre eine Platform as a Service (PaaS). Diese wird von cloudfoundry.com als Layer auf einer EC2 geboten. Es lassen sich Spring und Grails Applikationen direkt in der Amazon Cloud deployen. Aktuell wird dieser Layer auch auf die hauseigene vCloud portiert. Auch wenn es noch einige Einschränkungen in der Entwicklung von Cloud Applikationen gibt, sieht das ganze sehr erfolgversprechend aus. Die Preismodelle von EC2 sind jedoch genau so durchsichtig (oder eben nicht) wie die bei einem Mobiltelefon, was das Durchrechnen eines konkreten Business-Cases erschwert.

Es bleibt also spannend… über oder besser gesagt in den Wolken… :-)

Continuous Integration – aber nicht in SharePoint-Projekten… oder?

Aktuell bin ich auf dem Weg nach Antwerpen, wo jedes Jahr eine der wichtigsten Konferenzen im Java-Umfeld stattfindet. Die devoxx (f.k.a javapolis). Da die Wartezeiten auf so einer Reise nicht unerheblich sind, wollte ich diese Nutzen, um von einem weiteren Meilenstein bei Namics zu berichten.

Anlass dazu hat mir der Post von Markus bezüglich Maven gegeben. Wie Markus auch berichtet hat, ist Maven bei Namics nicht mehr aus den Projekten wegzudenken. Zu wichtig ist ein gut strukturierter Buildprozess in einem grösseren Projekt. Die Unabhängigkeit von einer Entwicklermaschine oder von einer Entwicklungsumgebung wie Eclipse ist unerlässlich.

Das ist jedoch nur ein Aspekt im gesamten Entwicklungszyklus. Ein anderer, ebenso wichtiger Aspekt ist die Buildfähigkeit eines Projektes über die Zeit. Wie kann die Dynamik in einer grossen Source-Code-Basis über Monate oder gar Jahre überwacht werden? Das Zauberwort hier heisst Continous Integration. Mit diesem Begriff wird eine Infrastruktur assoziiert, welche es erlaubt, ereignissgesteuert (z.B. zeitlich oder manuell) die gesamte Codebasis eines Projektes aus dem Sourcecodeverwaltungssystem auszuchecken und anschliessend zu bauen. Am Ende sollte hinten ein installationsfähiges Stück Software herausfallen.

Als Atlassian Partner setzten wir bei uns intern auf Bamboo, welcher genau diese Funktion ausübt. Bislang haben wir diese Infrastruktur allerdings ausschliesslich für Java-Projekte eingesetzt. Das wird sich jetzt jedoch künftig ändern, da seit der aktuellen Version von Bamboo auch eine Möglichkeit besteht, SharePoint-Projekte mittels MSBuild zu bauen und so über die Zeit zu überwachen. Jeder der schon mal grössere SharePoint-Projekte implementiert hat, weiss jedoch, dass sich hier viele Fallestricke und Tücken verstecken. Mit diesen setzen wir uns aktuell auseinander. Ziel ist es, künftig auch grosse SharePoint-Projekte mit dieser Infrastratur automatisiert zu bauen. Bei einem ersten Musterprojekt ist es uns auch bereits gelungen. Aber eben… wie gesagt, vielleicht haben wir auch noch nicht alle Falltüren geöffnet… :-) Aber es ist ein weiterer wichtiger Schritt aus Sicht der Qualitätssicherung…

So… bald geht der Flieger in Richtung Amsterdam… hoffe, ich habe keine Verspätung… sonst erwische ich den Zug nach Antwerpen dann nicht mehr… :-)

Geld will verdient sein!

Ja, Geld will verdient sein. Dies gilt insbesondere dann, wenn sich die Firma im Opensource-Umfeld bewegt. Eine solche Firma ist seit einiger Zeit auch SpringSource, die Firma, die hinter dem bekannten und gleichnamigen Spring-Framework steht. Opensource wird primär mal als „keine Lizenzkosten“ wahrgenommen – wobei man sich ab und zu doch auch die Lizenzbedingungen anschauen sollte. Aber egal, die Frage bleibt:

„Wie verdienen Firmen, die ein Produkt haben das nix kostet, ihr Geld?“

Das habe ich mich natürlich auch bei SpringSource gefragt. Die Firma hat ja mittlerweile eine stattliche Grösse mit über 100 Mitarbeiter, die auf der Gehaltsliste stehen und jeden Monat ihren Lohn auf dem Bankkonto sehen möchten.
Eine erste Antwort bietet die Website an. Neben den üblichen verdächtigen unter dem Menüpunkt Services (Consulting, Training, etc.) gibt es seit Anfang Jahr ein „Produkt“ namens SpringSource Enterprise. Was das alles umfasst, kann unter obigem Link nachgelesen werden. Was mich aber etwas stuzig gemacht hat, sind die Punkte unter „Spring Enterprise Edition“. Dort stehen Dinge wie „QA tested“, „Enterprise-class features“ und eben „Regular maintenance releases with latest bug fixes“…
Hmm, was genau unterscheiden diese Punkte vom Opensource Produkt? Und was genau bedeutet der letzte Punkt?
Das wollte ich doch genauer wissen und habe bei einer Gelegenheit mal einen Mitarbeiter von SpringSource danach gefragt. Die Antwort war: „Jeder Kunde bekommt ein eigenes Subversion-Repository, in welchem Bugs schneller gefixt werden, als im Opensource-Teil“… Meine spontane Reaktion: „Hoffentlich habt ihr nicht zuviele Kunden und/oder Bugs…“. Denn mittlerweile ist Spring mit all seinen Teilframeworks sicherlich ein paar Millionen Codezeilen gross. Und der Unterhalt einer solchen Codebasis ist definitiv nicht einfach.

Nun ja, ich bin gespannt, wie der Markt das aufnimmt und ob die Dienstleistung angenommen wird. Denn obwohl SpringSource mittlerweile eine zweite Finanzspritze mittels Venture Capital bekommen hat, wollen die Geldgeber am ende des Tages dann doch das Geld wieder sehen… eben – Geld will verdient sein!

Spring auf allen Ebenen

Vor ziemlich genau fünf Jahren bin ich zum ersten Mal mit Spring (damals noch Interface21 auch in den Packagenamen) in Kontakt gekommen. Damals noch ein ziemlich unbeschriebenes Blatt hatte Spring in Kunden-evaluationen /-situationen kaum eine Chance gegen Struts. Da musste man schon fast einen Liebhaber von „progressiven“ Neuerungen auf der Gegenseite haben, um von Struts wegzukommen. Wie auch Struts war Spring damals vorallem auf die serverseitige Webprogrammierung ausgerichtet – um einiges besser schon damals als Struts aber auch um einiges unbekannter… :-)
Während bei Struts das „Benzin“ ausging und seid damals keine wirklich nennenswerte Neuentwicklung mehr zustande kam, ging bei Spring so richtig die Post ab. Die drei Standbeine „dependency injection“ mit Bean-Container, „portable service abstraction“ für die Abstraktion der diversen Java-API’s und Unterstützung von aspektorientierter Programmierung wurden schnell ziemlich gut ausgebaut und in den neuesten Versionen mit Möglichkeiten von AspectJ und Annotationen ergänzt. Damit hat sich Spring serverseitig im Markt behaupten können, erleichtert täglich dem Entwickler vieles und ist heute Quasi-Standard im Enterprise Java-Markt.

… und alles wurde gut… wohlgemerkt, serverseitig… wenn da nicht der Client wäre… :-)

Ich habe mich ehrlicherweise bislang nie so richtig wohl gefühlt im Html-, CSS- und JavaScript-Dschungel… zu unstrukturiert und launisch war mir diese Welt. Die unterschiedlichen Browser und ihre Eigenheiten haben das ihrige dazu beigetragen. Seid 2005 und der „neuen alten“ Technologie AJAX und dem Buzzword Web 2.0 hat sich jedoch einiges verändert. Der Client ist nicht mehr als reine Anzeigemaschinerie da sondern erhält – je nach Gewichtung – immer wie mehr Logik (Stichwort hier RIA). Und ein neuer riesiger Zoo von AJAX-Frameworks war die Folge. Ich mag sie gar nicht erwähnen, so viele sind es mittlerweile (auch sehr gute, keine Frage).

Glücklicherweise hat dies auch Springsource erkannt und hat ihr altbewährtes „portable service abstraction“-Prinzip nun bis auf den Client ausgebreitet. Was bedeutet das? Nun, ganz einfach. Ich erhalte als Entwickler ein einheitliches clientseitiges Prgrammiermodel mit dem ich arbeiten kann. Ich muss mich nicht mit Dojo oder JQuery Eigenheiten auskennen sondern es reicht, wenn ich das SpringJS-API kenne. Schematisch sieht das folgendermassen aus:

i-702f1bc30705fdf214bd9df2649727a6-springjs.png

Als erste Bridge und Implementierung wird Dojo unterstützt. Als weitere Bridge geplant ist zudem JQuery. Damit sind sicher die aktuell am meist verbreiteten JavaScript-Libraries unterstützt.
Mit SpringJS wird die HTML-Seite mit „progressivem“ JavaScript ergänzt… was heisst, die Funktionalität ist auch dann gewährleistet, wenn der Client JavaScript ausgeschaltet hat. Das fühlt sich dann ungefähr so an:

i-3b9791742f332229703515e773ee0239-springjs_ex.png

Die HTML-Elemente werden mit sogenannten Dekorationen (siehe Decoration-Pattern) erweitert. Im Beispiel wird einfach ein OnClick-Handler dem Html-Element findFormUrl „hinzugefügt“.

So einfach… oder? Und das ganze portabel… hoffentlich… :-)

OSGi – Eine Technologie wird (endlich) erwachsen

Es ist aus… ja… die Schweiz hat ihr zweites EM-Gruppenspiel gegen die Türkei verloren…!! Ich sitze hier in Antwerpen an der SpringOne 2008 und habe mit der Schweizer Nati mitgefiebert… in einem irischen Pup… mit belgischem Bier und gefüllt mit türkischen Fans… vergebens… na ja… das musste ich einfach kurz loswerden, bevor es zum eigentlich Thema geht…

Ja… wie bereits gesagt… ich bin momentan in Antwerpen, Belgien. Hier findet zum dritten Mal die SpringOne in den Räumlichkeiten der Metropolis statt. Und das – vermutlich – zum letzten Mal, wie ich vernommen habe… was nicht allzu schlecht ist, denn Antwerpen ist rein reisetechnisch wirklich nicht gerade gut zu erreichen… Locations gäbe es sicherlich optimalere… Amsterdam ist im Gespräch… aber das sind nur Gerüchte… :-)

Der heutige Tag stand bei mir hauptsächlich unter dem Thema OSGi. Eigentlich kaum zu glauben, wie lange es dauert, bis eine Technologie sich am Markt beginnt durchzusetzen. Insbesondere dann, wenn keine wirklich grosse Marketing-Maschinerie a la Microsoft vorhanden ist und es sich erst noch um eine Spezifikation handelt. Aber – und das sage ich immer wieder – gute Technologie setzt sich auf lange Sicht hin durch.

Was eigentlich vor beinahe 10 Jahren!! in einer Art Allianz behonnen hat, ist erst im Jahre 2008 in der Web-Applikationsentwicklung angekommen. Schade eigentlich, denn OSGi hilft bei einigen grundlegenden Problemen wie Versionierung von Java-Typen enorm. Nun denn, mit der SpringSource Application Plattform steht nun erstmals eine serverseitige OSGi-Infrastruktur zur Verfügung, um Webapplikationen zu entwickeln und als Bundles zu deployen.

OSGi zu Fuss ist hart. Das API ist sehr low-level und erinnert mich irgendwie an JDBC und andere low-level API’s. Spring-sei-Dank oder Dank Spring Dynamic Modules, welches Costin Leau von SpringSource in einem eigenständigen Vortrag beleuchtet hat, ist es mir als Entwickler jedoch sehr einfach möglich, OSGi-Bundles und Services zu entwicklen, ohne dass ich mich um diese technologischen Details zu kümmern brauche.

Ok… mit OSGi löse ich keine bislang ungelösten Business-Probleme… aber es löst mir einige engineering-technische Probleme, welches die Wartung (was in der Regel immerhin der grössere Teil der Gesamt-Projektkosten ausmacht) eines Softwaresystems erheblich erleichtert.

2008 wird nicht das Jahr der Schweizer Nati… aber das Jahr von OSGi… ganz sicher… :-)

Seite 1 von 212