SOA und IBMHeute hatten wir zusammen mit IBM das Vergüngen, eine Veranstaltung zum Thema SOA zu machen. Ich habe den konzeptionellen Überblick gegeben und Norbert Bieberstein von IBM sprach dann anschließen über IBMs Lösungen in diesem Bereich. Er hat ein Buch über SOA geschrieben und ist einer der Köpfe im Bereich SOA bei IBM. Inhaltlich war es also auf jeden Fall gut und auch die Location war cool: Wir waren in Udo Lindenbergs Privatkino im Hotel Atlantic in Hamburg. Also: Gelungene Veranstaltung...
Tutorial: LSDNein, nicht das, was man denken könnte, sondern Lean Software Development. Das Turtorial wurde von Mary Poppendiek selbst durchgeführt, die auch das dazu passende Buch geschrieben hat. Das interessante ist, dass sie eigentlich aus dem Management von Produktions-Prozessen kommt. Sie war lange bei 3M beschäftigt und stand dort stark unter dem Einfluss von Lean Production, dass im weiteren zu Just-In-Time und Supply Chain Management geführt hat. Gleichzeitig ist ihr aber auch völlig klar, dass Produktion anders ist als Software-Entwicklung, denn das ist ja eher Produkt-Entwicklung.
Ihre Ideen sind sehr interessant und machen einen gut durchdachten Eindruck. Das ganze ist mir vor allem sympathisch, weil es nicht ein Ansatz wie XP ist, wo einige Techniker sich überlegen, was funktionieren kann, sondern hier werden erfolgreiche Prinzipien eines Bereiches auf einen anderen übertragen. Da die unterschiedlichen Bereiche auf Management-Ebene ähnlich sein sollten, kann man also durch die Erfolge zum Beispiel bei Toyota sehen, dass es funktionieren sollte.
Monitoring und Management in Java 5In diesem Vortrag ging es um die JMX Features, die in Java 5 eingebaut sind. Es ist nun möglich, zahlreiche Werte aus der JVM über JMX abzurufen und auch dynamisch Änderungen durchzuführen. Im wesentlichen werden dabei Speicher, Garbage Collection und Threads zugreifbar
Mit JDK 5 wird auch JConsole als JMX Client ausgeliefert. Wenn man nun nooch die Anwendung mit -Dcom.sun.management.jmxremote startet, kann man gleich starten und einen Blick auf die JVM werfen. Auf Mac OS X funktioniert es allerdings leider nicht...
The Roots of ScrumIn diesem Vortrag sprach Jeff Sutherland über die Herkunft von Scrum. Er ist an verschiedenen Projekten beteiligt gewesen, Dazu gehört Quattro Pro, das wohl eine exorbitante Produktivität erreicht hat, aber auch Easel oder iRobot, ein automatischer Staubsauger.
Scrum ist inzwischen recht groß: Es gibt 1000-2000 zertifizierte Scrum Master. Geht man davon aus, dass es zusammen mit den nicht-zertifizierten 10-mal soviele sind, kommt man auf 10000-20000.
Der Ursprung von Scrum ist Toyota. Eine der Ideen von Toyota ist es, der Gemeinschaft zu helfen. Außerdem wollen sie Qualität, Variabilität und niedrige Kosten alle gleichzeitig erreichen. Auf Software übertragen bedeutet dies, dass man Qualität, niedrige Kosten und hohe Geschwindigkeit alle erreichen kann.
Allerdings basiert Scrum auch nicht auf Command and Control, sondern auf Selbstorganisation. Das Team darf sich selbst organisieren. Google scheint hier ein Beispiel zu sein. Das Motto: Don't wait to be managed. Und: If you fail, fine. On to the next idea.
Ziel bei Toyota ist Ba. Dies ist ein gemeinsamer Kontext, in dem Individuen miteinander interagieren können. Dazu gehört Liebe, Führsorge, Vertrauen und Commitment. Ein wesentliches Prinzip ist es, nur Dinge zu tun, die sinnvoll sind, um das Produkt auszuliefern.
Es gab dann eine Folie zum konkreten Scrum mit Sprints, Meetings und ScrumMasters usw.
Sein nächster Schritt ist es, mehrere überlappende Sprints gleichzeitig durchzuführen je nach Problem, dass man gerade bearbeitet (Bug Fix, Feature, ...)
Azul: Java Performance ExplainedIn diesem Blog habe ich schon über Azul berichtet: Die Firma baut einen Mulitprozessor Server für Java Anwendungen, der verhältnismäßig billig ist, bis zu 384 Prozessoren verträgt und Synchronisierung und Garbage Collection sehr geschickt implementiert, so dass die Performance der Anwendungen sehr positiv beeinflusst wird.
In diesem Vortrag ging es jedoch um ein ganz anderes Thema: Welche falschen Java Performance Tipps gibt es? Dabei kommt es vor allem darauf an, dass man mehrere JVMs vergleicht, den ein Trick, der auf einer JVM etwas bringt, kann auf einer anderen JVM ein Nachteil ergeben.
Die Ergebnisse:
- Exceptions, um eine Schleife zu verlassen, sind teuer. Das ist recht klar, da das Werfen von Exceptions eben teuer ist.
- Klassen oder Methoden final zu machen, bringt praktisch nie einen Vorteil
- try / catch hat meistens keine Kosten
- Es gibt anscheinend Leute, die statt einem virtuellen Methoden Aufruf mit instance_of den Typ des Objekts abfragen oder gar dafür eine Instanzvariable einführen, die je nach Typ des Objekts anders gesetzt ist. Das bringt keinen Vorteil, aber unwartbaren Code...
- Synchronisation kostet 55-110 ns, wenn keine Contention (=paralleler Zugriff) vorkommt. Das ist also nicht so viel.
- Objekt Pooling bringt auch bei großen Objekten nichts. Der einzige gute Grund für Pooling sind also Objekte, die extern Ressourcen allokieren, so dass die Erzeugung wirklich teuer ist
- In Java 5 sind foreach, Autoboxing und varargs tatsächlich nicht nachteilhaft. Bei Enums führt jedoch ein .values() zu einem Clonen des Arrays der Werte, was deutlich suboptimal ist. Allerdings wird hier wahrscheinlich früher oder später ein Fix kommen.
Es gab dann noch den Tipp, dass Garbage Collection von der JVM abhängig ist, so dass Feintuning auf einer anderen Maschinen zu Problemen führen kann. Synchronisierung hingegen wichtig, weil man in Zukunft deutlich mehr Multi CPU Maschinen haben wird, so dass Fehler durch fehlende synchronized zunehmend ein Problem werden.
Zum Abschluss gab es als finalen Tipp, dass JVMs sauberen Code favorisieren: Sie sind eben darauf optimiert, den Stil zu unterstützen, der am häufigsten verwendet wird, damit möglichst viele was davon haben. Und die andere Nachricht ist, dass Optimierungen eben JVM spezifisch sein können, so dass man wegen Portabilität aber auch wegen zukünftigen JVMs vorsichtig sein muss.
Dynamically Typed Language on the Java PlatformDas ganze fing schon mit dem Titel des Vortragenden Gilad Bracha an: Computational Theologist.
Sun selbst findet es sinnvoll, auf die Java Plattform andere Sprachen zu bekommen: Zum einen, weil man damit bestimmte Sachen eben einfacher hinbekommen kann und zum anderen, weil man dadurch eine breitere Community erreichen kann. Seiner Meinung nach ist es für eine sinnvolle Unterstützung von dynamischen Sprachen notwendig, Byte Code um dynamische Methodenaufrufe zu ergänzen.
Heute schon existieren Skripting Sprachen wie Jython, Kawa, Groovy oder ECMAScript (aka JavaScript). Das Problem ist aber eben, dass die JVM Einfachvererbung, single Dispatch und statisch getypte Sprachen unterstützt, während Scripting Sprachen typischerweise dynamisch typisiert sind und Mehrfachvererbung nutzen.
Im Bytecode gibt es folgende Instruktionen für einen Methodenaufruf:
- invokevirtual für einen "normalen", dynamisch gebundenen Methodenaufruf
- invokeinterface für den Methodenaufruf an ein Interface
- invokestatic für statische Methoden
- invokespecial für Konstruktoren, private Methoden usw.
In der VM wird für einen Methodenaufruf alles gemacht, bis auf das Auflösen von Methoden, die mit unterschiedlichen Parametertypen überladen sind, und Generics sind auch im javac.
Für den Methodenaufruf in einer dynamischen Skripting Sprache scheint invokevirtual eine gute Idee zu sein. Das Problem ist jedoch, dass man dazu Klassen- und Methodensignatur angeben muss. Und der Byte Code Verifier kontrolliert auch, ob die Typen korrekt gesetzt sind.
Nun hat man das Problem, dass man Typen in dem Methodenaufruf angeben muss, obwohl die Sprache nicht typisiert ist. Heutige Implementierungen verwenden dazu offensichtlich eine große Anzahl generierter Interfaces. Das führt zu ineffizientem Code und zu komplexem Code. Also muss man ein invokedynamic haben, bei dem man die Typen nicht angeben muss.
Trotzdem hat man immer noch das Problem, dass man das Überladen von Methoden auflösen muss. Dazu verwendet Java den javac Compiler, was für Skriptsprachen nicht geht, da die Typinformationen nicht statisch vorliegen. Es muss aber gelöst werden, weil man sonst Java Bibliotheken, die Überladen verwenden, nicht aufrufen kann. Die Lösung soll hier ein Trap sein, der ausgelöst wird, wenn dieses Problem auftritt. Der kann dann von der Luafzeitumgebung der Sprache geeignet behandelt werden.
Beim Thema Unterstützung von Mehrfachvererbung haben wir dann die Abkürzung OMDB kennengelernt: Over My Dead Body.
Ingesamt ein sehr unterhaltsamer Vortrag, der zeigt, dass Sun in dieser Richtung auf jeden Fall etwas tun will.
Microsoft Keynote: Tools for Architects & Future Directions in ModelingIn dieser Keynote stellt Microsoft im Prinzip wieder einmal ihren Ansatz zum Thema Software Factories vor. Allerdings gab es einige interessante Details.
Der Vortrag fing mit dem Thema an, dass man die typischen Rezepte in der Software Entwicklung automatisieren will. Der Prozess ist das Problem und manchmal muss man extrem viele Artefakte bauen. Der Vortragende ging auch auf den Chaos Report von der Standish Group ein, der ja bekanntermaßen einen hohen Anteil an schief gegangenen Großprojekten konstantiert.
Das ganze soll die Motivation für Software Factories sein. Dabei sollen eben statt Economy of Scale (Massenproduktion gleicher Sachen) Economy of Scope (vereinheitlichte Produktion ähnlicher Sachen) genutzt werden. Dazu werden Domain Specific Languages verwendet werden. Dazu sind Domain Specific Languages notwendig. Neu war die Notation von Domain Specific Processes.
Für Microsoft läuft dies auf ein Customizing der IDE hinaus, aber auch Process und Porject Management Sachen sollen in dem Tool sein. Das erinnert ein wenig an das, was Ivar Jacobson in seiner Keynote sagte.
Das Tool bringt dann viele Viewpoints wie Requirements, Deployment oder Orchestration. Außerdem ist die Integration eigener DSLs relevant.
Es schloss sich dann eien Visual Studio 2005 Demo an. Das ganze war recht elegant und war vor allem eine High-Level-Architektur mit der Definition von Komponenten und dem Deployment der Anwendung. Das ist natürlich in Java auch möglich, aber ich habe das Gefühl, dass es dort nicht so elegant ist und auch nicht vereinheitlicht. Es gibt eben Eclipse GEF/EMF, die Netbeans Ansätze, die Dinge von intelliJ, OpenArchitectureWare und verschiedene UML basierte Ansätze wie AndroMDA.
Visual Studio hat eine eigene Engine für die ganze Sache. Durch das DSL Tool erwartet Microsoft einen neuen Markt mit eigenen DSLs, wie das auch schon bei den Komponenten der Fall war.
Es schloß sich eine Demo an, bei der gezeigt wurde, wie man UML Use Case Diagramme und Aktivitäts Diagramme selbst als DSL definieren kann. Das führt natürlich zu der Frage, warum man das nicht direkt in die Plattform integriert hat. Eine Firma namens Statesoft soll auch schon eine eigene DSL als Produkt haben.
Die Zusammenfassung war dann, dass man mit diesem Verfahren das Wissen konsolidieren kann. Dadurch Dadurch soll sich Produktivität, Vorhersagbarkeit und weniger Kosten und Risiken ergeben. DSLs beuten Gemeinsamkeiten aus und unterstützt Veränderlichkeit.
Die wichtigste Sache aus dieser Keynote war für mich, dass Microsoft immer noch DSLs als sehr wichtig ansieht. Und die Qualität der Tools ist recht gut - von daher ein sehr guter Weg. Schauen wir mal, wo das hingeht, und wie Java darauf reagiert.
BPM / JBossEin Mitarbeiter der JBoss Group sprach dann über Business Process Mangement. Einige Impressionen: Er sagte, dass in OO Sprachen für Business Process vor allem die Möglichkeit fehlt, den Zustand der Ausführung eines Programms persistent zu machen. Und auch die Möglichkeit zum Warten fehlt. Genau dass erreicht mat mit orthogonal persistenten Systemen wie PJama oder Tycoon: Man kann einfach einfach den Zustand einer VM persisten machen inkl. Threads. Das sollte da also helfen, wir aber wohl doch nicht die Research Labs verlassen, wo es ja schon 10 Jahre oder so liegt....
Eine interessante Abgrenzung wearen Pure Play BPM, die wirklich Geschäftsprozesse managen, und Integration Broker Suites, die Software integrieren. Das klärt, warum es Workflow-Systeme gibt und dann die ganzen Integrationslösungen.
Er wurde auch nicht müde, darauf hinzuweisen, dass BPEL ungünstig sei. Seiner Meinung nach braucht man eine grafischere Notation.
Heute...Den heutigen Tag habe ich vor allem mit meinem beiden Vorträgen und dem Vorbereiten derselben verbracht. Heute vormittag habe ich über Simple Java EE gesprochen einschließlich einer kleinen Live Demos. Solche Demos müssen immer besonders gut vorbereitet sein, damit dann auch nichts schief geht. Es ging dann auch alles glatt und ich glaube, dass es auch einigen Anklang gefunden hat, zumindest ist das Feedback entsprechend. Danach habe ich dann über "Java Performance - Tips and Tricks" gesprochen. Das war vor einem kleineren Publikum und ohne Demo, aber auch hier gab es gutes Feedback.
Ivar Jacobson: Beyond Agile - SmartWohl kaum jemandem hat die OO Community mehr zu verdanken, als meinem Gegenüber beim gestrigen Abendessen und dem heutigen Keynote Speaker: Ivar Jacobson. Er hat den Use Case erfunden und viele andere, extrem wichtige Sachen im OO Bereich. Und heute wollte er uns den Nachfolger der Agilität zeigen: Eben Smart.
Er fing die Präsentation mit der These an, dass Software passiv ist: Man selber muss aktiv sein und sie benutzen. In Zukunft soll Software aktiv sein. Das scheint erstmal nichts mit Vorgehensmodellen zu tun zu haben, aber der Zusammenhang wird später noch deutlich.
Auf der anderen Seite ist es so, dass Software Entwicklung eben eine Menge Wissen vorraussetzt. Agilität setzt dabei eher auch das Wissen im Kopf, während der Unified Process (UP) eher auf explizites Wissen in Büchern oder Dokumenten setzt. Seiner Meinung nach ist dadurch ein agiler Prozess möglicherweise schwergewichtiger, da man mehr diskutieren muss als bei UP.
Im nächsten Schritt sagte er über das
Agile Manifesto, dass es so allgemein sei, dass jeder damit übereinstimmen würde. Außerdem stellt er die Behauptung auf, dass der UP explizite Regeln für die Qualität hat und dadurch die Qualität von Requirements, Design usw. sichergestellt werden kann. Er hob noch hervor, dass UP ein Prozess Meta Modell ist: Ein Modell, um Modelle von Prozessen zu erzeugen. Das ist als OMG SPEM standardisiert. Außerdem sagte er, dass nur 10% aller Entwickler UP machen werden, weil eben so ein großes Investment ist.
Also: Wie bekommt man es hin, dass man das Wissen in UP einfacher anwendbar macht? Nur das benötigte Wissen präsentiert bekommt. Man würde also nichts an UP ändern, sondern nur dafür sorgen, dass das Wissen besser verfügbar ist. Man kann dann einzelen entscheiden, was man genau tut.
Der Prozess läuft dann versteckt ab und ist nicht mehr etwas, womit man sich explizit beschäftigen muss. Seine Idee ist, dies durch intelligente Agenten zu bewerkstelligen: Die haben das komplette Wissen über den Prozess und präsentieren es, wenn es notwendig ist.
An dieser Stelle hatte ich eigentlich Zweifel, wie ich es bei den meisten KI Sachen habe. Aber im Prinzip haben wir das schon: Wenn man Eclipse nutzt, zeigt es einem, wo man Fehler im Code hat und Command+1 (für Windows: Ctrl/Strg+1) fixt es dann. Das ist genau dieses Modell. Ob man das auf Prozesse übertragen kann, ist dann die Frage.
Weiter Info gibt es bei
http://www.ivarjacobson.com/ oder
http://www.jaczone.com/.
SOA und WMWareAuch VMWare fand sich im SOA Track. Das ist überraschend, denn die Firma baut eigentlich Virtualisierungslösungen für PCs und Server - Was hat das mit SOA zu tun?
Die Antwort ist recht einfach: Wenn man einen Dienst mit einem Service Level Agreement (SLA) absichert, in dem man eine bestimmte Qualität des Services zusichert, ist Virtualisierung eine gute Idee. Dadurch kann man die Anwendung leichter von Rechner zu Rechner übertragen oder Server konsolidieren. Außerdem wird es so möglich, Server Appliances, also Rechner, die gleich die Anwendung installiert haben, auf eine andere Art und Weise auszuliefern und auf vorhandenen Systemen zu installieren. In dem Vortrag wurde außerdem darauf hingewiesen, dass man mit VMWare auch gleich ein ganzes Netzwerk von Rechnern installieren kann, was die heutigen komplexen Szenarien entschärft und auch zum Beispiel einfacher testbar macht.
Eine interessante Vorschau gab es dann noch auf die Zukunft: In Zukunft wird VMWare ein Netz-weiten Resource Pool anbieten, der aus den im Netzwerk bereitstehenden Servern besteht. Dadurch kann Fail Over und Load Balancing auf Ebene der Virtualisierung erledigt werden: Aus dem Pool werden dann eben andere oder mehr Ressourcen zugeteilt. Das ist eine recht coole Sache, die an die verteilten Betriebssysteme wie Plan 9 erinnert. Außerdem denke ich (und hoffe ich), dass es diesmal nachhaltig klappt...
SOANicolai Jossutis sprach dann über SOA Erfahrungen in einem konkreten Projekt. Zunächst sagte er, dass in diesem Projekt nicht etwa Web Services verwendet werden, was ja sonst oft fast synonym für SOA ist, sondern Tibco. Dadurch komment man zu einem zentralen Bus.
Im weiteren gab er konkrete Erfahrungen aus seinem Projekt. Er versucht zunächst, starke Typisierung bei den Aufrufen der Services durchzuhalten, um beim Compilieren schon passende Fehlermeldungen zu bekommen. Das führt aber auch zu starken Abhängigkeiten, weil man nicht einfach einen Parameter ergänzen kann, da dies dann die Typisierung bricht.
Versionierung und Granularität sind dann weitere Themen. Bei der Granularität gibt es offensichtliche Unterschiede zwischen einer Integration der gesamten Geschäftslogik der Firma und z.B. der Abtrennung einer GUI von der Geschäftslogik.
Generell sieht er das Problem, dass Services schwer änderbar sind, da sie von vielen Client genutzt werden. Dadurch kommt man in einen Konflikt mit den von ihm favorisierten agilen Vorgehensweisen. Da die Services nicht änderbar sind, kommt man automatisch in ein weniger agiles Modell.
Schließlich sieht er auch bei Performance ein Thema: Wenn man statt einem direkten Datenbank-Zugriff eine SOA Infrastruktur bemüht, ist man teilweise eine Größenordnung schlechter.
Ein Fazit: SAO macht es einfach, Dinge kompliziert zu machen. Vor allem werden Abhängigkeiten versteckt und dadurch kann man dann in eine schwer zu managende Situation kommen, weil man nicht weiss, was man ändern kann.
Er zog noch eine interessante Parallele zu OO: Auch die Einführung von SOA war scher und auch OO skaliert nicht - erst durch Komponenten kann man große Systeme bauen. Das ist bei Services möglicherweise ähnlich.
Ingesamt ein interessanter Vortrag, der gezeigt hat, dass SOA ohne Web Services geht und wie man es in der Praxis beispielsweise umsetzen kann und was man für Probleme dabei hat.
ObjectScriptMeine Erwartung war, hier eine weitere interessante Skript Sprache für die Java Plattform zu sehen. Ich hätte eigentlich bei der Herkunft des Speakers erkennen sollen, dass das nicht so sein wird. Er kam von der Firma Intersystem, die mit Cache eine Datenbank im Programm haben, die sich postrelational nennt und eine sage wir mal lange Historie hat.
Im Rahmen des Vortrags wurde dann deutlich, dass auch ObjectScript diese lange Historie hat. Es ist nämlich von der Sprache M bzw. MUMPS abgeleitet. Diese wurde irgendwann in den 70er entwickelt und was ich noch nicht wusste: Sie ist tatsächlich nach der Krankheit benannt. Ich kenne viele Sprachen, die eine Krankheit sind, aber sich danach bennen? Wie dem auch sei.
Sie kann direkt interpretiert werden oder in P-Code compiliert werden und sie ist schwach typisiert. Soweit keine Überraschungen. Die gibt es dann in Folge von impliziten Typ-Konvertierung dann aber in der Sprache selbst. Ein kleiner Quiz?
Was ergibt 2+3*2? Richtig: 10. Denn ObjectScript kennt kein Punkt vor Strich, sondern geht von links nach rechts vor.
Und 2>10+2? Richtig: true. Denn 2>10 ist false. false ist 0. 0+2 ist 2 und das ist true.
Neben diesem "Feature" biete ObjectScript noch multi-dimensionale Arrays auch mit Strings als Keys an. Diese können dann einfach persisten gemacht werden und dabei funktionieren auch Transaktionen und Locks.
Das OO System unterstützt Mehrfachvererbung. Eine coole Sache ist, dass man zur Laufzeit neuen Code generieren kann und ihn ausführen lassen kann. Außerdem gibt es eine SQL Integration.
Ingesamt habe ich keinen Appetit auf mehr bekommen und es ist eben auch ein proprietäres Produkt, was mich nicht unbedingt davon überzeugt, mich tiefer damit zu beschäftigen.
Patterns
Markus Völter hielt einen Vortrag über die Verwendung von Pattern in der Software-Entwicklung heutzutage. Dabei war die erste wesentliche Aussage, dass Patterns selber kein Hype mehr sind. Bücher nutzen Patterns zur Darstellung, aber sie nennen den Begriff Patterns nicht mehr im Titel. Außerdem gibt es fachliche Patterns, die für bestimmte Domänen interessant sind. Dadurch sind sie eben nicht mehr generell relevant und sie werden zum Teil auch gar nicht veröffentlich, weil sie eben Spezialwissen der Firmen enthalten, die ein Teil des Wettbewerbsvorteils der Firma sind.
Markus hat dann die Remoting Patterns als Beispiel vorgestellt. Seiner Meinung nach kann man mit solchen Patterns ein tiefes Verständnis über den jeweiligen Bereich erreichen. Außerdem kann man so Best Practicses vermitteln und Struktur von Systemen klären.
Es gab dann eine kurze Diskussion zum Thema Dependency Injection und Spring. Es wird eben zur Zeit nicht als Pattern wahrgenommen. Warum das so ist, blieb allerdings offen. Interessant war auch, dass der Begriff Dependency Injection trotz des Hypes immer noch recht wenig weit bekannt ist.
Ein weiteres Thema war die Verwendung von Patterns in Tools. Nach Markus Darstellung ist es dann nur eine Lösung und noch nicht mal das, es ist oft nur eine Struktur. Beim Observer Pattern werden nur Subject und Observer festgelegt, aber nicht, was genau beobachtet werden soll und wann. Natürlich kann man das Pattern in AOP direkt umsetzen, aber Markus hob dann (wenig überraschend) auf eine Implementierung im Rahmen einer MDA Infrastruktur ab.
Dabei ergeben sich einige interessante Konsequenzen: Der Entwickler des Code Generators hat die konkrete Implementierung in der Hand. Eventuell ist noch nicht einmal klar, dass es um das erwähnte Pattern geht. Beim Observer könnte z.B. nur das Verschicken von Events sichtbar sein, dass aber ein Observer verwendet wird, ist nicht sichtbar und es kann sogar sein, dass statt des Observers eine statische Struktur verwendet wird, wenn dies ausreicht.
Als Seitennotiz sagt Markus noch, dass die "Schönheit" des generierten Codes durchaus relevant ist, weil man beim Debugging und beim Entwickeln des Generators damit Kontakt hat.
Ein weiteres Thema war das Selbst-Schreiben von Patterns. Markus Meinung nach verbessert es die Kommunikation und den Stil der Kommunikation.
Auch Architektur Patterns sind seiner Meinung nach wichtig, da sie wesentliche Orientierungs-Punkte für Architekturen sind. Relevant ist hier vor allem das POSA Buch.
Sein Fazit: Patterns sind überall. Es gibt nur noch wenig Hype, und wo es Hype gibt (Tools), sind Patterns eher unwichtig. In den nicht gehypten Bereichen (z.B. MDA) sind Patterns hingegen sehr nützlich.
Die Frage-Runde war fast schon deprimierend: Wie führt man Patterns in Organisationen ein sollte 10 Jahre nach dem GoF Buch eigentlich kein echtes Thema mehr sein. Die Realität ist offensichtlich anders...
The Joy of ScriptingDave Thomas gab hier eine Einführung in Skripting Sprache. Dabei gab er als Einsatz-Szenarien Automatisierung, Konfiguration, Glue Code, Prototypen und mittlerweile auch ganze Applikationen an. Er bezeichnet Skripting als "Gentle Slope Porgramming", als Programmierung mit einer wenig steilen Lernkurve. Interessanterweise ist er der Meinung, dass Frameworks wie Zope (für Python), Rails (für Ruby) und PHPNuke (für PHP) die wirklichen "Seller" für die Skriptsprachen sind. Dadurch kommt man zu einer Schichtenarchitektur: Oben das Framework, dann die Sprache, darunter die Sprach-Engine und schließlich das Betreibssystem. Damit verstecken Skriptsprachen die Komplexität auf Ebene des Betriebssystems.
Er führte auch noch eine Unterscheidung nach Prototyp-basierten Skriptsprachen und Klassen-basierten Skriptsprachen ein. Die Klassen-basierten haben Klassen als Quelle neuer Objekt-Instanzen, die Prototyp-basierten klonen Objekte.
Und der Link aus dem Talk ist
Damgecontrol: Ein generisches Build Tool.
JAOO Keynote Open Source von SunDie erste Keynote auf der JAOO wurde von Simon Phipps (Chief Open Source Officer, Sun) gehalten. Er war vorher bei IBM für Java zuständig...
Der Beginn war das nicht anders zu erwartende bei Sun: Wir sind im Participation Age und nicht mehr im Consumer Age. Dadurch ändern sich einige Sache: Security Thema ist die Digital Identity, SOA kommt (aber WS-* ist überbewertet), Software wird auf Basis des Werts abgerechnet und Märkte werden zu Conversations (siehe
The Cluetrain Manifesto). Sun hat mit den eigenen Blogs offensichtlich positive Erfahrungen gemacht: Es führt zu mehr Transparenz und damit zu mehr Vertrauen.
Open Source ist auch ein Vertreter dieser Bewegung, die eben Software öffnet. Vor allem bietet Open Source den Vorteil, dass man wählen kann: Brauch man nur die Software oder auch Support usw.? Eine Abhandlung darüber soll
Coase's Penguin sein.
Wesentlicher Punkte ist, dass die Open Source Community Werte erzeugt und damit auch Geschäftsmöglichkeiten. Dabei kann man jedoch jeweils nur den Unterschied zwischen der allgemein verfügbaren Open Source Software und der eigenen Arbeit berechnen.
An dieser Stelle sprach er auch von dem Gatekeeper, der kontrolliert, was in die Code Basis zurück geht. Das ist natürlich allgemein bekannt, aber trotzdem recht interessant, weil ich genau dieses Verfahren normalerweise ablehne, weil es nicht skaliert: Man kann nur soviel Software bauen, wie der Gatekeeper verarbeiten kann. Darüber muss man also nochmal nachdenken.
Open Source ist in erster Linie die Freiheit zu entwicken. Für den Benutzer ist allerdings die Freiheit in der Verwendung wichtiger. Das kann er jedoch nicht nur mit Open Source erreichen, weil er dann an das Open Source Produkt gebunden ist. Erst mit Interoperabilität, Standards und Open Source kommt er zum Ziel.
Das Geschäftsmodell umfasst dabei nicht nur Services, sonder auch andere Dinge: Es geht im wesentlichen nur darum, dass man eine gemeinsame Basis hat, die nichts kostet, und dann in den Differenzierungsaspekten im Wettbewerb steht.
Er führte dann Solaris als Fallstudie aus. Dabei stellte er klar, dass Solaris aus seiner Sicht nicht mit Linux konkurriert, weil beide sehr unterschiedliche Communities haben.
Er zeigt dann auch noch eine Folie zum Thema Java und Open Source. Dabei stellte er klar, dass z.B. bei Java EE Open Source sehr weit verbreitet ist. Auf die Frage, ob man das Java Runtime Environment Open Source machen soll, gibt es zwei Antworten aus seiner Sicht: GNU Classpath ist schon verhältnismäßig weit und Apache Harmony wird die JVM dazu bauen. Außerdem würde er lieber Java SE 6 als Open Source sehen als dass man Java SE 5 noch Open Source macht und dafür Ressourcen verbraucht.
Ingesamt hat mir der Vortrag recht gut gefallen. Ich habe jetzt verstanden, dass Sun mit OpenSolaris in Zukunft möglicherweise besser dasteht als IBM mit AIX, weil sie auf gleicher Ebene mit Linux konkurrieren: Beides sind Open Source Produkte und man kann daher mit dem Betriebssystem eh kein Geld mehr verdienen, sondern nur noch mit darauf aufbauenden Dingen.
Vorwarnung: JAOO Konferenz
In der nächsten Woche bin ich in Dänemark auf der
JAOO Konferenz. Ich bin schon gespannt, was es da alles interessantes zu sehen gibt. Ich selber spreche zum Theme "Simple Java EE" und "Performance: Tips & Tricks". Ich werde hier im Blog über die Konferenz berichten, was dann zu erhöhtem Posting-Aufkommen führen kann... :-)
Die Erkenntnis des Tages...
...kommt aus der Computer Zeitung aus einem Interview mit Prof. Gunter Dueck, seines Zeichens Chief Technologist, IBM Globale Services Germany (die anderen Titel erspare ich mir) und Kolumnist im Informatik Spektrum.
In dem Interview stellt er fest, dass der Druck zum Überleben und die daraus entstehende Not analog ist zu dem Verhalten jener, die in der Schule auf die Zahlen achten und immer eine Vier hatten. Auf eine Eins zielen aber Erfinden und Nachdenken - und kein Überlebensdruck. Die Eins bekommt man nur durch Innovationskultur.
Ich hatte erst gedacht, dies sei ein Gegensatz zu Maliks Idee, dass
Arbeit nicht unbedingt Spass machen muss, aber das ist nicht der Fall. Aber Malik hat zum Thema Innovation unter anderem gesagt,
dass man vom Markt kommen muss, was zumindest noch eine gute Ergänzung ist.
Auch das andere Ufer...
Wie man
hier sehen kann (unter Enterprise / Java .NET), ist in der aktuellen Ausgabe des dot.net Magazins mein Artikel zum Thema Migration von Java Code in Richtung .NET erschienen. Microsoft bietet hier verschiedene Werkzeuge an, die einen bei der Migration unterstützen. Der Artikel vergleicht die Ansätze und zeigt Vor- und Nachteile auf.
Testen, DI und EJBs
Interessanterweise ist es immer noch schwer, die DI Vorteile wirklich plastisch darzustellen. Zur Verdeutlichung sollte man sich nochmal EJB 2.1 vergegenwärtigen. Wie teste ich dort eine Anwendung? Die entscheidene Frage ist vor allem, wie ich Unit Tests umsetze. Dort kann ich die Anwendung in einen Application Server deployen. Schon dieser Vorgang alleine dauert länger, als ein Unit Test dauern sollte - keine gute Idee.
Also muss ich mir etwas anderes einfallen lassen. Ich sollte die Anwendung zwischen Technologie (EJB) und Logik aufteilen. Dazu gibt es Ansätze wie den Business Delegate, an den ich die Aufrufe der EJBs delegieren. Das ist fast gut, impliziert jedoch entweder den Gebrauch eines Generators oder viel Code Duplikation. Na ja, aber ich habe jetzt meine normalen Java Objekte, die ich mit JUnit einfach testen kann. Übrigens habe ich hier bei bei Entity Beans mit EJB 2.1 ein echtes Problem, denn die wesentliche Eigenschaft (Persistenz) ist außerhalb eines Application Servers nicht testbar. Sicherheit kann ich ebenfalls nicht testen, ist aber für Unit Tests nicht relevant. Transaktionen wären vielleicht relevant, aber sind hier auch nicht testbar. Schlimmer ist, dass ich alle Ressourcen, auf die mir ein Application Server Zugriff bietet, nur über JNDI erreichbar sind. Hier kann ich einen Service Locator verwenden, in den ich alle JNDI Zugriffe auslagere. Wenn ich testen will, schiebe ich dem Service Locator einfach Testobjekte unter. Die andere Möglichkeit ist es, direkt im JNDI andere Objekte zu registrieren und eine JNDI Implementierung außerhalb des Application Servers zu nutzen.
Soweit ist das Vorgehen auch ein "offiziell authorisiertes" EJB Vorgehen, will heißen: Jeder gute EJB Consultant empfiehlt es. Dependency Injection geht hier nur einen kleinen Schritt weiter, indem es den Service Locator durch eine Infrastruktur ersetzt, die den einzelnen Java Objekte die Referenzen auf Ressourcen zuweist, statt dass die Objekte sie selber heraussuchen müssen. Was das bedeutet? Dependency Injection ergibt sich fast zwangsläufig aus dem Anspruch, EJB Anwendungen testbar zu machen. Schon diese Argumentationskette reicht meiner Meinung nach als Begründung für DI aus. Wer EJB 2.1 Anwendungen ohne Application Server testen will, landet fast automatisch bei normalen Java Objekten und DI.
Die Frage ist nun, ob man eine solche Infrastruktur selber schaffen will, oder ob man nicht ein kostenloses Open Source Framework wie z.B. Spring verwendet. Zusätzlich ist es in Bezug auf Transaktionen von der Umgebung unabhängig, so dass man auch dies in einem Kontext ohne Application Server z.B. mit einer In-Memory Datenbank wie HSQL testen kann, wenn man mit Datenbank testen will. Übrigens ist genau dies auch der Grund, warum Spring eine bessere Lösung ist als EJB 3: Die Transaktionen in EJB 3 sind für EJB Umgebungen definiert, was im Moment bedeutet, dass sie nur auf Application Servern funktionieren. Spring Transaktionen gehen auch mit einfachen JDBC Connections...
Ist also DI nur eine Erleichterung für Tests? Meiner Meinung nach nicht, weil es auch eine flexilblere Architektur bietet, in der man einfacher Services als einfache Java Objekte komponieren kann und vorgefertigte Konfigurationsmöglichkeiten bekommt. Außerdem sind Techniken wie Spring AOP erst so möglich und auch den Export als Web Services oder per RMI erleichtert das Modell. Also: DI ist mehr als "nur" einfache Testbarkeit, aber Testen reicht meiner Meinung nach als Begründung für DI schon aus.
Vortrag Simple Java EE bei der XP User Group Hamburg
Wie man
hier sieht, werde ich am 15.9. ab 19:00 einen Vortrag zum Thema Simple Java EE bei der XP (nicht Windows XP, sondern eXtreme Programming) User Group Hamburg halten. Ich bin vor allem auf die Diskussion gespannt.
Adrian Colyer geht von AspectJ zu Spring...
Wie man
hier lesen kann, geht Adrian Colyer von IBM zu Interface21. Adrian leitet das AspectJ Projekt, das die wohl umfangreichste Aspekt-Implementierung für Java darstellt. Bei IBM hat er diese Technologie z.B. in WebSphere eingeführt. Sein Wechsel zu Interface21 ist ausgesprochen spannend, weil Spring dadurch wahrscheinlich stärker mit AspectJ integriert wird. Außerdem sind im Spring Umfeld dann die beiden wichtigsten Aspect Implementierungen vertreten: Spring AOP und eben AspectJ. Auf diese Art und Weise kann Spring sich wahrscheinlich an die Spitze der "Middleware Technologie neuen Typus" Bewegung setzen, die auf AOP als Basistechnologie setzt. Gute Nachrichten also!
Plattform Strategien am Beispiel PSP und Java
Ein anscheinend begehrtes neues Technik-Spielzeug ist die Sony PSP (Play Station Portable). Sie definiert tatsächlich die Leistungsfähigkeit mobiler Spielkonsolen neu und ist so eine Art "Playstation 2 Laptop" - ähnlich leistungsfähig, aber eben mobil.
An der PSP kann man recht deutlich die Plattform Strategie der Videospiele Hersteller sehen: Sony versucht durch Firmware Updates zu verhinder, dass man auf der PSP selbstgeschriebene Software laufen zu lassen. Für den Kunden ist dies ein massvier Nachteil: So gab es schon Quake, MAME (ein Emulator für verschiedene Videospiele) und verschiedenes anderes als Software zum runterlafen (z.B.
hier).
Dadurch beschädigt Sony natürlich die Plattform: Der Besitz einer PSP wird weniger attraktiv. Auf den ersten Blick verwundert das, da Sony z.B. für die PS2 sogar ein Linux angeboten hat. Auf den zweiten Blick ist es weniger erstaunlich, denn fast alle Spielkonsolen lassen sich nur mit Mühe dazu überreden, "innoffizielle" Software laufen zu lassen.
Dies hängt mit dem Geschäftsmodell zusammen: Die Hardware selbst ist nicht der Gewinnbringer, sondern die Spiele. Dadurch haben die Hersteller ein Interesse daran, die Plattform so zu gestalten, dass sie möglichst nur auf die eigenen oder offiziell lizensierten Spiele limitiert ist. Nur dann verdienen sie Geld.
In anderen Bereichen ist dies nicht so: Java als Plattform versucht, möglichst offen zu sein und ist dadurch so erfolgreich. Open Source ist Teil des Konzepts und mittlerweile steht der Community Gedanke im Mittelpunkt. Dadurch muss der Business Case entweder sein, an der Plattform selber Geld zu verdienen oder durch Services, die auf der Plattform aufbauend einen echten Mehrwert für den Kunden erreichen.
Beim iPod funktioniert übrigens beides: Auf der einen Seite ist er offen, um auch fremde MP3 Stücke abzuspielen, auf der anderen Seite dient er als Basis für den Verkauf von Musik aus dem iTunes Music Store. Vielleicht sollte man sowas auch mal für Konsolen ausprobieren...
Mac OS X...
Wie man
bei anandtech nachlesen kann, hat Mac OS X offensichtlich ein ernsthaftes Problem vor allem mit Thread Verwaltung, was den Einsatz in Enterprise Umgebungen erschwert (vorsichtig gesagt). Eigentlich erstaunlich, denn das Mach Betriebssystem, auf dem das ganze basiert, sollte solche Sachen ganz gut abbilden können. Was lernen wir daraus? Auch Apple sollte sich wohl auf seine Kernkompetenzen fokussieren und das ist die Benutzeroberfläche. Darwin ist auch schon Open Source. Aber langfristig sollten sie dann wohl auf einen der großen Open Source Kernel umsteigen. Die sind offensichtlich besser optimiert...
Spring in HannoverAm Montag habe ich das Vergnügen, in Hannover bei Arbeitskreis "OOT in Java" zu sprechen. Natürlich über mein Lieblingsthema: Das Spring Framework. Ich bin gespannt, was mich dort erwartet. Die Zwischenfragen und Diskussion machen solche Sachen immer wieder interessant...
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
