Heute begann das Programm schon um 8:30 und in der Pause funktionierte das WLAN nur sehr unzuverlässig.
Who is BIRT? (BIRT Day)
Gestartet habe ich den Tag mit den ersten beiden Vorträgen des BIRT Day. D.h. mit der Einführungsfrage "Was ist BIRT eigentlich?" und wohin geht die Reise mit der nächsten Version. Geplant ist, die Versionsnummern mit denen von Eclipse zu synchronisieren, so das Eclipse 3.5 zusammen mit BIRT 2.5 im Juni erscheinen wird.
Es war nichts wirklich überraschendes dabei, da ich mich vorab schon mit BIRT, Pentaho und Jasper etwas auseinandergesetzt habe. Solides Werkzeug, das auch in kommerziellen Produkten eingesetzt wird. z.B. in IBM Tivoli
Java Best Practices mit aktuellen Frameworks
Arno Haase gab einen Praxiseinblick der üblichen Herausforderungen, die man bei Verwendung großer Frameworks wie Spring trotzdem noch hat, weil auch diese Frameworks natürlich noch Lücken aufweisen (müssen?):
Logging mittels Log4J bitte unter Beachtung der Bedürfnisse des Betriebs (keine 2 GB Log pro Tag trotz Info-Modus), einem sauberen Handling von Exceptions an den Systemgrenzen, der Beachtung von Parallelität von Threads (insb. in Sessions z.B. mit Ajax), dem Umgang mit Änderungen an Konfigurationsdateien im laufenden Betrieb und schließlich mit JUnit Tests, die möglichst nicht alle Komponenten des Systems zur Testzeit benötigen sollten.
Auch diese Aussagen sind eigentlich selbstverständlich, werden aber scheinbar in vielen Projekten nicht beachtet.
Keynote: Fette Maschinen brauchen schlanke Software
von Claus Alfert. Er führt ein in die Keynote mit einem Abriss über die Geschichte der Hardware-Entwicklung nach Moores Gesetz, nachdem sich die Zahl der Transistoren alle zwei Jahre verdoppelt (nicht die Taktfrequenz!). Aktuell stehen wir bekanntlich an der Schwelle, mit der dieses Gesetz zu einer Vervielfachung der Kerne führt, die aber von der Software nicht wirklich genutzt werden können. Supercomputer werden bald Millionen von CPUs haben und auch die Entwicklung im Enterprise Markt wird in diese Richtung gehen. Aber wie sollen die Kerne ausgenutzt werden, um weiterhin Leistungssteigerungen mitnehmen zu können?
Das Amdahlsche Gesetz zeigt den maximalen Speedup für Programme durch Parallelisierung mit mehreren CPUs. Bei einer Parallelisierbarkeit der Codeausführung von 50% kommt man danach gerade mal auf einen Speedup-Faktor von 2 bei beliebig vielen CPUs. Erst mit sehr hoher Parallelisierbarkeit über 99 % kommt man der 16fachen Geschwindigkeit nah. Aber das ist richtig schwer zu erreichen.
Mit Java ist automatisches Multithreading aufgrund der für diesen Zweck ungünstig gewählten Primitive schwierig umzusetzen (Ist z.B. die Reihenfolge von Zuweisungen relevant?). Dadurch kann der Compiler nicht optimieren und die meisten CPUs werden sich langweilen.
An 3 Beispielen zeigt Herr Alfert in seinem souveränen fesselnden Vortrag auf, wie das Problem angegangen werden könnte: Funktionale Programmierung (wie z.B. in Sprache Erlang), Transactional Memory und Actors.
So senden sich Actors gegenseitig asynchron Nachrichten auf die Sie reagieren können oder nicht und können auf diese Weise warten und anderweitig weiterarbeiten, bzw. Abhängigkeiten entkoppeln. Scala implementiert Actors. Es handelt sich um einen Hybrid aus Objekt-Orientierter-Programmierung und Funktionaler Programmierung. Dabei können über 1 Million Actors pro JVM aktiv sein, während Threads gerade mal auf 3000 bis 4000 gleichzeitig kommen können.
Das heißt dann wohl, dass über kurz oder lang neue Sprachen kommen werden, die mit mehr Wissen um die Abhängigkeiten der einzelnen Aktivitäten die Arbeitsschritte optimieren und auf die CPUs verteilen können, um die Hardware zu nutzen. Vorübergehend lässt sich mit mehreren virtuellen Systemen auf einem Blech noch etwas Zeit schinden.
S.O.S. - Mein Chef sagt, wir brauchen einen ESB
Nachdem auch wir schon vor der Frage standen "ESB oder nicht ESB" und uns gegen einen ESB entschieden haben, war es sehr interessant zu sehen, das wir damit nicht ganz alleine stehen. Bzgl. des Titels des Talks wünschen sich wahrscheinlich viele Architekten, das es den "Man-In-Black-Gedächtnis-Löscher" gäbe, wenn der Chef einen Vortrag einer Firma gesehen hat, die Ihren ESB als Komplexität reduzierende Wunderlösung dargestellt hat. Die Komplexität kann man nicht reduzieren. Sie wird nur in einer wilden Konfiguration des ESB versteckt.
Thilo Frotscher gab hierzu aber keine klare Richtlinie vor, das diese Entscheidung im Einzelfall entschieden werden muss. Ein kommerzieller ESB löst im Allgemeinen alle Probleme, aber auch die die man ohne nicht hätte. D.h. der Umfang und Overhead ist das Kriterium. Leider ist nicht genau festgelegt, was zu einem ESB gehört und so unterscheiden sich die Angebote stark: Messaging System, Binding Komponenten, Transformation, Filter, Routing, Mediation, ... . Zudem hat man oftr langwierige Einführungsphasen, bevor die ESB-gestützte Lösung lauffähig, währen neue Anforderungen verzögert werden, was die Fachbereiche nicht gerne sehen.
Es gibt aber auch die schlanke Variante, sich seinen ESB mit Open Source Produkten selbst nach seinen Anforderungen zusammenzubauen. So kann man klein anfangen und das System schrittweise ausbauen und hält sich trotzdem noch die Tür auf, irgendwann einen kommerziellen ESB einzusetzen.
Mit Active MQ als Messaging-Kern, Apache Camel fürs interne Routing und Apache Synapse als externer SOAP-Router hat man entsprechende Bausteine, die einen minimalen ESB nachbilden, dessen interne Struktur bekannt ist und dessen Einzelteile austauschbar sind. Dafür ist es aber fehlerträchtiger als eine Fertiglösung, weil man die Komponenten erstmal aufeinander abstimmen muss.
Schließlich gab es noch ein paar Weisheiten zum Ausklang des Themas, die gerne verbreitet werden:
"Point2Point ist nicht schlimm!" aber zunehmend gefährlich weil komplex!
"ESB-Konfiguration ist Spaghetti-Code" aber einfacher änderbar.
"ESB nur für große Unternehmen!" aber braucht man unbedingt ein System für alles? Insellösungen funktionieren auch oft.
"Anzugträger empfehlen SOA mit ESB, Jeans- und Turnschuh-Träger klären auf und sagen es geht auch ohne ESB." aber eigentlich geht beides, nur sind die Aufwände unterschiedlich und das führt wieder zum "Es kommt drauf an."
Am Ende gibt es also zu "SOA nur Meinungen aber kaum Fakten".
Keynote: Prozesskomposition in realen Unternehmensszenarien
Herr Thomas Volmering von SAP stellte in seiner Keynote das "ultimative Manager-Tool" vor, mit dem Geschäftsprozesse in BPMN modelliert und dann in Code und somit in die Tat umgesetzt werden könnten, wenn das System dereinst mal fertig sein wird. Auch wenn er (im auf Eclipse aufsetzenden Tool) schon einige Schritte demonstrierte, wird es wohl noch Jahre dauern, bis das in Produktion nutzbar sein wird (Aussage eines BPM Evangelisten: 10 Jahre).
Wer sich das aber mal ansehen möchte kann bei SAP eine Trial-Version herunterladen.
Wenn Scrum zu eng wird - agil in größeren Projekten
Ist das ein Widerspruch? Es entsteht der Eindruck, das Scrum und herkömmliches Vorgehen einander nicht vertragen. Bernd Österreich bezeichnet Scrum als die Anti-These zur starren alten "Wasserfall"-Vorgehensweise, die noch zeigen muss, ob sie den Wertewandel einleitet oder nur ein Hype ist.
Aber das alte System hat Schwächen. Kaum ein Projekt läuft Problemlos. Wer aber das Alte kennt und das Neue ausprobiert, kann aus der Kombination weiterkommen. Sein Vortrag läuft darauf hinaus, dass man zum Beispiel das Anforderungsmanagement (AM) in Scrum übernimmt um das Backlog zu befüllen. Prinzipiell funktioniert Scrum auch ohne AM durch die eigenen Mechanismen der Retrospektive, aber erst im Laufe der Iterationen und Realisierung. Einfacher und planbarer wird es aber durch eine vorgeschaltete AM.
Practical Polyglot Programming: Groovy, Scala, JRuby, Jython and Clojure
Dieser Vortrag klang sehr interessant, brachte mir aber leider nichts, da der Speaker ein sehr schwer verständliches gebrochenes Englisch sprach und viel zu schnell mittels Eclipse durch seine Sourcen sprang. Alle 30 Sekunden verabschiedete sich ein Zuhörer durch Verlassen des Raumes und schließlich habe auch ich nicht durchgehalten.
Nach soviel Input kam ich nicht mehr dazu alles sofort zusammenzufassen. Deshalb etwas verspätet die Infos im Blog.