J and I and Me

Meine völlig subjektiven Eindrücke von Ubuntu

2009-11-08T19:58:00.007+01:00

Ich habe in der letzten Zeit ein wenig mit Ubuntu Linux auf verschiedenen eee PCs herumexperimentiert. Die Erkenntnisse, die ich dabei gewonnen habe, würde ich gerne hier der geneigten Öffentlichkeit mitteilen. Vorab folgendens:

Ich bin ein Mac User. Nicht aus ideologischer Überzeugung, sondern weil ich mit Macs am besten zurecht komme und sie NeXTstep am meisten ähneln, womit ich vorher gearbeitet habe.

Ich habe mit Linux schon 1992 oder 1993 angefangen zu experimentieren, damals in 0.96. Davor habe ich auch schon mit Coherent herumgebastelt. Ich habe sogar Geld als Linux-Admin verdient. Ich bin also kein Neuling und wünsche Linux alles erdenklich Gute. Außerdem arbeite ich selber bei einer Open-Source-Firma.

Fangen wir an mit der Installation von Ubuntu Netbook Remix (UNR) 9.04 auf eine eeePC 701. Das ist der ursprünglich eeePC, noch mit Xandros Linux. Den wollte ich auf UNR umrüsten, weil das für mich gegenüber Xandros die bessere Alternative ist. Ein Grund ist der große Verbreitungsgrad von UNR und das bessere Software-Angebot. Außerdem zweifel ich, dass das Xandros langfristig weiter unterstützt wird. Die Installation von UNR war auch einfach. Am Ende hat man einen einfach zu bedienenden Rechner mit einem schönen Menü, der jede Menge aktuelle Software hat. Nur benutzen kann man ihn nicht. Das Menü ist mit grafischen Animationen verziert. Der eeePC ist nicht dazu in der Lage, diese schnell genug anzuzeigen, so dass die Oberfläche tatsächlich fast nicht benutzbar ist. Das ist erstaunlich, denn zuvor hatte ich auf dem Rechner schon mal viele lustige Grafik-Effekte mit der Linux-Distribution am Laufen, die heute easypeasy heißt. Die Lösung findet man nach eine Suche im Netz zum Beispiel hier. Es fehlt lediglich eine Zeile in einer Konfigurationsdatei. Erfahrung hier: Tolle Software-Auswahl, tolles Menü, aber auf dem eee PC 701 kein Plug and Play. Ein "normaler" Anwender hätte das Handtuch geworfen, weil es schlicht nicht ordentlich funktioniert - und das auf dem Rechner, der sehr lange bei Amazon der am besten verkaufte Laptop war.

Auf meinen neuen eee PC 1011HA sollte Ubuntu Desktop 9.10 drauf, obwohl der Test in der c't dem 1011HA eine schlechte Linux-Kompatibilität bescheinigt hat. Mit 9.10 funktionieren WLAN und Netz problemlos, während 9.04 hier noch Probleme machte. Ich habe noch in der Beta-Phase von 9.10 einige Releases installiert. Problem ist die Grafik, aber dank diesem Thread aus dem Ubuntu-Forum ein lösbares Problem. Allerdings hat irgendein Beta-Update dann den Installation des Grafik-Treibers kaputt gemacht, so dass ich dann neu installieren musste. Allerdings habe ich Fedora 11 ausprobiert, um auch mal davon einen Eindruck zu bekommen. Auch bei Fedora muss man den Grafik-Treiber nachinstallieren, eine Anleitung gibt es hier. Fedora funktioniert gut, aber mir persönlich gefällt die Oberfläche von Ubuntu besser und auch der Package-Manager von Ubuntu ist eher mein Fall. Außerdem gibt es mit Ubuntu One auch einen Service, um 2GB Daten auf einem Server kostenlos zu parken, was Fedora nicht bietet. Keine großen Themen, aber insgesamt bin ich dann wieder zu Ubuntu gewechselt, nachdem 9.10 Release draußen war. Erstaunlicherweise funktioniert fast alles - Hibernate, Suspend, Sound, Grafik, WebCam - bis auf das interne Mikro. Ein externes geht, wenn auch verrauscht. Skype und VMware Player sind ebenfalls leicht nachinstallierbar.

Was mich wirklich wundert ist allerdings, dass einige Ubuntu Packages einfach nicht funktionieren. eToys funktioniert schlicht nicht und dazu gibt es auch einen Bug-Report. Dabei startet das Programm noch nicht einmal. Ebenfalls habe ich sugar nicht zum Laufen gebracht - die Oberfläche des OLPC (One Laptop Per Child)-Projekts. Hier mag es sein, dass ich etwas falsch gemacht habe, aber es gibt auch dort einen Bug-Report, der besagt, dass sugar einfach nicht startet. Nun sind dies keine sehr wichtigen Pakete, aber es ist schon erstaunlich, wie schlicht nicht lauffähige Software in ein Release kommt.

Ingesamt also überwindbare Probleme. Aber es bleibt die Frage, warum man überhaupt Ubuntu nutzen sollte - jenseits des "Es ist freie Software und es fühlt sich gut an!". Immerhin ist der Anspruch von Ubuntu ja, den Bug 1 von Ubuntu zu fixen. Meiner Ansicht nach ist ein wesentlicher Vorteil die virtuellen Desktops. Eigentlich ist das ein Feature, dass X Window Manager schon lange anbieten. Man kann tatsächlich mehrere Arbeitsflächen einrichten, die jeweils Anwendungen für bestimmte Aufgaben wie Kommunikation (EMail, Skype, IM) oder konkrete Arbeit (OpenOffice) enthalten. Dadurch kann man tatsächlich diese Aufgaben konsequent voneinander trennen. Lustigerweise geht das viel besser als unter Mac OS X mit Spaces. Das liegt meiner Ansicht nach daran, dass die Desktops tatsächlich getrennt sind. Alt+Tab beispielsweise schaltet nur zwischen den Fenstern im aktuellen Desktop um. bei Mac OS X schaltet es zwischen alle Fenster um. Außerdem kann man Fenster auf einem oder allen Desktops anzeigen lassen. Alles keine Innovationen, sondern schon lange üblich bei Linux - aber eben weder unter Windows noch Mac OS X und ein Feature, dass ich in Mac OS X auch gerne sehen würde.

