Spring Web Flow 1.0 releast
Spring Web Flow 1.0 ist releast worden. Damit kann man komplexe
Abläufe in Web-Anwendungen recht einfach implementieren inkl.
Zustands-Management. Mehr Infos gibt es hier:
http://www.springframework.org/go-webflow
http://www.infoq.com/news/spring-web-flow10
http://www.theserverside.com/news/thread.tss?thread_id=42799
Viel Spaß beim Ausprobieren!
Spring User Group Germany gegründet
Auch in Deutschland hat sich jetzt eine User Group für das Spring Java Framework gegründet. Ziel ist der Austausch von Informationen, Erfahrungen und Meinungen über das Spring Framework und anderen Technologien in diesem Bereich.
Die User Group steht ab sofort unter
http://groups.google.com/group/sugg allen Interessierten offen. Also: Mitmachen - Wir freuen uns auf regen Austausch!
Closures == Inner Classes?
Wie man
hier lesen kann, werden wir in Zukunft in Java Closures haben. Ich ging dort schon darauf ein, dass Closures eigentlich in der Tradition der Inner Classes stehen. Darauf basierend hat
dieses Paper eine Syntax vorgeschlagen, die eine Art Closures als syntaktischen Short Cut für Anonyme Inner Classes einführt.
Ich finde das eigentlich eine gute Idee. Allerdings habe ich das von der Implementierung der Generics gedacht, weile diese (eleganterweise) ohne Änderungen im Bytecode auskommt. Mittlerweile bin ich da nicht mehr so sicher, denn man kann eben über Reflection nicht ermitteln, welcher konkrete Typ gerade an den Parameter gebunden ist. Bei dem Vorschlag für Closures vermag ich allerdings erstmal kein Problem zu erkennen. Auch das leidige final Thema wird angegegangen...
Nächste Konferenz: WJAX
Die nächste Konfernz ist dann die WJAX. Hier die Themen, an denen ich beteiligt bin:
Die WJAX findet wie jedes Jahr in einer sehr schönen Location in München statt und ist eine der wichtigsten Veranstaltungen im Java-Bereich. Also: Wir sehen uns dort...
JAOO 2006: Fazit
Auch dieses Jahr hat mir die JAOO wieder sehr gut gefallen. Es gab eine breite Palette an interessanten Themen, technische und nicht-technisch, Java und .NET usw. Wie schon geschrieben ist ein Ergebnis die nun wieder eher offene Sprach-Frage und ansonsten viele andere Eindrücke, die man so mitnimmt. Mir hat es auf jeden Fall viel Spaß gemacht und ich komme gerne wieder!
JAOO 2006: Rod Johnson: Are we there yet?
Rod sprach dann im Open Source Enterprise Java Track. Der Titel seines Talks kommt von dem "Sind wir schon da?", das Kinder im allgemeinen bei eier langen Autofahrt äußern.
Zunächst ein Rückblick auf 2003: Nur log4j and Struts sind anerkannte Open Source Java Projekte und man hat auf Tools zur Beherrschung der Komplexität gesetzt.
Inzwischen sind wir hier an allen Fronten wesentlich weiter und mittlerweile sieht man Entwickler auch als vollwertige Mitspieler und nicht mehr nur als einfache Implementierer. Und diese Innovationen kamen vor allem außerhalb des JCP-Prozess zustande.
Was wollen wir also noch erreichen? Es geht um die Entwicklung echter OO-Systeme und noch mehr Vereinfachung wie zum Beispiel dynamische Sprachen.
Rod sprach dann darüber, dass bei der Aufteilung in Services und Datencontainer im Prinzip Objekt-Orientierung gebrochen wird, weil man Verhalten und Daten trennt, was in OO-Systemen ja eigentlich zusammen gehört. Mit @Configurable ist es nun in Spring 2.0 möglich, Services in "normale" Domänen-Objekte zu injizieren, so dass man recht einfach eine Art OO-Facade für die Services bauen kann. Rod streifte dann noch die Implementierung von Spring-Beans in dynamischen Sprachen und die Integration von JPA. Schließlich zeigte er die Wichtigkeit von AOP auf und die Probleme, die EJB 3 in diesem Bereich hat.
Der Vortrag zeigte recht deutlich, in welche Richtung die Entwicklung bei uns geht. Gerade mit Spring 2.0 haben wir einen guten Fortschritt erzielt - mal schauen, was uns noch so einfällt...
JAOO 2006: Spring & Patterns
Der Titel meines Vortrags ist leider irreführend: Es geht nicht um den Einsatz von Patterns in einem Spring-Context, sondern um die Patterns, die Spring selber implementiert. Basis dafür ist das
Server Component Patterns Buch, an dem ich mitgewirkt habe und das Patterns "alter" Infrastrukturen wie EJB oder COM+ zeigt.
Im ersten Teil spreche ich dann über Patterns wie Component, Component Interface, Virtual Instance, usw und erläutere dadurch, dass Spring eben ein Komponent-Modell hat, bei dem die Komponenten nicht mehr als Klassen sind. Das Component Interface ist dann nur noch ein Java Interface. Virtual Instance, in EJB durch Pooling von Stateless Session Beans und Entity Beans implementiert, ist zum einen nicht mehr so wichtig, weil neuere JMVs wesentlich weniger Problem mit Objekt-Allokation und -Zerstörung haben und außerdem ist es in Spring generalisiert: Man kann eben jedes Spring-Bean poolen oder in einen ThreadLocal unterbringen. Naming (=JNDI) und Component Home werden durch Dependency Injection abgelöst.
Interessant ist für mich vor allem, dass Component Home ein echter Fehler war: Für Stateless Session Beans und Stateful Session Beans macht es wenig Sinn, man hätte im JNDI auch gleich eine Instanz registrieren lassen können. Für Entity Beans ist es zwar sinnvoll, aber Entity Beans selber sind problematisch. Wenn man nun eine Stateless Session Bean hätte, die dasselber Interface hat wie ein Entity Home, kommt man zu dem typischen DTO-Strukturen von EJBs bzw. DAOs in moderneren Anwendungen.
Spring bringt dann die Exporter und Proxies, mit denen man Spring-Beans in andere Infrastrukturen exportieren kann oder ein Objekt aus einer Infrastruktur transparent ansprechen kann. Beispiele sind verteilte Infrastrukturen wie RMI, SOAP etc., aber eben auch JMX oder OSGi. Diese Patterns sind als Adapter bzw. Proxy im ursprünglichen Desing Patterns Buch bereits beschrieben, können in Spring aber oft durch eine reine Deklaration implementiert werden.
Zum Abschluss habe ich dann noch Spring Patterns für API-Abstraktionen wie den Exception-Übersetzer vorgestellt. Der ist übrigens in EJB in Ansätzen auch vorhanden (durch das Wrappen technischer Exceptions in EJBExceptions) und auch mit AspectJ durch das Soften von Exceptions möglich - in Spring ist es allerdings mehr: Die Exceptions werden nicht nur einfach in eine generische Exception eingepackt, sondern es gibt eine detailierte Exception-Hierarchie, die z.B. Exceptions aus den verschiedenen Persistenz-Technologien vereinheitlicht.
Das andere Pattern ist dann das Template, dem man auszuführenden Code übergibt, und das sich dann um die Ressourcen kümmert. Hier habe ich darauf hingewiesen, dass es mit Closures noch einmal deutlich einfacher wird.
Das Feedback war rech gut - es gab sogar eine Einladung auf eine andere Konferenz...
JAOO 2006: Bruce Snyder : Achieving High Performance Enterprise Messaging
Bruce Snyder von Logic Blaze baut zum einen an Service Mix, einer Java-basierten SOA Lösung, und sprach außerdem über ActiveMQ, eine Open Source JMS Implementierung. In seinem Talk stellte er zunächst fest, dass Message basierte Lösungen primär wegen Verfügbarkeit genutzt werden und zum anderen, dass es sehr viele Stellschrauben gibt, mit denen man die Performance anpassen kann. Da keine zwei Szenarien gleich sind, muss man hier individuell schauen, was sinnvoll ist. Dinge wie persistene Queues oder garantierte Zustellung können dann die Performance entsprechend beeinflussen und zum Beispiel auch ein Problem werden, wenn eine Node neu hochkommt und erstmal mit alten Nachrichten "überflutet" wird.
Er berichtete außerdem, dass man mit ActiveMQ recht leicht Cluster bauen kann, da neue Nodes automatisch gefunden und in den Verbund aufgenommen werden.
Ich ware leider mit meinen eigenen Folien noch beschäftigt, so dass ich dem Vortrag ansonsten nicht detailiert folgenden konnte...
JAOO 2006: Guy Steele: Growing a language
Guy Steele trug in seiner Keynote über die neue Programmiersprache Fortress vor. Ausrichtung ist der technisch-wissenschaftliche Bereich (wo ja immer noch Fortran eine wichtige Rolle spielt) . Entsprechend nutzt Fortress Unicode für die Darstellung der Programme, weil so auch komplizierte technische-wissenschaftliche Symbole z.B. für Summen zur Verfügung stehen.
Neben der Sprache ist für Guy auch die User Community relevant. Außerdem will er die wesentlichen Features nach Möglichkeit in Libraries implementieren und nicht im Compiler, um den Sprachkern klein zu halten. Er will die Probleme der Anwender durch Libraries lösen, die dann in der Sprache möglichst einfach implementierbar sein sollen. Die Libraries selbst sind aus Komponenten mit Interfaces zusammengestellt, so dass man diese Teile austauschen kann.
Das Typsystem - eines der wichtigsten Themen einer Programmiersprache - verwendet polymorphe Operatoren und kann auch Typ-Inferenz. Mit Typ-Inferenz muss man den Typ eines Ausdrucks nicht explizit deklarieren, sondern er wird automatisch festgestellt. Normalerweise haben vor allem funktionale Sprachen solche Features.
Listen, Vektoren (im mathematischen Sinn) und Mengen sind eingebaut wie auch physikalische Einheiten. Ebenfalls gibt es verteilte Datenstrukturen. Auch eine Versionskontrolle ist eingebaut. Der Compiler wird in 2010 wohl soweit sein, dass er gut optimierten Code erzeugt.
Ein neues Konzeot sind Traits: Sie enthalten Interfaces und Code, sind aber keine Klassen und enthalten keine Felder. Dadurch kann man Mehrfachvererbung implementieren - außer eben für Felder. Die Felder kommen in den Blättern des Vererbungsbaums hinzu.
Desgin by Contract wird direkt unterstützt und es werden auch automatisch Tests gebaut.
Die primitven Datentypen sind auch Objekte - im Gegensatz zu Java. Es gibt auch eine deklarative Verteilung von Daten and Threads, transaktionalen Speicher und Schleifen werden per default parallel ausgeführt.
Ingesamt recht interessant, aber eben auch eher eine Nischensprache (zumindest vom Anspruch her). Ob sie sich gegen Fortran durchsetzen kann, wird man sehen, zumal Fortran eben seit ca. 50 Jahren diesen Bereich dominiert.
JAOO 2006: Rodney A. Smith: Mashups Meet Enterprise
Es gab für mich zwei Gründe, diesen Vortrag zu besuchen: Es ging um das Thema Mashups im Enterprise, was ich für eine interessante Integrationslösung halte. Außerdem war der Votragende von IBM, so dass hier auch echte Enterprise Kunden zu erwarten sind.
Er berichtete, dass viele Unternehmen an Web 2.0 interessiert sind. Technologien sind dabei vor allem AJAX (wenig überraschend), aber auch RSS. Das wird zum Beispiel von AmEx benutzt, um Content-spezifische Anwenudngen zu vereinfachen und eine Integration zu ermöglichen. Damit wird RSS dort eben nicht für das typische Blog und News Posting verwendet, sondern eben für eine Integrationsaufgabe.
Ein anderes Beispiel ist Retail: Dort hängt viel vom Wetter ab. Ein idealer Fall für ein Mashup, den sie dann auch gebaut haben mit einer Wiki-ähnlichen Oberfläche. Das ganze scheint recht einfach zu sein. Dadurch kann sich jeder sozusagen seine individuelle Oberfläche gestellaten. Was sonst viele Leute eh tun - so nutzen Store Manager typischer Excel, um ihre Berechnungen und Planungn zu machen - warum also nicht ein passend individualisierbares Werkzeug anbieten?
Ein anderes Beispiel war der Reverse Lookup von Telefonnummern: Eine Verscherung muss bei irgendwelchen Änderungen am Vertrag den Versicherungsnehmer informieren. Da die Daten oft nicht aktuell sind, gibt es hier ein Problem. Mit Hilfe eines solchen Dienstes kann man die Telefonnummern noch einmal verifizieren und hat dadurch höhere Qualität und weniger Probleme.
Ingesamt habe ich hier den Eindruck mitgenommen, dass Mashups tatsächlich auch im Enterprise-Umfeld eine interessante Integrationsmöglichkeit sind, die man auf jeden Fall weiter beachten sollte....
JAOO 2006: Gregor Hophe: SOA Track Introduction
Gregor arbeitet bei Google und hat das
Enterprise Integration Patterns Buch geschrieben. Er vertrat - wie ich auch - die Meinung, dass SOA vor allem die Art und Weise wie wir über Systeme nachdenken verändert. Damit ist es technologieunabhängig, obwohl es auch auf der Technologie-Seite Herausforderungen wie die Kopplung der Dienste gibt.
Die komplexen dynamischen Interaktionen der Dienste benötigen eine gemeinsame Vision, um wirklich zu einem zusammenhängenden System zu kommen. Dabei sind Elemente wie Events als Grundlage und deklarative Ansätze wichtig wie auch der Austausch von Objekten oder auch Objekten.
Interessant war dann noch, dass Gegor der Meinung ist, grafisch Notationen helfen nicht wirklich. Womit er recht hat, sie vermitteln eine Übersicht, aber grafische Modellierung ist oft einem textuellen Entwurf unterlegen (daher ja auch zum Beispiel das Interesse an textuellen DSLs). Einige missbrauchen Integrationswerkzeuge sogar für künstlerische Dinge, siehe
hier. Dies zeigte er dann auch in der Präsentation.
Dienstag abend: Das "Boot" von Charles Simoyi
Abends waren die Track-Hosts dann auf dem Boot von
Charles Simonyi eingeladen. Mir war er eigentlich nur als Ex-Microsoft-Mitarbeiter bekannt und als derjenige, der
Intentional Programming macht. Nun ja, sagen wir mal, ich habe es unterschätzt. Charles hat im wesentlichen Excel und Word gebaut und sein "Boot" ist ein Schiff - von innen soll es seinem Haus in Seattle nachgebaut sein. Siehe auch die Bilder:
Es gab dort einige interessante Diskussionen. Vor allem wurde für mich an dem Abend klar, dass die Sprach-Frage wieder offener wird. Neben der Keynote von Guy Steele über Fortress war auch Erik Meijer (Microsoft) dort, der LinQ baut. Interessanterweise hat er vorher an Haskell gearbeitet, einer funktionalen Sprache, auf der die Ideen aus LinQ nun basieren. Daher macht das ganze auch so einen gut fundierten Eindruck. Außerdem war Laurence Tratt vom King's College London dort, der ebenfalls eine neue Programmiersprache gebaut hat. Da gab es natürlich einige interessante Diskussionen.
Ingesamt denke ich, dass es gar nicht so schlecht ist, dass die Sprach-Frage wieder offen ist. Durch den Erfolg von Java war hier eher Stillstand eingetreten, aber die Sprache definiert eben auch, was man überhaupt ausdrücken kann, daher ist Stillstand dort eigentlich schädlich. Schauen wir mal, was da noch an interessanten Dingen passiert...
JAOO 2006: Wolf Johansson & Olivier Caudron: Boosting project productivity with an integrated approach using Caché and Jalapeño
Den Abschluss des Performance-Track bildete dann Intersystems, die dort ihre Datenbank Caché vorstellten. Diese ist irgendwo zwischen einer relationalen und objektorientierten Datenbank positioniert. Darauf setzt dann Jalapeño auf als Zugriffsschicht auf. Ingesamt ein interessanter Ansatz, der wohl aber nur eine Insel-Lösung ist. Es ist eben leider so, dass die meisten Projekte relationale Datenbanken verwenden und die sind auch meistens strategisch gesetzt. In der Session waren mehrere Leute von Intersystems vor Ort, die dann auch kompetent und ausführlich Rede und Antwort standen. Die Präsentation selber war sehr praktisch orientiert mit konkretem Life-Coden. Abegrundet wurde es dann durch Projekt-Erfahrungen von Triii.
JAOO 2006: Andre Bondi : Experience with Performance Engineering in an Agile Development Process
Weiter ging es im Performance Track mit Andre Bondi, der in München für Siemens in einem großen agilen Projekt als Performance-Engineer gearbeitet hat und über seine Erfahrungen berichtete.
Der Vortrag war ausgesprochen interessant und zeigte, wie Andre sich in dem Projekt systhematisch mit dem Performance-Thema beschäftigt hat. Dabei wurden auch Synergien deutlich: Mit einem agilen Vorgehen kann man frühzeitig schon in den bereit implementieren Use Cases Tests vornehmen und optimieren. Anhand des Oktoberfests verdeutlichte er typische Performance-Probleme: Wie auch für die Kellnerinnen beim Oktoberfest muss man auch in einem Computer-System dafür sorgen, dass es keine Bottlenecks gibt, sie ggf. identifizieren und dann eliminieren.
Vor allem war interessant, wie man die Rolle eines Performance Engineers in einem Projekt ausgestalten kann und in Kooperation mit Management und Entwicklern in diesem Bereich das Projekt zum Erfolg führen kann.
JAOO 2006: Angelika Langer: The Art Of Micro-Benchmarking In Java
Angelika ist ebenfall ein Java Champion und arbeitet im Bereich C++/Java-Beratung und -Training. Auch hier nur eine kurze Zusammenfassung, meine Mitschrift ist halt leider weg...
In ihrem Vortrag ging es um das Thema von Micro-Benchmarks. Das sind kleine Anwendungen, die man nutzt, um die Entscheidung für oder gegen einen Algorithmus zu treffen. Das Problem ist nun, dass durch die dynamische Optimierung der JVM hier verschiedene Effekte passieren. So kann die Durchführung der Optimierungen die Anwendung verlangsamen, da sie nicht nur den Code ausführt, sondern auch die Optimierungen durchführt. Anschließend können dann De-Optimierungen notwendig werden, die wiederum Zeit kosten. Ähnliches gilt für Garbage-Collections, die dazu führen können, dass die Anwendung eine Pause macht, so dass entsprechend falsche Ergebnisse rauskommen. Das ganze macht Micro-Benchmarks wesentlich in Java schwieriger handhabbar als zum Beispiel bei C++. Man kann allerdings zumindest in Java 5 einige der Compiler-Zeiten über JMX sehen oder per -XX:+PrintCompilation ausgeben lassen.
Angelika hat sehr deutlich gezeigt, dass es nicht einfach ist, solche Micro-Benchmarks richtig hinzubekommen, aber nur mit solchen Benchmarks kann man die richtige Entscheidung für oder gegen einen Algorithmus treffen.
JAOO 2006: Kirk Pepperdine: Performance Anti Pattern
Kirk Pepperdine war dann der nächste im Performance-Track: Er ist auch ein Java Champion und betreibt
Java Performance Tuning. Sein Talk war sehr interessant und hatte auch einen guten Vortragsstil. Wie schon berichtet, sind meine Aufzeichnungen leider verschwunden, aber einige Dinge sind mir noch in Erinnerung.
Er sprach sehr konkret darüber, wie man die Performance eine Java-Anwendung untersuchen und verbessern kann. Er beschriebt dabei Vorgehensweisen, die typischerweise zu Problemen führen (eben Anti-Patterns) und Gegenmaßnahmen. Dabei ging es um Dinge wie "Measure - Don't Guess!" und "Data Lite". Letzteres beschreibt den Umstand, dass man in einer Anwendung für Performance-Tests oft eine reduzierte Mengen an Daten verwendet, wodurch dann die Probleme nicht auftreten, die mit Produktions-Datenmengen auftreten. Andere Themen umfassen zum Beispiel das Bewerten von Performance-Messungen, bei denen es nicht nur auf Mittelwerte, sondern eben auch auf die Streuungen ankommt.
Das ganze wurde durch konkrete Beispiele ergänzt. Als Werkzeuge kamen dabei zum Beispiel Apache JMeter und IronEye SQL zum Einsatz. Letzteres gibt aus, was genau auf der Java-Seite der Anwendung un Bezug auf Datenbank-Anfragen passiert. Kirk stellte auch zahlreiche Fragen an das Publikum, das dann mit Süßigkeiten belohnt wurde....
JAOO 2006: Patrick Linskey und Brian Oliver: Making Java Persistence Perform
Im Rahmen meines Performance Tracks sprachen dann Patrick Linskey (BEA) und Brian Oliver (Tangosol) über "Making Java Persistence Perform". Patrick war zuvor bei Solarmetric, die den Kodo JDO O/R Mapper gebaut haben, der jetzt in OpenJPA bei BEA aufgeht. Brian arbeitet bei Tangosol, die einen verteilten Cache für Cluster anbieten. Eigentlich ist Tangosol sogar mehr, da durch redudnate Speicherung die Daten auch recht sicher sind, d.h. wenn eine Node versagt, hat man immer noch die Daten im Zugriff.
Leider habe ich meine detailierten Aufzeichnungn verloren, aber einige Sachen sind mir im Gesächtsnis geblieben:
Zunächst ging Patrick auf den Unterschied zwischen Performance (=schnell) und Skalierbarkeit (=mehr Ressourcen führen zu mehr Durchsatz) ein. Dann stellt er da, dass Datenbanken einige grundlegende Eigenschaften haben: Sie skalieren nur begrenzt (weil sie kaum im Cluster laufen) und sie haben eine gewisse Latenz, weil sie eben auf einer anderen Maschine laufen und im Zweifel auch auf die Platte zugreifen müssen.
Daraus leiteten die beiden dann einige Regeln ab, wie zum Beispiel das Verlagern der Tätigkeiten in die Datenbank (die sehr effizient große Datenbestände durchsuchen kann) oder Dinge wie "Schreib einfach keine Daten". Während das auf den ersten Blick unsinnig scheint, ist es in wirklichkeit so, dass man mit einem Cache wie Tangosol dazu in der Lage ist, Daten sicher bereit zu stellen, ohne sie zu schreiben, weil sie im Cache redudant gespeichert werden. Andere Tipps betrafen zum Beispiel die Verwendung grobgranularer Transaktionen.
Meiner Ansicht nach war dieser Talk recht wichtig, denn gerade Persistenz ist oft ein Performance-Thema. Dazu kommt dann noch, dass man eigentlich für solche Probleme sowohl Datenbank-Know-How als auch Java-Know-How haben muss, so dass man das eigentlich kaum alleine bewältigen kann. Daher war einer der Tipps auch, it den Datenbank-Administratoren zu reden und sich ein gutes Verhältnis zu Ihnen aufzubauen.
Spring: Es geht weiter....
Nur wenige Tage nach dem Spring 2.0 Release geht es gleicht weiter:
- Die Spezifikation für die Spring-OSGi-Integration ist draußen. Dies ist ein wichtiges Thema, weil dadurch eine Spring Anwendung in einem OSGi-Container laufen kann, so dass man einzelne Teile individuell hoch und runterfahren kann.
- Und Spring Web Flow ist jetzt in RC4, wie man hier sehen kann.
Also: Innovation never stops.
JAOO 2006: Performance Track
Ich hatte die Ehre, dieses Jahr den Performance-Track auf der JAOO zu organisieren. Das ganze ging damit los, dass ich in der Einführung einen Überblick und ein Problem-Statement gegeben habe. Wesentliche Eckpunkte waren dabei:
- Performance muss man vor allem auf der Prozess-Ebene richtig hinbekommen
- Es macht keinen Sinn, ausschließlich auf den Application-Layer zu fokussieren, da im allgemeinen in Bereichen wie zum Beispiel der Datenbank mehr zu holen ist - also muss man einen Gesamtansatz wählen.
- Gleichzeitig ist Performance besonders wichtig, weil die Einhaltung der Anforderungen in diesem Bereich offensichtlich sind und die Produktions-Einführung verhindern kann
Leider kann man in einer Einführung eigentlich nur Themen aufwerfen, aber die Themen nicht inhaltlich einer Lösung zuführen - das habe ich dann den anderen Teilnehmern am Track überlassen.
JAOO 2006: Eric Evans - Domain Driven Design
Leider konnte ich nur den zweiten Teil von Eric Evans Session besuchen. Er hat mit
Domain-Driven Design eines der wichtigeren Bücher der letzten Jahr geschrieben und über dieses Thema hat er auch gesprochen.
Er fing damit an, darzustellen, dass es nur ein begrenzte Team-Größe gibt, die man noch sinnvoll koordinieren kann. Als Beispiel, um dies zu illustrieren, wählte er Ruderboote: Es gibt nur maximal einen 8er, weil darüber hinaus die Koordinierung nicht mehr möglich ist.
Als nächstes stellte er die These auf, dass in einem großen System nicht alle Teile gleichgut designt sein werden. Daher rät er dazu, den Umfang zu reduzieren. Außerdem ist er der Meinung, dass präzise Designs auch dazu neigen, fragil zu sein. Das ist insbesondere schlecht, wenn um das gute Design herum Chaos herrscht.
Also rät er dazu, Grenzen in das System einzuziehen und an den Grenzen auch jeweils ein Mapping einzuführen, so dass unterschiedliche Modelle für unterschiedliche Anwendungsfälle möglich sind. Man hat also dann Grenzen im System und innerhalb dieser Grenzen ist ein Modell dann einsetzbar. Interessanterweise stellt dies natürlich völlig in Abrede, dass man ein generelles, universelles Objekt-Modell erstellen kann, wie es eigentlich zum Beispiel für eine SOA sinnvoll erscheint.
Ein weitere Maßnahme, die er dann vorstellte, war ein Anti-Corruption Layer. Dies wird dazu benutzt, um zwei unterschiedliche Teile des Systems voneinander zu entkoppeln. Idealerweise sollte es die beiden Teile hermetisch voneinander abgrenzen, in der Realität haben sie allerdings oft ein Leck, so dass man dann Probleme bekommt - und bereits bei recht kleinen Lecks recht große. Die Übersetzung der Modelle der verschiedenen System-Teile wird dabei in die Grenzen verschoben, um die Teile möglichst gut voneinander zu entkoppeln und innerhalb des Systems Konsistenz mit einem einzigen Modell zu erreichen. Als Metapher wählte er die biologischen Zellen, die ja auch durch Zellwände voneinander entkoppelt sind.
Für die Visualisierung schlägt er Context Maps vor, die darstellen, an welchen Stellen des Systems welche Modelle verwendet werden. Für Verbesserungen schlägt er vor, zunächst das darzustellen, was vorhanden ist, dann die echten Probleme zu beseitigen und nachdem man tatsächlich diese Änderungen vorgenommen hat, sollte man eine neue Context Map erstellen.
Anschließend kam er zu dem Thema des "Destillierens" der Core Domain. Seiner Meinung nach zerfällt ein System in drei unterschiedliche Bereiche:
- Generic Subdomains, die generische Funktionalitäten wie zum Beispiel das Handling der Zeitzonen implementieren. Weil diese gut strukturierte und eine generische Implementierung in diesem Bereich auch recht spannend ist, stürzen sich oft die besten Entwickler auf dieses Thema
- Supporting Domains, die schon speziell zum Anwendungsfall gehören, aber nicht den Kern darstellen
- Core Domain: Der tatsächliche Kern der Funktionalität
Die Frage, die dabei beantwortet werden muss, ist: "Was ist es, was die Entwicklung des Systems rechtfertigt? Warum kann man es nicht kaufen oder outsourcen? Und warum kann man es nicht einfach mit Visual Basic bauen?"
Seiner Meinung nach ist es oft nicht so einfach, die Core Domain zu identifizieren, da man dazu verstehen muss, was der Anwendungsfall genau ist und vor allem, was der Wettbewerbsvorteil ist. Als Beispiel wählte er den Versand von Containern: Obwohl eigentlich das Ziel des Projekts ist, den Versand zu optimieren, indem man Container während der Reise noch auf einen anderen Weg schicken kann. Dennoch hat die Firma als Wettbewerbsvorteil, dass der Versand mit ihr besonders reibungslos ist. Daher sollte man darauf fokussieren. Was mich dabei irritiert ist, das auf diesem Wege eine Management-Entscheidung über der Fokus des Projekts getroffen wird und das möglicherweise auf einer Ebene, die solche Entscheidungen nicht treffen sollte.
Spring 2.0 ist draußen!
Wie man
hier lesen kann, ist Spring 2.0 jetzt final draußen. Der Ansturm hat den Server auch schon in die Kniee gezwungen...
Also: Runterladen und Ausprobieren!
JAOO 2006: Werner Vogels - CTO Amazon
Die erste Session war am Montag morgen Werner Vogels (CTO, Amazon). Damit konnte man also einen Eindruck davon gewinnen, was ein Versandhandel von der Größe Amazons so treibt....
Als erstes wies er auf die
Amazon Web Services hin, mit denen Amazon Zugriff auf die Amazon-Infrastruktur auch anderen Benutzer ermöglicht. Dabei geht es um Dinge wie Storage oder Computing. Amazon ist eine der Sponsoren und daher gibt es sicher hier am Stand dazu auch mehr Informationen.
Dann ging es um sein eigentliches Thema. Zunächst stellte er verschiedene Web-Sites vor, die Amazon als Checkout anbieten. Das bedeutet, dass in Wirklichkeit dahinter Amazon steckt - es ist nur eine andere Oberfläche. Dazu gehört zum Beispiel der NBA-Shop.
Ingesamt wird Amazons Online Shop dadurch von einer Application zu einer Technology Platform, die auch anderen offen steht. Technologie wird für Amazon dabei eine der wichtigsten Elemente der eigenen Strategie. Die Idee von Amazon ist unter anderem der "Long Tail", also auch jene Waren anzubieten, bei denen nur wenig Nachfrage besteht. Diese kann man mit einem Online-System noch preiswert verkaufen, weil man zum Beispiel keinen gedruckten Katalog benötigt. Bücher eigenen sich gut, weil es soviele verschiedene Bücher gibt. Jetzt versucht Amazon, noch in einem anderen Bereich einen "Long Tail" zu realisieren: Neben Büchern werden auch andere Dinge angeboten wie zum Beispiel neuerdings eine Grocery und Industrial Produkte.
Gleichzeitig wird Amazon zu einem Marktplatz: Er zeigte das am Beispiel eines Falchbildschirm-Fernsehers, den Amazon auf der Web Seite anbietet. Der beste Preis, der auch prominent dargestellt wird, ist jedoch kein Amazon-Preis, sondern der Preis eines anderen Versenders. Das ist logisch, denn der Kunde geht sowieso woanders hin. So kann Amazon immer noch daran verdienen. Die Versender bekommen so Zugang zu 60 Millionen Kunden und vor allem auch zuu Amazon-Technologien. Die Technologien werden in Zukunft noch wichtiger werden, weil Amazon nun auch Fullfillment anbietet: Man kann dabei auch zum Beispiel den Versand eines Gegenstandes aus einer EBay-Auktion an Amazon übergeben. Amazon öffnet damit seine iegne Technologie-Platform für andere Firmen.
Technisch ist ganz interessant, dass Amazon bei seinen Services auch anbietet, dass man seine eigenen XSLT-Skripts auf dem Amazon-Server ausführen lässt, so dass man nur genau die Information bekommt, die man haben will und in der Repräsentation, die man gerne haben möchte.
Ein Hauptproblem von Amazon ist natürlich die Skalierbarkeit: Man muss ständig nachlegen, um mit den steigenden Kundenzahlen zurecht zu kommen und auch nur so kann man billiger und auch sonst attraktiver werden, um noch mehr Kunden zu bekommen.
Amazon hat dann irgendwann entschieden, dass man alles in einzelne Services aufteilt, die auch jeweils eine eigene Datenbank haben. Die Logik wird dabei in der Nähe der Datenbank implementiert. Dadurch bekommt man mehr Skalierbarkeit, weil das Management des Zustand transparent ist. Die Serives werden auch von einem Team implementiert und zwar, um ein Business-Problem zu lösen. Diese Teams machen Design, Development und auch Operations. Die klassische Trennung zwischen Implementierung und Betrieb wird hier also aufgelöst. Dadurch sind die Entwickler auch motiviert, die Services leicht managebar zu machen.
Es kam dann eine Diskussion, dass Skalierbarkeit bedeutet, dass alles höchsten in O(n) wachsen darf, was nicht völlig trivial ist. Wenn es stärker wächst, skaliert man halt nicht linear, was keine gute Sache ist.
Eine andere Sache, die er vorstellte, war das CAP-Theorem. CAP steht für Consistence, Availability und Partionability. Das Theorem besagt, dass man von diesen drei Eigenschaften nur zwei bekommen kann. Weil Partiotionierbarkeit zwingend ist (das Netzwerk kann halt ausfallen), kann man sich nur für Availability oder Consistence entscheiden. Typischerweise ist die Wahl dann die Availability.
Ingesamt war der Vortrag ausgesprochen beeindruckend: Amazon weiß offensichtlich sehr genau, was sie wollen und ist technologisch auf einem spannenden Trip. Vor allem ist es interessant, dass Amazon konsequent auf Technologie als Differnziator setzt - das ist bei anderen Firmen, deren wesentlicher Wettbewerbsvorteil eigentlich Technologie ist, durchaus anders: Dort wird es oft nur als Kostenfaktor wahrgenommen.
J for Java |
I for Internet, iMac, iPod and iPad |
Me for me
