Open Source?

Marc Fleury von JBoss hat sich hier über seine Ideen bezüglich Open Source ausgelassen. Meiner Meinung nach muss eine Bewertung von Open Source aus der Kunden-Perspektive kommen. Welche Lizenz bringt für ihn den meisten Nutzen? Bei LGPL/GPL hat er das Problem, dass er Modifikationen frei geben muss, was ihn wegen der Schwierigkeiten, dies tatsächlich umzusetzen und auch garantiert durchzuhalten, abschrecken kann. Fleury hat hier recht, dass dies aus Anbieter-Sicht eine schlechte Idee ist, aber es geht eben um Kunden. Bei BSD oder Apache gibt es dieses Problem nicht. Daher werden Kunden es bevorzugen.

Fleury äußert weiter, dass er das veröffentlichen von Sachen z.B. durch BEA nicht gut findet, weil es eine Art Umweltverschmutzung ist. Ich kann das nicht nachvollziehen. Wenn die Sachen weiter entwickelt werden, sorgen die Sourcen dafür, dass meine Investition besser abgesichert ist und das Suchen von Fehlern erleichtert wird. Wenn es nicht weiterentwickelt wird: Was soll man dann damit tun? Wegwerfen? Und die Sourcen wegschließen? Ist das besser?

Wenn wir bei Kunden-Orientierung sind: Es ist sicher nicht für Kunden schön, wenn JBoss versucht, Trainer-Anbieter aus Markenrechtsgründen abmahnt. Auch der Markt für Dienstleistungen sollte offen sein. Hier Markenrecht heranzuziehen, bedeutet, dass JBoss genau hier keine Kunden-Orientierung und keinen Wettbewerb will.

Schauen wir mal, wie es weitergeht. IBM mit Geronimo Community Edition ist sicher spannend. Und ich würde auch gerne mal einen Total-Cost-Of-Ownership für Application Server von BEA, IBM und JBoss sehen, die auch die Service-Kosten berücksichtigen.  ¶ 12:45 0 comments

  Spring 2.0 / Buch Release Party am Do., 30.03.06 in Stuttgart

Am Do., 30.03.06 ist in Stuttgart die Release Party für Spring 2.0 und mein Buch statt. Die Teilnehmer haben die Chance, mehrere Buchgutscheine mein
im April im dpunkt.verlag erscheinende Buch
über Spring zu gewinnen.

Programm (Details siehe weiter unten):

14:00 Eberhard Wolff: Spring - Das neue Java EE?
15:00 Torsten Jürgeleit, Christian Dupuis: Spring-IDE
16:30 Wolfgang Wopperer: JSF-Spring
17:30 Jürgen Höller: Neues in Spring 2.0
19:00-openend Party und CodeCamp

Kosten: EUR 50.- (bar vor Ort, mehrwertsteuerfrei).

Anmeldung: bitte melden Sie sich per Mail an spring@jugs.org mit
vollständigen Kontaktdaten an.
Die Teilnehmerzahl ist auf 100 Personen begrenzt.
Beim CodeCamp am Abend ist aus räumlichen Gründen die
Teilnehmerzahl auf 50 Personen begrenzt. Bitte geben Sie bei
der Anmeldung mit an, ob Sie auch am CodeCamp teilnehmen werden.
Die Plätze für das CodeCamp werden in der Reihenfolge der
Anmeldungen vergeben. Falls das CodeCamp ausgebucht sein
wird, können Sie abends trotzdem gerne an der Party teilnehmen.

Ort: Alte Scheuer (Agnes-Kneher-Platz)
Große Falterstraße 11
70597 Stuttgart-Degerloch
Anfahrt siehe JUGS-Website

Bei Fragen inhaltlicher oder organisatorischer Art wenden
Sie sich bitte an Dr. Frank Gerhardt (fg@jugs.org).

Das Programm im Detail:

14:00 Eberhard Wolff: Spring - Das neue Java EE?