Ansonsten bin ich nicht sicher, ob ich Microsoft Office Mac gegen OpenOffice eintauschen würde, denn ich bin auf weitgehende Kompatibilität angewiesen. Aber es macht sicher Spaß, sich mal anderswo - also bei Ubuntu - umzusehen.

Fazit: Die Installation von UNR 9.0.4 auf dem eeePC 701 ist nicht akzeptabel. Die Installation auf dem einem derart weit verbreiteten Netbook sollte Plug and Play sein. Die Installation auf dem 1101HA ist erwartungskonform und man hätte den Problemen mit anderer Hardware wahrscheinlich entgehen können. Ubuntu insgesamt macht Spaß - wenn auch einige Dinge wie nicht funktionierende Software - einfach nicht akzeptabel sind.

Am Ende noch ein "Danke" an Canonical, Ubuntu und die Ubuntu-Community für die Software!

Über Architekturen und Perfektion

2009-11-06T12:49:00.000+01:00

Wenn ich mir Architekturen ansehen, wie sie typischerweise präsentiert werden, muss ich an dieses Photo denken:

Ein völlig sauber, möglichst quadratisches Gebäude mit rechten Winkeln - das ist es, was man meistens als Ziel für die Architektur präsentiert bekommt. Oder die tatsächliche Architektur des Systems soll wirklich so aussehen. Meistens gibt es da aber dann die sprichwörtlichen "kleinen" Ausnahmen.

In Wirklichkeit erinnern mich die tatsächlichen Architekturen eher an das hier:

Das ist das Spiel "Villa Paletti", zum bekommen bei Amazon. Dabei geht es darum, dass jeder Spieler Säulen seiner Farbe ganz nach oben auf das Gebäude stellen muss, bis es einstürzt. Es gewinnt der Spieler mit den wertvollsten Säulen auf der obersten Ebene.

Wenn man sich die dabei entstehenden Konstruktionen anschaut, sind sie sicher ein Gräuel, wenn man ein Gebäude mit möglichst vielen rechten Winkeln und klaren Strukturen bevorzugt. Und natürlich ist das Ziel einer Software-Architektur nicht, dass sie am Ende einstürzt.

Aber die entstehenden Entwürfe haben auch Vorteile: Auf dem Bild kann man erkennen, dass die oberste Ebene nur von zwei Säulen unterstützt wird. Hier kommt man also mit einem sehr geringen Material-Einsatz aus - und bei einem klassischen Entwurf würde man sicher jede Ebene mindestens mit drei Säulen unterstützen. Es kann also im Laufe des Spiels eine Konstruktion entstehen, die mit weniger Material mehr Höhe erreicht, als dies bei einer im Vorhinein geplanten Konstruktion der Fall wäre.

Die andere interessante Eigenschaft des Spiels ist, dass man ständig evolutionär weiterentwickelt. Das Gebäude umfasst immer alle Bausteine und wird schrittweise "optimiert", also höher. Das ist bei dem Gebäude auf dem anderen Bild sicher nicht der Fall. Dort wird das Gebäude gebaut, es dann irgendwann "fertig" und kann danach eigentlich nicht mehr wirklich verändert werden. Bevor es "fertig" ist, kann man es nicht benutzen. Für Software ist das eine schlechte Eigenschaft, weil man dann die Software nicht ernsthaft weiterentwickeln kann.

Ich bin nun der Meinung, dass "Villa Paletti" eine wesentlich bessere Metapher für Software-Entwicklung ist als das Gebäude weiter oben. Warum?

Software entsteht evolutionär. Es wird ständig weiterentwickelt, angepasst usw - ein klarer, rechteckiger Entwurf kann dabei nicht entstehen.

Selbst wenn ein "sauberer" Entwurf entstehen könnte - das "Villa Paletti"-Modell ist teilweise überlegen, wie man am Beispiel des Material-Einsatzes sieht.

Für die Software-Entwicklung bedeutet das aus meiner Sicht, dass wir uns von den klaren, rechteckigen Entwürfen verabschieden müssen - wir werden sie eh nicht realisieren können. Wenn man es dennoch versucht, landet man bei Stackenblocken, weil man es eben nicht schafft, alles in rechten Winkeln anzuordnen. Zu Stackenblocken gibt es unter http://www.youtube.com/watch?v=QEN5-_93gQg ein sehr sehenswertes Video.

Das bedeutet aus meiner Sicht:

Lebe damit, dass die Architektur nicht perfekt sein wird!

Beeinflusse aktiv, welche Teile architekturell besser und schlechter sind. Wenn nicht alles perfekt sein kann, muss man dafür sorgen, dass zumindest die wichtigen Teile eine gute Architektur haben.

Setze also Prioritäten: Probleme, mit denen man leben kann, sollte man nicht korrigieren. Beispielsweise ist ein sauberer Entwurf kein Wert an sich, sondern er hilft bei der Weiterentwicklung. Ein sauberer Entwurf für einen Teil, den man nicht weiterentwickeln wird, macht daher kaum Sinn.

Entwickel daher die Architektur und die Software evolutionär weiter. Man kann nicht ein sauberes, neues Gebäude bauen - es wird früher oder später wieder umgebaut werden, das muss evolutionär passieren und das Umschalten auf das neue Gebäude wird nicht einfach sein.

Noch Plätze frei: Spring: Performance, Skalierbarkeit & Betrieb am 3.11. in Düsseldorf

2009-10-20T10:21:00.003+02:00

Am 3.11. findet in Düsseldorf der Event zu Spring: Performance, Skalierbarkeit & Betrieb statt.

Auf der Agenda steht:

Monitoring und Performance Optimierungen mit Spring (Eberhard Wolff)

Portabilität auf Framework-Level - Spring als Runtime (Agim Emruli)

Hyperic HQ - Die Open-Source-Monitoring-Lösung (Agim Emruli)

Tomcat und OSGi als Plattformen: Alternativen, Vor- und Nachteile (Eberhard Wolff)

Nähere Informationen finden Sie unter http://spring-performance.eventbrite.com/. Dort können Sie sich auch registrieren. Es wird ein Unkostenbeitrag in Höhe von 99€ erhoben, für das leibliche Wohl ist gesorgt.

JAOO: Dritter Tag

2009-10-07T23:43:00.005+02:00

Heute habe ich nur wenige Sessions besucht. In der Keynote hat Cameron Purdy nocheinmal die Vorteile von Java gegenüber C++. Daraus wollte er dann die Probleme von Java ableiten, die eine neue Sprache lösen müsste. Dort kamen Themen wie Startup Time, Memory Footprint, Full GC Pausen usw - meiner Meinung nach nicht wirklich die großen Probleme.

Dann habe ich noch den Schluss von Beat Schweglers Vortrag über Microsofts Cloud-Pläne mitbekommen und mich geärgert, dass ich nicht früher bei dem Talk war.

Gregor Hohpe sprach über Googles Cloud Ansatz. Dabei ging es um das Google File System, Big Table für Datenhaltung und Map Reduce für die Verteilung von Arbeit. Wie auch Urs Hölzle vor ihm gab das einen guten und interessante Einblick darin, wie Google arbeitet.

Schließlich habe ich noch den Vortrag von Rod Johnson, dem Chef der SpringSource Division bei VMware angehört. Dieser Vortrag zeigt sehr deutlich, wo die Chancen von SpringSource un VMWare liegen. Die Folien gibt es hier - reinschauen lohnt sich. Fast alle anderen Folien finden sich im Schedule der Konferenz.

Artikel zu Spring ROO

2009-10-07T08:33:00.002+02:00

Hier findet sich ein Artikel meines Kollegen Mike Wiesner für Jaxenter über Spring ROO. Dabei handelt sich um einen Generator-basierten Ansatz für die Entwicklung von Spring-Anwendungen. Viel Spaß beim Lesen.

JAOO: Tag 2

2009-10-07T07:27:00.004+02:00

Zunächst ein Nachtrag zum ersten Tag: Ich war auch in einem Talk von Jonas Jacobi zu WebSockets. Interessant war dabei neben WebSockets auch das Stomp-Protokoll, mit dem man in JavaScript von ActiveMQ Mesages empfangen kann - und das sehr problemlos.

Der zweite Tag ging los mit einer Keynot von Simon Peyton-Jones (Microsoft Research) zu Haskell, einer funktionalen Programmiersprache, und zwar insbesondere zu dem Typ-System und der Modellierung von Klassen in dem System. Inhaltlich fand ich es sehr interessant, aber sicher auch eher schwer zu verstehen. Gleichzeitig zeigt die Keynote, dass Sprachen wieder ein Thema sind. Lustig ist vor allem, dass vor längerer Zeit ein Bekannter Haskell an der Uni lernen musste und sehr negativ dazu eingestellt war - weil es ihm akademisch und nicht praxisrelevant erschien. Jetzt scheint Haskell in der Nutzung auch außerhalb der Unix zumindest zuzulegen und Microsoft Research wird sicher nicht "einfach so" Experten in dieser Sprache eingestellt haben.

Den Start des von mir organisierten "Java Now" Tracks gab es auch eine Art Keynote. Rod Johnson, Erfinder von Spring und Chef der SpringSource-Division bei VMWare, sprach über den Trend zu Open Source und leichtgewichtigen Ansätzen bei Java. Ich fand diesen Vortrag vor allem wichtig, um auf die große Bedeutung von Open Source als Innovator bei Java hinzuweisen.

In diesem Sinne ging es dann weiter: Dalibor Topic (Sun) sprach über das OpenJDK-Projekt, dessen Leiter er ist. Neben den Innovationen wie Type Annotations habe ich vor allem mitgenommen, dass Java noch mehr Verbreitung findet, seit es Open Source ist. So steht es jetzt in jeder Linux-Distribution zur Verfügung und auch in vielen anderen Betriebssystemen wie beispielsweise BSD. Später zeigte Dalibor mir noch eine Grafik, die zeigt, dass es auch immer mehr Open-Source-Projekte gibt, die auf Java setzen. Also wird durch das OpenJDK-Projekt Java noch populärer.

Martin Lippert sprach dann über OSGi auf dem Server, meiner Meinung nach eines der wichtigsten Zukunftsthemen für Server-Java. Schön war, dass Martin auch der Meinung ist, dass der SpringSource dm Server in diesem Bereich im Moment die beste Lösung darstellt. Inhaltlich ging Martin neben den Grundlagen - also den Problemen, die man bei OSGi auf dem Server hat - auch auf die neuen Architektur-Herausforderungen wegen der Dynamik von OSGi ein. Ich denke, dass in diesem Feld noch einige interessante Ansätze möglich sein werden.

Kirk Pepperdine sprach über Latenzzeiten. Gerade bei automatisierten Börsen-Systemen können Latenzen sehr wichtig sein. In seinem Talk hat er dann einen vollständigen Ansatz zur Analyse von Performance-Problemen dargestellt - was für eine Stunde eine große Leistung ist.