Spring ist ein neuer Ansatz für die Entwicklung von Java-
Anwendungen. Es stellt statt der unnötigen Komplexität des
Java-EE-Programmiermodells POJOs (Plain Old Java Objects)
in den Mittelpunkt, was eine Refokussierung auf bewährte
objektorientierte Prinzipien erlaubt. Dabei kommt Dependency
Injection zum Aufbau von Objektnetzen zum Einsatz und AOP
als Basis für die Implementierung von Features wie Sicherheit
oder Transaktionen. Gleichzeitig wird für viele bekannte
Java-APIs eine vereinfachende Abstraktionsschicht angeboten.

Eberhard Wolff Chef-Architekt bei der Saxonia Systems AG.
Hauptsächlich beschäftigt er sich mit Java-Server-Anwendungen
mit Java EE und Spring. Er ist einer von weltweit 20
Gründungsmitgliedern der Java Champions.

15:00 Torsten Jürgeleit, Christian Dupuis: Agile Spring-
Entwicklung mit der Spring IDE (http://springide.org)

Während der Einführung von Spring innerhalb großer Entwicklungs-
projekte wird häufig bemerkt, dass die Komplexität der Spring-
Konfigurationsdateien mit zunehmender Projektdauer steigt und
die Konfigurations-Artefakte unübersichtlich und umständlich zu
warten sind. Durch die Einbindung entsprechender Tools in
Eclipse vereinfacht die Spring IDE das Erstellen und Verwalten
von Spring Konfigurationsdateien. Spring IDE bietet Validierungs-
mechamismen, einen XML-Editor und Tools zur grafischen
Darstellung von Spring Beans und deren Abhängigkeiten. Der
Vortrag gibt eine Einführung in den Funktionsumfang der Spring
IDE sowie einen Einblick in das Projekt und die kommenden
Features.

Torsten Jürgeleit ist seit seinem Studienabschluss 1992 als
Diplom-Informatiker (FH) im Bankenbereich tätig. Dabei liegt
sein Themenschwerpunkt im Bereich Java-basierter Bank-
applikationen im Internetumfeld. Seit 3 Jahren ist er bei der
DekaBank beschäftigt. Hier wirkt er als Technischer Architekt
an B2C / B2B-Lösungen mit.
Torsten ist Gründer des Open-Source-Projekts "Spring IDE".

Christian Dupuis ist seit 2002 bei Accenture angestellt und
Mitglied der "Technical Architecture Capability Group" innerhalb
des Unternehmensbereichs "Financial Services". Als Technischer
Architekt beschäftigt Christian sich mit dem Design und der
Implementierung von unternehmenskritischen Anwendungen auf
Basis von Spring in der Finanz- und Versicherungs-Branche.
Christian ist Co-Lead des Open-Source-Projekts "Spring IDE".

16:00 Pause

16:30 Wolfgang Wopperer: JSF-Spring

Der Vortrag gibt einen Überblick über das Open-Source-Projekt
JSF-Spring, das eine weitreichende Integration von JSF und Spring
bietet. Nach einer kurzen Einführung in JSF wird das Konzept von
JSF-Spring vorgestellt. Danach werden anhand konkreter Beispiele
die Benutzung und die wichtigsten Features von JSF-Spring er-
läutert und deren Nutzen für die Entwicklung von Webapplikationen
verdeutlicht.

Wolfgang Wopperer ist Mitgründer und Gesellschafter des Hamburger
Softwarehauses mindmatters, das seit 2004 federführend JSF-Spring
entwickelt.

17:30 Jürgen Höller: Neues in Spring 2.0

Gutes kann noch besser werden: In der Version 2.0 des Spring-
Frameworks kommen zahlreiche Features und Enhancements auf Basis
des bestehenden Cores hinzu. Die neue Schema-Variante für XML-
Konfiguration bietet Erweiterbarkeit über Namespaces, wobei viele
Convenience-Tags bereits mitgeliefert werden.
Im AOP-Bereich wird nun AspectJ auf verschiedenen Ebenen direkt
unterstützt. Neue Bereiche werden mit Message-Driven POJOs,
Portlet-Support und JPA-Support erschlossen. Der Vortrag gibt
einen Überblick über die neuen Möglichkeiten, direkt vom Lead-
Entwickler.

Jürgen Höller ist Mitbegründer von Interface21, einem inter-
nationalen Consulting-Unternehmen mit Sitz in London. Seit der
Gründung des "Spring Framework"-Projekts ist er als Lead-
Entwickler und Release-Manager involviert. Er ist Co-Autor von
"J2EE Development without EJB" und "Java Development with the
Spring Framework".

19:00 - openend: Party und CodeCamp

Im Anschluss an die Vorträge wollen wir den Abend gemütlich
ausklingen lassen. Dazu lassen wir weniger die Puppen tanzen,
sondern bieten vielmehr die Möglichkeit auf selbst mitgebrachten
Laptops kräftig in die Tasten zu greifen. Wenn Sie nicht hacken
möchten, können Sie auch da bleiben, um sich mit den Spring-
Experten zu unterhalten. Jürgen Höller, Eberhard Wolff und das
Spring-IDE-Team werden den ganzen Abend anwesend sein.
Machen Sie Ihre ersten Schritte mit Spring, oder bringen Sie
ein kniffliges Problem aus Ihrem Spring-Projekt mit! Haben
Sie vielleicht Lust an einem der Open-Source-Projekte mitzuwirken?
Finden Sie hier den Einstieg!
Für Verpflegung und Getränke ist den ganzen Abend gesorgt.  ¶ 18:20 0 comments

  Das Home Interface ist das Problem!

Ich habe mit Markus Völter zusammen eine Folge für SE Radio aufgenommen. Darin ging es um unser Buch über Server Component Patterns. In dem Buch haben wir 2002 beschrieben, welche Patterns in einer Middleware wie EJB implementiert sind. Die Patterns haben wir im Lichte aktueller Technologien wie zum Beispiel Spring für den Podcast besprochen.

Ein interessantes Ergebnis: Das Home Interface ist ein Anti-Pattern. Für Session Beans ist es überflüssig, da man die Session Beans direkt im Namenssystem JNDI hinterlegen könnte. Bei Stateful Session Beans würde das zwar zu einer Einschränkung auf eine einzige Instanz führen, aber das sollte keine echte Einschränkung sein, da sowieso nur eine Session zur Zeit aktiv sein sollte. Bei Entity Beans zeigt es sogar das grundlegende Problem mit Entity Beans: Wenn man das Home Interface selbst zu einer Komponente gemacht hätte, wäre man bei Session Bean + Data Transfer Objects, was sich bewährt hat, beziehungsweise bei einem DAO Pattern. Also ist hier das Home Interface sogar ein Hinweis auf das grundlegende Problem mit Entity Beans.  ¶ 09:13 0 comments

  RoR not done yet?

Hier gibt es einen spannende Antwort auf Bruce Tates These, dass Java de factor tod sei. Es sind zwei Dinge, die erwähnt werden: Die Standards, die bei Ruby nie im Leben in Sicht sind. Das ist sicher richtig und man darf eben nicht übersehen, dass SAP, Sun, IBM, BEA und so weiter alle hinter Java stehen, weil es eben ein Standard ist. Zum anderen wird die These aufgestellt, dass es keine produktionsreife Umgebung gibt, in die man das deployen kann. lighttpd mit FastCGI oder apache mit mod_ruby oder fastCGI werden unterstützt. Das erste soll angeblich instabil sein, das zweite wird angeblich nicht mehr weiterentwickelt. Wenn das so ist, sind die RoR Leute wirklich cool. Reiner Hype ohne Produktionsumgebung. Ich kann das eigentlich nicht glauben. Das lustige ist, dass niemand im Thread widerspricht.  ¶ 19:39 1 comments

  Noch ein Klassiker stirbt

Nach der Borland-Nachricht gestern kommt es heute ein wenig schlimmer: SGI sagt hier, dass es ihnen so schlecht geht, dass sie alles tun würden, um zu überleben. Schade. War mal eine tolle Firma mit coolen Rechnern. Na ja, auch hier: Wenn man stehen bleibt, hat man ein Problem. NVidia ist ja anscheinend von Ex-SGIlern gegründet worden, wäre also eine Möglichkeit für SGI gewesen....  ¶ 11:03 0 comments

  Borland verkauft

Die Nachricht des Tages ist der Verkauf des Geschäfts mit Entwicklungs-Umgebungen bei Borland. Die Nachricht findet sich hier und hier. Ein Kommentar gibt es hier auch schon. Nachdem ich früher für diese Firma gearbeitet habe, bin ich von der Sache natürlich schon berührt.

In gewisser Weise ist der Schritt richtig. Eclipse hat den gesamten Java-IDE Markt für sich eingenommen hat und eigentlich gibt es sonst nur noch intelliJ. Dort hätte JBuilder sein müssen, wenn dieses Produkt dauerhaft hätte überleben sollen. Das ganze ist eine Folge des Schritts, Eclipse zu Open-Source zu machen, mit dem IBM eigentlich Microsoft treffen wollte.

Im Delphi-Bereich fehlt mir die Übersicht, aber dort scheint es in letzter Zeit auch nicht so gut zu laufen und vor allem konkurriert man dort mit Microsoft.

Mit dem Fokus auf Application Lifecycle Management steht Borland nun vor einer interessanten Herausforderung. Dieses Geschäft ist völlig anders als der Verkauf von IDEs an Entwickler oder Einzelpersonen. Auch die Marke Borland ist hier eher hinderlich, weil sie eben für einfache IDEs steht und nicht für Enterprise-Lösungen. Konkurrenten sind zum Beispiel Rational, die durch den IBM Hintergrund sicher ganz anders aufgestellt sind.

Fazit: Ein konsequenter Schritt, eine sinnvolle Maßnahme, eher überfällig. Wenn man sentimental ist, würde man es schade finden, aber eigentlich war es zu lange abzusehen. Obwohl es ein richtiger Schritt ist, bin ich nicht überzeugt, dass Borland damit wieder auf der Gewinner-Straße steht. Es kann ein richtiger Schritt sein, aber danach muss es dann noch weitere geben.

Interessant ist der Vergleich zu IBM, die auch gerade die einstige Kernsparte mit dem Bau von PCs und Notebooks verkauft haben. Bei IBM ist allerdings klar zu sehen, wie es weitergehen soll: Eben mit Services, Consulting und den anderen Umsatzbringern wie Mainframes. Bei Borland gab es aber eine solche substantielle Veränderung nicht. Das zeigt, was passiert, wenn man stehen bleibt. Böse Zungen könnten behaupten, dass das Problem schon mit dem Weggang von Anders Hejlsberg begonnen hat.....  ¶ 13:48 0 comments

  Alternative zu XML für Spring-Konfiguration

Die XML-Konfiguration von Spring ist in der Praxis aus meiner Sicht eine gute Idee und wird zum Beispiel durch Spring IDE auch gut unterstützt. Dennoch fühlt es sich für einen Software-Entwickler einfach falsch an, wenn man solche Sachen nicht in Java schreibt, sondern in XML. Vor allem hat man bei Java Type-Checking und Code-Completation umsonst. Eine recht interessante Idee, wie man das realisieren kann, findet sich hier im Blog von Matthias Ernst. Vielleicht eine gute Erweiterung zum Spring-Framework...  ¶ 09:27 4 comments

  Spring und EJB3

Wie schon erwähnt, hat EJB 3 einige Probleme wie zum Beispiel die Begrenzung von Dependency Injection auf EJBs oder die ungenügende Unterstützung für AOP. In diesem Beitrag wird gezeigt, wie man mit Spring 2.0 einen EJB 3.0 Enterprise JavaBean gleichzeitig durch Spring konfigurieren lässt und vor allem wurde praktisch ausprobiert, ob es tatsächlich geht. Damit kann man also einen "Zwitter" bauen, der ein EJB 3.0 Enterprise JavaBean ist und ein Spring-Bean. Der nächste Schritt ist dann, die EJB 3 Annotationen, die sonst zu Konfiguration im Source Code führen können, durch AspectJ in eine externe Konfiguration in einem Aspekt unterzubringen. AspectJ kann nämlich eine Java Klasse im Nachhinein noch um Annotationen ergänzen. Dann ist man endlich bei einem echten POJO Modell, bei dem Dependency Injection nicht durch Annotationen im Code konfiguriert wird sondern durch eine Spring-Konfiguration und auch der Rest extern gehalten werden kann. Die Vermischung von Konfiguration und Source Code ist nämlich leider eine Unart, die XDoclet eingeführt hat und EJB 3 übernommen hat.  ¶ 22:24 0 comments

  I don't get Spring: Ich bin enttäuscht

Hier kann man einen Link auf einen Blog finden, in dem der Autor sich darüber auslässt, dass Spring keine gute Idee ist. An dieser Stelle muss ich Ramstein zitierten: "Ich bin enttäuscht. Total enttäuscht." Worauf ich warte, ist eine fundierte Kritik an Spring, denn auch Spring wird nicht das letzte Framework sein. Und wenn man die Schwächen kennt, kann man anfangen Verbesserungen zu erarbeiten. Der vorliegende Artikel ist aber leider keine Basis dafür:

• J2EE ist nicht schlecht. Es ist eine gute Basis für Enterprise Anwendungen. Spring ist eine Abstraktion über J2EE. Daher gibt es eher Synergien zwischen J2EE und Spring als einen Gegensatz. Entsprechend ist es auch nicht richtig, dass Spring Leute bzgl. J2EE hochnäsig sind.


• Die JavaDocs sind sehr tatsächlich ausführlich. Meiner Erfahrung nach ist das aber ein Feature. Man findet praktisch immer eine Antwort auf ein Problem in den JavaDocs. Da sie in der IDE integriert sind, ist das ein wirklicher Vorteil. Man bekommt auch Antworten auf Fragen wie "Wo wird Transaktions-Verschachtelung unterstützt?" und das recht schnell.


• Ja, die Spring-Konfiguration ist Spring-spezifisch. Darum geht es aber nicht. Es geht darum, dass der Java-Code unabhängig von Spring ist. Dadurch ist eine Wiederverwendung auch ohne Spring machbar. Eine von der Dependency Injection Implementierung unabhängige Dependency Injection Konfiguration gibt es auch nicht.


• Die Abhängigkeiten werden per Spring IDE zur Entwicklungs-Zeit gecheckt und sonst (meistens) beim Startup der Anwendung. In der Praxis ist das Typisierungsthema keins. Und wenn man typsicher sein kann, kann man auch Autowiring nach Typ benutzen. Außerdem ist Java auch nicht so typsicher, zumindest <1.5.


• Nein, man schreibt nie eine ID eines Spring-Objekts im Code. Weil Dependency Injection überall hinreicht. Auch in die GUI, Web-Layer usw. Die Vermutung, dass man Spring Bean IDs oft im Code benötigt, ist einfach realitätsfremd. Es gibt ganz wenige Ausnahmen (EJB 2 Wrapper für Spring zum Beispiel).

Und so weiter.

Was ich vor allem Schade finde: Spring hat 3 Elemente: Dependency Injection, AOP und die API-Abstraktion. Wer Dependency Injection nicht mag oder die Spring Implementierung nicht mag, soll halt was anderes nutzen. Der Rest von Spring kann dann immer noch verwendet werden. Im Blog geht es aber nur um Dependency Injection und dann auch nur darum, dass die Spring Version von Dependency Injection angeblich nichts taugt (wie übrigens angeblich auch die von Pico Container nichts taugt). Ich bin nicht dieser Meinung, aber selbst dann kann man den Rest von Spring trotzdem verwenden. Und wer z.B. JMS oder JDBC ohne Spring verwendet, macht sich einfach unnötig das Leben schwer.

Fazit: Sehr schade. Ich bin auf der Suche nach wirklichen Problemen mit Spring. Nur dadurch kann ein Framework wachsen, denn wenn die Probleme bekannt sind, kann man anfangen, sie zu beseitigen. Dieser Blog-Eintrag hilft leider nicht weiter.  ¶ 15:30 0 comments