Am Abend gab es dann noch eine Diskussion mit James O Coplien und mir bei der JavaGruppen zur Zukunft von Java. An dieser Stelle nochmal mein Dank an JavaGruppen und Martin Boel für die Organisation. Insgesamt gab es eine lebhafte Diskussion und ich hoffe, dass dabei klar geworden ist, dass Java und die JVM eine sehr positive Zukunft haben werden.

JAOO: Erster Tag

2009-10-05T19:01:00.005+02:00

Ich bin gerade auf der JAAO Konferenze in Dänemark und habe den ersten Tag erfolgreich hinter mich gebracht. Hier die Highlights:

Rod Johnson hat über Spring ROO gesprochen. Passend dazu ist heute auch der zweite Release Candidate erschienen, siehe http://www.springsource.org/node/2024. Meiner Meinung nach eine sehr interessante Technologie, mit der man durch ein gutes Framework und einen Generator wesentlich bessere Produktivität erreichen kann. Vor allem muss man sich nicht mehr mit den Details von Maven etc. auseinandersetzen. Die breite Mehrheit der Zuhörer findet das auch und wollte nach Rods Nachfrage sich ROO auch anschauen!

Interessant war auch die Präsentation von Graeme Rocher über Grails: Bekanntermaßen ist es ein sehr interessanter und produktiver Ansatz für die Entwicklung mit Groovy. Man kann über die mittlerweile 299 Plug Ins alles mögliche einbauen - Taxonomien, Tags usw.

Urs Hölzle von Google sprach über energieeffiziente Rechenzentrum. Ich fand es spannend, dass einer der Gurus für VMs und Programmiersprachen nun in diesem Bereich tätig ist. Aber wenn man sich die Anzahl Server bei Google ansieht und die technischen Herausforderungen, ist das nachvollziehbar.

Für morgen steht dann der von mir organisierte Java-Track auf dem Programm...

Bitte wählen!

2009-09-24T18:45:00.002+02:00

Am Sonntag ist Bundestagswahl. Ich möchte alle Leser dieses Blogs darum bitten, an der Wahl teilzunehmen und dabei eine demokratische Partei - also nicht NPD - zu wählen.

Und an dieser Stelle noch ein Hinweis an die NPD-Wähler unter den Lesern: Sie sind hier nicht erwünscht. Ich möchte nicht, dass die Ergebnisse meiner Arbeit von Nazis genutzt werden. Bitte bestellen Sie den Blog ab. Danke.

SE-Radio-Interview mit mir über Spring

2009-09-23T08:08:00.002+02:00

Unter http://www.se-radio.net/podcast/2009-09/spring-2009-eberhard-wolff gibt es eine Interview mit mir zum Spring-Framework - allerdings in Englisch. An dieser Stelle mein Dank an SE Radio und insbesondere Markus Völter für das Interviews.

Event: Leichtgewichtige JEE Entwicklung mit dem Spring Framework

2009-09-11T10:40:00.004+02:00

SpringSource und OPITZ CONSULTING zeigen auf unsere gemeinsamen
Veranstaltung „Moderne Enterprise-Java-Entwicklung mit dem Spring
Framework“ welche Vorteile die Entwicklung mit Spring bei
Individualsoftware bringt. Individualsoftware unterstützt komplexe
Prozesse optimal und lässt sich so flexibel anpassen, dass sie den
ständigen Änderungen im Geschäft gewachsen ist. Jedoch verbindet man
Entwicklung und Betrieb individueller Unternehmensanwendungen oft mit
drei Eigenschaften: teuer, riskant und aufwändig. Dass es mit den
richtigen Werkzeugen und Methoden auch anders gehen kann, möchten wir
Ihnen in dieser Vortragsreihe beweisen.

Termine:
23.9.2009 Frankfurt
12.10.2009 Hamburg
13.10.2009 München
14.10.2009 Köln
9.11.2009 Zürich

Agenda

10:00 Uhr Softwareprojekte in wirtschaftlich schweren Zeiten

Chancen und Risiken

Bedeutung von Vorgehen und Technik

Referent: OPITZ CONSULTING

10:25 Uhr Effizienz durch moderne Entwicklungsverfahren

Spring als Grundlage moderner Architekturen

Qualität und Wartbarkeit durch Testautomatisierung

Effizienz durch Vermeidung nichtdifferenzierender Entwicklung

Referent: OPITZ CONSULTING

11:15 Uhr Integration statt Neuentwicklung

Spring als Integrationsplattform

Effizienz durch Vermeidung nichtdifferenzierender Entwicklung

Fallbeispiele

Referent: OPITZ CONSULTING

12:00 Uhr Mittagspause

12:45 Uhr Spring kosteneffizient betreiben

Monitoring und Administration

tc Server, dm Server und Hyperic

Praxisbeispiele

Referent: SpringSource

13:30 Uhr Get together

EJB 3.1 Singletons considered harmful

2009-09-11T09:00:00.003+02:00

Bevor wir zum Problem vorstoßen, zunächst einige Worte zu Singletons und Pooling. EJB hat vor 3.1 nur ein Modell mit Pooling von Bean angeboten. Der Grund für diese Entscheidung ist, dass man sich so nicht mit Multi-Threading in seiner Anwendung beschäftigen muss. Jeder Thread bekommt seine Instanz aus dem Pool, daher wird jede Instanz nur von einem Thread genutzt. Spring hingegen nutzt Singletons - von jeder Spring Bean gibt es typischerweise nur eine Instanz. Spring bietet auch die Option für Pooling - aber dieses Feature würde ich für den Preis des am wenigsten genutzten Features in Spring nominieren. Ich selber habe es bisher nur einmal produktiv verwendet - und nicht etwa, um Thread-Problemen zu entgehen, sondern um Ressourcen zu poolen. Die Nutzung von Singletons stellt bezüglich den Threads nämlich meistens kein Problem dar - weil die Beans fast immer Thread-Safe sind. Sie erhalten die Daten als Parameter, haben keinen eigenen Zustand und Ressourcen wie die Datenbankverbindung wird von Spring automatisch an den Thread gekoppelt. Dieses Modell wird in vielen Anwendungen genutzt und hat sich als sehr skalierbar erwiesen.

EJB 3.1 bietet nun als Neuerung auch ein Singelton-Modell an. Obwohl es aber mittlerweile unstrittig ist, dass Pooling praktisch nie wirklich benötigt wird, bleibt das Pooling der Default. Singletons sind vor allem dafür gedacht, um Datenstrukturen zu implementieren, die man nur einmal haben möchte. Dazu gehören zum Beispiel Caches. Es macht kaum Sinn, mehrere Instanzen eines Caches vorzuhalten. Man sollte lieber für alle Zugriffe dieselbe Instanz nutzen, weil man sonst mehrere Cache befüllen muss. Ein einfaches Singleton kann zum Beispiel folgendermaßen aussehen:


@Singleton
public class MyCache {
  
  private Map cache = new ConcurrentHashMap();

  public Object get(String key) {
    return cache.get(key);
  }

  public void store(String key, Object value) {
    cache.put(key, value);
  }

}

Sieht jemand das Problem? Nun, wenn man diese Implementierung so nutzt, wird man ein erhebliches Skalierungsproblem haben. Überrascht? Lesen Sie weiter.

EJB 3.1 Singletons haben ein interessantes Feature. In der EJB-3.1-Spezifikation ist das Problem der Nebenläufigkeit gelöst worden. Dieses Thema dort anzusprechen ist gleich aus mehreren Gründen spannend:

In Java gibt es mit synchronized und dem Package java.util.concurrent ausgesprochen gute Werkzeuge für Nebenläufigkeit. Es muss in diesem Bereich also keine Lücke gefüllt werden.

Nehmen wir dennoch an, dass die Unterstützung für Nebenläufigkeit in EJB 3.1 eine sinnvolle Ergänzung ist. Warum ist sie dann auf EJB 3.1 beschränkt? Nebenläufigkeit ist ein fundamentales Problem und gehört nicht in eine spezialisierte API wie EJB.

Außerdem ist Nebenläufigkeit bei den Singletons meist kein Problem, wenn man die Erfahrungen mit Spring zu Grunde legt. Zugegebenermaßen fokussiert EJB 3.1 aber auf Anwendungsfälle, bei denen man Datenstrukturen verwendet, die von mehreren Threads genutzt werden sollen, wie den Cache im Beispiel oben. Dort kann es dann sicher zu Nebenläufigkeitsproblemen kommen.

Das erinnert an eines der größten Probleme von EJB in Version 1.x und 2.x. Damals wurde mit Container Managed Persistence das Persistenz-Problem gelöst. Dabei wurden die bekannten Ansätze von O/R-Mappern ignoriert - so wie man jetzt die vorhandenen Nebenläufigkeits-APIs ignoriert. Und man hat eine Lösung in EJB implementiert, so dass man sie nur in einem Application Server nutzen kann - obwohl Persistenz genau wie heute Nebenläufigkeit ein viel allgemeineres Problem ist.

Wie funktioniert nun die Nebenläufigkeit bei EJB 3.1? Der Default ist Container Managed Concurrency. Alternativ kann man durch Bean Managed Concurrency die üblich Java-Bordmittel nutzen. Bei Container Managed Concurrency kann eine Methode mit @Lock(READ) oder @Lock(WRITE) markieren. Nur eine Methode mit einem WRITE-Lock kann zu einem Zeitpunkt aufgerufen werden. Keine andere Methode - weder mit READ- noch mit WRITE-Lock - darf dann in einem anderen Thread ausgeführt werden. Parallele Abarbeitung von Methoden mit READ-Locks ist hingegen erlaubt. Die Nebenläufigkeit an Methoden fest zu machen ist alleine schon Problem genug. Der Schlüssel zu einem skalierbaren System ist, dass man Locks so kurz wie möglich hält.

Ich hatte vor einiger Zeit einen Consulting-Einsatz wegen eines Skalierungsproblems. Das habe ich gelöst, indem ich diesen Code:


...
synchronized(cache) {
   if (cache.get(key)==null) {
      cache.put(aValue);
   }
}
...

durch solchen Code ersetzt habe:


...
if (cache.get(key)==null) {
   synchronized(cache) {
     if (cache.get(key)==null) {
        cache.put(aValue);
     }
  }
}
...

Dadurch wird der Cache nur noch gelockt, wenn er den Wert noch nicht enthält. Da der Cache irgendwann gefüllt ist, wird der Cache dann praktisch gar nicht mehr gelockt und man kann der Code dann mit wesentlich besserer Nebenläufigkeit betrieben werden. Wie man hier sieht, kann das Verschieben des Locking um eine Zeile schon einen erheblichen Unterschied machen. Wenn man solche Sachen mit den EJB-3.1-Annotationen machen will, wird man nicht weiterkommen, da sie nur auf Methoden wirken.

Schlimmer wird es nun dadurch, dass der Default ist, dass jede Methode ohne Annotationen so behandelt wird, als wäre sie mit @Lock(WRITE) versehen. Das bedeutet, dass in dem gesamten EJB-3.1-Singleton - wenn man nicht anderes definiert - nur ein Thread zur Zeit aktiv sein kann. Der oben mit EJB 3.1 implementierte Cache kann also nur von einem Thread parallel genutzt werden. Das wird in der Realität bei vielen parallelen Threads zu erheblichen Problemen führen. Da @Lock(WRITE) der Default ist, sieht man gar nicht, was passiert, und muss man sehr genau verstehen, was hinter den Kulissen vor sich geht. Wer also einfach so mit EJB 3.1 los programmiert, wird in diese Falle tappen.

Besonders ironisch ist natürlich, dass der oben definierte Cache durch die ConcurrentHashMap sowieso von mehreren Threads parallel genutzt werden kann. EJB 3.1 schüzt uns also ganz umsonst von der ach-so-komplizierten Welt der Nebenläufigkeit.

Event am 3.11. in Düsseldorf: Spring: Performance, Skalierbarkeit & Betrieb

2009-09-08T10:12:00.002+02:00

Sie benutzen Spring zur Entwicklung Ihrer Anwendungen - aber was ist beim Betrieb und Performance-Tuning zu beachten? In diesem Seminar erhalten Sie Hinweise, wie man Anwendungen mit Spring effektiv betreiben kann und wie man typische Performance-Optimierungen vornehmen kann. Dabei stellen wir Ihnen Projekte wie die Hyperic HQ Open-Source-Monitoring-Lösung, Tomcat und dm Server vor.

Bitte registrieren Sie Sich unter http://spring-performance.eventbrite.com/ - dort finden Sie auch den genauen Ablauf. Es wird ein Unkostenbeitrag von 99€ erhoben. Für das leibliche Wohl ist gesorgt.

VMware und SpringSource nachdem sich der Staub gelegt hat....

2009-08-14T14:20:00.002+02:00

Am Montag abend ist der Kauf von SpringSource durch VMware öffentlich bekannt gegeben worden. VMware ist schon länger Partner von SpringSource. Es gab auch vor dem Kauf technologische Kooperationen zum Beispiel beim der Integration des VMware Lab Manager in die SpringSource Tool Suite. Daher kommt der Schritt für SpringSource-Mitarbeiter nicht überraschend, denn es gab schon lange Beziehungen. Für einige Außenstehende ist der Schritt anscheinend dennoch überraschend -obwohl SpringSource nicht die erste Enterprise-Java-Firma ist, die von einer größeren Firma gekauft wird.

Technisch ist dieser Schritt auf jeden Fall sehr sinnvoll. Mit tc Server und dm Server haben wir innovative Application Server im Angebot, die insbesondere in der Cloud Vorteile bringen. Dazu gehört in tc Server die Möglichkeit, eine Gruppe von Servern zu definieren, auf die man dann Anwendungen deployen kann oder umkonfigurieren kann. Ähnliches wird es in dm Server 2.0 auch geben. Außerdem wird man dort ein zentrales Repository für mehrere dm Serve definieren können, aus dem dann alle Server in der Cloud OSGi Bundles laden können. Und unser Management-Produkt Hyperic ist gerade beim Management von Clouds sinnvoll, weil man nur einen Agent auf jedem Knoten installieren muss - die komplette zu managende Software auf dem Rechner wird automatisch gefunden. Man kann also basierend auf diesen Lösungen leicht einen Cloud von VMs aufbauen, um seine Anwendung skalierbar zu halten und effektiv zu betreiben. Durch VMwares Technologien kann man dann in diesem Cluster einzelne Knoten auf andere physikalische Rechner migrieren, um bei einem Ausfall die Verfügbarkeit zu gewährleisten oder bei Hochlast die Performance zu verbessern.

Ebenfalls wird die Entwicklung vereinfacht, weil man sehr einfach Test-Umgebungen aufbauen kann und auf diesen die Anwendungen mit einem Application Server zusammen deployen kann. Solche Test-Umgebungen kann man auch recht einfach in Produktionskonfigurationen überführen. Ohne Virtualisierung sind diese Aufgaben sehr komplex, dauern sehr lange und sind auch sehr fehleranfällig. Weitere technische Diskussionen dazu finden sich in Adrian Colyers (CTO SpringSource) Blog Post.

Neben den Technologien ist ein weiterer wichtiger Punkt die Ausrichtung der Firmen. Beide Firmen sind technologie-fokusiert. Beide Firmen haben sich zur Offenheit bekannt. Das ist konsequent: Letztendlich ist der Erfolg der SpringSource-Technologien nur durch ihre Communities möglich. Dafür möchte ich mich bedanken. Wir werden auch weiterhin unsere Communities interessante Technologien anbieten - um so mehr, weil wir nun durch eine direkte Unterstützung von Virtualisierung spannende neue Ansätze anbieten können. Gleichzeitig werden wir auch weiterhin alternative Ansätze unterstützen. Schließlich ist einer der großen Vorteile von Spring schon immer die Plattformunabhängigkeit gewesen und das wird sich nicht ändern.

SpringSource wird von VMWare gekauft

2009-08-10T22:17:00.004+02:00

SpringSource wird von VMWare gekauft. Das ist ein sinnvoller Deal, weil wir uns gut ergänzen, es gibt keine Überschneidungen bei den Produkten. Und gleichzeitig haben wir ein recht umfangreiches Produktangebot. Gleichzeitig bietet es uns die Möglichkeit, noch mehr in unsere Technologien zu investieren. Siehe zum Beispiel http://finance.yahoo.com/news/VMware-to-Acquire-iw-1761113527.html?x=0&.v=1 oder http://blog.springsource.com/2009/08/10/springsource-chapter-two/.

Spring 3.0: Meta Annoationen

2009-08-10T10:32:00.002+02:00

In Spring 3.0 hat mit Meta Annotationen ein neues Feature Einzug gehalten, das den Umgang mit Annotationen vereinfacht. Hier ein Beispiel ohne Meta Annotationen:

@Service @Transactional(timeout=42, noRollbackFor={ApplicationException.class}) public class EinService { ... }

Wie man sieht, ist der Service mit zwei Annotationen versehen. Vermutlich sollen alle anderen Services genauso annotiert werden. Der Code drückt aber nicht die eigentliche Intention aus: Jeder Service auch die entsprechenden Transaktions-Regeln haben. Beide Annotationen werden immer nur zusammen vorkommen.
Das könnte man durch AOP lösen, indem man jeden Service per AOP mit einer passenden Transaktions-Regel versieht. Eine ander Möglichkeit sind die Meta Annotationen. Dazu definiert man sich seine eigene Annotation:

@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) @Service @Transactional(timeout=42, noRollbackFor={ApplicationException.class}) public @interface MeinService { }

Diese Annotation wirkt nun genau wie die Kombination aus @Service und @Transactional. Der obige Code wird also zu:

@MeinService public class EinService { ... }

Analog könnte man @MeinRepository usw. definieren. Dabei ist zum Beispiel auch die Nutzung von @Scope für die Definition eines Scopes möglich.

Wie man sieht, bieten Meta-Annotationen interessante neue Möglichkeiten für die Konfiguration mit Spring.

Das Problem mit Java EE oder: Die reale Realität vs. die Konfernenz-Realität

2009-07-28T11:30:00.003+02:00

Wenn man Konferenzen besucht und sich Vorträge anhört, bekommt man leicht den Eindruck, dass Java EE eine ernsthafte Alternative zu Spring ist und vor allem - es ist ja im Application Server enthalten, warum also Spring nutzen? Dabei ist die Rede natürlich von Java EE 5 und dem noch nicht fertig spezifizierte Java EE 6. Diese Standards haben neue Programmiermodelle eingeführt - über die Probleme von Java EE 1.4 und EJB 2.x braucht man wohl nichts zu sagen.

Interessanterweise hat diese Konferenz-Realität aber nichts mit der realen Realität zu tun, die da draußen in den Projekten wirklich gelebt wird. Zunächst einmal sagen zahlreiche Statistiken, dass Tomcat die führende Java-Plattform ist. So zeigt der JAXenter Quick Vote zum Beispiel, dass 58% aller Java-Entwickler Tomcat als Basis aller Web-Projekte verwenden, 24% gelegentlich je nach technischer Entscheidung und 12% gelegentlich je nach politischer Entscheidung - zusammen 94%. Das 2008 Evans Data Survey geht von 68% Markt-Anteil von Tomcat aus. Das TheServerSide Survey kommt zu ähnlichen Ergebnisse. Ingesamt arbeitet die Mehrheit der Java-Anwendung also mit Tomcat und hat daher keine vollständige Java-EE-Umgebung. Sie können oder wollen also nicht die vollständigen Java-EE-APIs nutzen. Es kann auf keinen Fall die Rede davon sein, dass man die Java-EE-APIs "eh schon im Application Server hat". Das Gegenteil ist der Fall - der Java-EE-Application-Server ist die Ausnahme, nicht die Regel. Und selbst wenn einer genutzt wird, ist es oft eine alte Version, die noch kein Java EE 5 unterstützt. Der Betrieb ist eben eher konservativ. Java EE 6 ist noch nicht einmal fertig standardisiert - es macht also wenig Sinn, das weiter zu betrachten.

Diese Wahrnehmung spiegelt sich auch in konkret in letzter Zeit erlebten Projekt-Szenarien wieder:

So das Projekt, das zwar auf einem vollständigen Java-EE-Server läuft, aber auf JDK 1.4. Java EE würde hier EJB 2.x anbieten, was niemand wirklich will. Die einzige sinnvolle Alternative ist also Spring.

Oder das Projekt, dass auf einer Standard-Software aufbaut. Die läuft auf einem gebundelten Tomcat - der eben kein vollständiges Java EE anbietet. Selbst wenn man wollte, kann man kein vollständiges Java EE nutzen.

Oder das Projekt, das von EJB 3 wegmigriert, um auf Tomcat umzusteigen - weil man Tomcat als gegenüber Java EE als Ablaufumgebung vorzieht.

Die Realität im Java-Bereich ist, dass eine vollständige Java-EE-Unterstützung - im Gegensatz zu dem Stand vor einigen Jahren - bei Enterprise-Anwendungen keine große Rolle mehr spielt. Und ich denke, dass sich dieser Trends aufgrund der Dominanz von Tomcat und dem OSGi-Aufschwung noch weiter verstärken wird.

Spring Day WJAX

2009-07-19T12:18:00.002+02:00

Ich habe auch dieses Jahr wieder das Vergnügen, den Spring Day auf der WJAX zu organisieren.

Den Anfang werde ich dieses Jahr bestreiten mit einem Überblick über Spring 3.0, das dann auch zur Verfügung stehen sollte. Mein Kollege Agim Emruli spricht dann über Rich Internet Applikationen mit Spring. Gerade in diesem Bereich stehen mit Spring Faces und der BlazeDS-Integration einige interessante neue Ansätze bereit. Zusammen mit Papick Taboada präsentiert Agim dann den dm Server insbesondere für den Einsatz für Web-Anwendungen. Thomas Biskup von Quinscape spricht im Anschluß über Möglichkeiten, wie man Spring gewinnbringend einführen kann. Ein wie ich finde interessantes Thema, weil man bei der Einführung naturgemäß noch nicht so viel über Spring weiß, aber eigentlich erst mit viel Erfahrung erkennt, wo Spring am besten einzusetzen ist.

Spring EInführungsartikel

2009-07-19T12:14:00.002+02:00

Unter http://robbbert.hostrator.com/ steht ein recht umfangreicher Artikel mit einer Einführung zu Spring bereit.

JAOO Java Track

2009-06-22T11:53:00.007+02:00

Ich habe dieses Jahr die Ehre, den Java Track auf der JAOO in Århus, Dänemark, zu organisieren. Das ist vor allem eine Ehre, weil die JAOO ursprünglich eine reine Java-Konferenz war und somit dieser Track sozusagen eine Art Kern der Konferenz darstellt.

Das Programm ist nun unter http://jaoo.dk/aarhus-2009/tracks/show_track.jsp?trackOID=264 online.

Erster Sprecher wird Rod Johnson sein, CEO von SpringSource. Dabei geht es um Innovation durch Standards und Open Source. Traditionell sind Standard bei Java ja wichtig gewesen, aber das ändert sich gerade. Und Open Source Projekte - wie Spring, Tomcat, Eclipse usw - werden langsam zu den wichtigsten Technologien im Java-Bereich. Die Details können sich aber durchaus noch ändern.

Wegen Open-Source-Thema freut es mich, Dalibor Topic als nächsten Speaker gewonnen zu haben. Er ist der Leiter des Open-JDK-Projekts und arbeitet dadurch an einer sehr zentralen Stelle im Open-Source-Java-Bereich. Gerade durch den Kauf von Sun durch Oracle ist es wichtig, sich noch einmal zu vergegenwärtigen, dass Java eben Open Source ist und kein Sun-Projekt. Außerdem sind für viele Java-Entwickler die konkreten Konsequenzen des Open-JDK-Projekts für ihre tägliche Arbeit noch nicht erkennbar. Das soll dieser Talk korrigieren.

Eine wichtige technische Innovation im Java-Bereich ist OSGi, vor allem auf dem Server. Zu diesem Thema konnte ich Martin Lippert gewinnen, der ja eine der herausragenden Größe in diesem Bereich ist. Themen wie Modularisierung und Dynamisierung werden Java-Server-Anwendungen sicher deutlich ändern und ich bin auf Martins Ausführungen diesbezüglich gespannt.

Schließlich gibt Gary Sevitsky einen Talk über speichereffiziente Java-Anwendung - ein konret uns praktisch wichtiges Thema. Den Abschluss bilde ich dann selber mit einem Überblick typischer Probleme in Java-Anwendung - ein Resultat der vielen Code-Reviews, die ich durchgeführt habe.

Und mein Kollege Arjen Poutsma organisiert dann noch den Spring-Track, siehe http://jaoo.dk/aarhus-2009/tracks/show_track.jsp?trackOID=274 .

Case Study mit QuinScape online

2009-06-17T12:38:00.002+02:00

Unter http://www.springsource.com/files/QuinScape%20Case%20Study_0.pdf steht nun eine Case Study zur Verfügung, in der unser deutscher Partner QuinScape über die Vorzüge von Spring und dm Server bei der Entwicklung von Anwendungen berichtet.

Domain Driven Design Seminar mit Eric Evans in Deutschland

2009-06-12T13:51:00.003+02:00

Unter http://www.domainlanguage.de/training/index.html gibt es eine Liste von Seminaren unter anderem auch mit Eric Evans zum Thema Domain Driven Design in Deutschland. Dieser Ansatz ist sicher einer der wichtigsten im Bereich der Software-Entwicklung und es ist schön, dass hier im deutschsprachigen Bereich nun auch mehr passiert!

Noch Plätze frei: SpringSource tc Server Event - The Tomcat you know, the Enterprise Capabilities you need

2009-06-09T13:35:00.002+02:00

Planen Sie die Migration weg von teuren und komplexen Java-EE-Applications-Servern?
Benötigen Sie Enterprise-Eigenschaften, die Tomcat selber nicht hat?

Tomcat ist ein sehr leistungsfähiger Web-Server, aber Tomcat-Installationen sind für Administratoren eine komplexe Herausforderung. Das Management und Monitoring unterstützt Tomcat sogar praktisch gar nicht, so dass oft aufwändige Lösungen selbst entwickelt werden müssen.
SpringSource tc Server ist da – endlich kann man Tomcat einfach installieren, managen und monitoren und dadurch Kosten sparen! Dieser zweistündige Vortrag zeigt Ihnen:

Wie Sie große Installationen managen

Verteilte Tomcat Instanzen überwachen

Zuverlässig Unternehmens-Applikationen in die Produktions-Systemen deployen

Serverprobleme schnell und zuverlässig identifizieren, diagnostizieren und lösen

Und das beste: Wenn Sie einen teuren Applikations-Server einsetzen, zeigen wir Ihnen gerne, wie Sie die verteilten Management Fertigkeiten zusammen mit Enterprise Support zu deutlich geringeren Kosten bekommen können.

Melden Sie Sich zu diesem kostenlosen Event unter
http://tcserverinfrankfurt.eventbrite.com/ Frankfurt, 16. Juni 14:00-16:00 Uhr bzw.
http://tcserverinzurich.eventbrite.com/ Zürich, 17. Juni, 14:30-16:30
an.

Video zum Vortrag "Architekturen und Spring" online

2009-05-29T10:33:00.001+02:00

Unter http://it-republik.de/jaxenter/news/JAX-TV-Gute-Architekturen-mit-Spring-049097.html kann man nun meinen Vortrag zum Thema "Architekturen mit Spring" anschauen. Viel Spaß!

Kostenloses Dokument zum SpringSource dm Server

2009-05-26T20:30:00.003+02:00

Unter http://www.dpunkt.de/buecher/3231.html steht mein neustes Werk bereit: Ein umfassendes Dokument zum SpringSource dm Server bereit - mit Beispielen, Einführungen in OSGi und Spring und vielen weiteren Infos - einfach mal anschauen.

SpringSource tc Server - The Tomcat you know, the Enterprise Capabilities you need - Event in Frankfurt & Zürich

2009-05-19T10:09:00.003+02:00

In diesem zweistündigen Event lernen Sie den SpringSource tc Server kennen, der die Administration und Verwaltung von Tomcat-Server-Installationen entscheidend vereinfacht. Melden Sie Sich zu diesem kostenlosen Event unter

http://tcserverinfrankfurt.eventbrite.com/ Frankfurt, 16. Juni 14:00-16:00 Uhr bzw.

http://tcserverinzurich.eventbrite.com/ Zürich, 17. Juni, 14:30-16:30

an.