So, das ist jetzt hoffentlich spannender und die ersten paar Minuten kann ich doch ganz bestimmt auf der CD-Rom noch checken. Auf jeden Fall habe ich gerade den Talk gewechselt und lass mich mal zum GlassFish informieren.
Ein interessanter Link ist VisualVM, ein Monitoring Tool aktuell in Beta 2.
GlassFish unterstützt Single Sign On (SSO) für alle Web Applikationen bzw. mit OpenSSO gibt es auch ein CrossServer bzw. CrossDomain SSO. Interessant ist, dass OpenSSO auch heterogene Umgebungen abdeckt, indem man Adapter in die jeweiligen Umgebungen deployt. Jetzt gibt's einige Beispiele dafür, wie man mit OpenSSO in verschiedenen Setups nutzt. Jetzt gerade gibt's hier das Beispiel für die Nutzung in WebServices. Da SSO ja ein immer wiederkehrendes Thema ist.
Weg vom SSO-Thema, hin zu einem neuen Hype: Scripting. Man merkt schon, Daniel Adelhardt hat so gewisse Vorbehalte: "muss man zugestehen" und "Quick, Dirty & Good Enough Architekturen" - ehrlich, das was hier offensichtlich als "Enterprise Architekturen" firmiert ist halt nicht pragmatisch. Nicht in dynamischen Sprachen und nicht in Java.
Immerhin, Sun hat das erkannt und setzt auf JRuby. Jython ist auch dazugekommen. Jetzt fehlt nur noch offizieller Support für Groovy. Und Daniel Adelhardt gibt das Statement, dass Groovy in Netbeans und in GlassFish unterstützt wird. Ich persönlich bin ja überzeugt davon, dass dynamische Sprachen - hier unterscheide ich für mich ja von "Skriptsprachen" - auch im Enterprise Umfeld wesentliche Benefits bringen können.
Dass es Sinn macht, AppServer und "Skriptsprachen" zu kombinieren, stellt auch Daniel Adelhardt dar, sei es aus Security Gründen, aus Gründen der Betriebs-Infrastruktur und des entsprechenden KnowHows.
Schön ist die Unterstützung von PHP über das Quercus Servlet. Das gefällt mir. Auch für JRuby gibt es Bundle, das sich direkt in den GlassFish 2 installieren lässt. Von GlassFish 3 gibt es eine Mini-Version (geht quasi zurück auf die Keynote), die dann auch quasi "nur" den Ruby-Server bereitstellt.
Was passiert mit Groovy bzw. Grails? Interessanterweise wird das in Deutschland gemacht und ist aktuell in Arbeit.
Nächstes Thema: Rich Application Clients: Load Balancing und Failover for IIOP(s). Man kann da den Client mit dem ear bundlen und der Glassfish generiert dann automatisch ein JNLP File. Scheint aber alles nicht so einfach zu sein. Das ganze gibt's zum Nachlesen auf den Slides. Und hah - für Firewall/Loadbalancing-Szenarien gibt's 'ne Lösung.
Comet ist eine Lösung, um einen Push vom Server auf den Client auszulösen. Muss man sich mal genauer ansehen. Auf jeden Fall unterstützt der GlassFish Comet und man muss einfach im http-listener das Property "cometSupport" auf "true" setzen. Im Server-Log sollte dann so was stehen wie "Enabling Grizzly ARP Comet support". Die Basis für Comet im GlassFish ist die NIO, die ein non-blocking handling erlaubt. Im Service einfach den CometHandler implementieren und den CometHandler beim Request anhängen. Der Code ging auf zwei Slides und der Mechanismus ist ziemlich interessant.
Mein Fazit zu dieser Session: Ja, das mit OpenSSO hat nicht wirklich zwingend was mit GlassFish zu tun, aber dennoch war der Talk sehr interessant, hat eine weite Thematik behandelt und war absolut empfehlenswert. Gut, das Thema Comet hatten wir so auch schon mal, ohne zu wissen, dass es Comet gibt.
Dienstag, 22. April 2008
jax08: Presenter First for RCP applications using Spring OSGi
Wow, drei Buzzwords auf einmal im Titel, wenn ich dann auch noch testable dazunehme... also abwarten, ob das Buzzword-Bingo wird oder interessant. In diesem Zeitslot ist die Konkurrenz groß, ich habe auf Glassfish, Sprachtrends und Pragmatic Architecture verzichtet.
Natürlich wollen wir möglichst einfach, agil, testbar auch unseren Eclipse RCP UI-Code entwickeln. Also los. Kurze Einführung ins Beispiel, Test Cases für das Beispiel. Schade, da macht Heiko Seeberger schon zuerst die Tests, doch dann macht er (auf seinen Folien) wieder den "Fehler", sich nicht von den Tests leiten zu lassen. Er macht erst mal ein "so macht man's nicht"-Beispiel und hackt das Beispiel komplett in einem Composite. Naja, kein Wunder, dass sich das nicht testen lässt. Weiter. Nächster Punkt.
Ich denke, dass ich hier falsch bin - und mir den Vortrag lieber auf CD-Rom ansehe. Mal sehen, ich geh mal weiter in den nächsten Vortrag, wo es sich vielleicht nicht so leicht nachlesen lässt.
Natürlich wollen wir möglichst einfach, agil, testbar auch unseren Eclipse RCP UI-Code entwickeln. Also los. Kurze Einführung ins Beispiel, Test Cases für das Beispiel. Schade, da macht Heiko Seeberger schon zuerst die Tests, doch dann macht er (auf seinen Folien) wieder den "Fehler", sich nicht von den Tests leiten zu lassen. Er macht erst mal ein "so macht man's nicht"-Beispiel und hackt das Beispiel komplett in einem Composite. Naja, kein Wunder, dass sich das nicht testen lässt. Weiter. Nächster Punkt.
Ich denke, dass ich hier falsch bin - und mir den Vortrag lieber auf CD-Rom ansehe. Mal sehen, ich geh mal weiter in den nächsten Vortrag, wo es sich vielleicht nicht so leicht nachlesen lässt.
Grails - der Gral der Webentwicklung
Mann, oh mann! Zweimal schon wollte ich mir diesen Talk in Hamburg schon anhören - in der XP-User Group und an der HAW. Hat beide Male nicht geklappt, also muss es hier endlich gehen. Ich komme ja aus der Ecke Web-Entwicklung und das Thema wird mich bestimmt auch nicht ganz loslassen, auch wenn ich im Moment eher Service-orientiert und Eclipse RCP-lastig unterwegs bin. Vielleicht gibt's ja auch neue Ideen für ein RCP-Grail, denn convention over configuration hat sich dort auch noch nicht durchgesetzt. Hinzu kommt, dass dies die meiner Meinung nach "schwächste" Session-Runde ist (hier hatte ich nur vier Talks zur Auswahl) und wir uns kollegentechnisch etwas aufgeteilt haben und wir so nichts relevantes verpassen. Hoffentlich.
Hey, cool. Endlich hat sich's mal gelohnt, dass mein Notebook so 'nen schwachen Akku hat: Dadurch wollte ich mir einen Platz mit Steckdose sichern, war früher da und muss jetzt wenigstens weder stehen noch am Boden sitzen. Grails ist ein Thema, das brennt.
Der Vortragsstil - zumindest der Einstieg - ist schon mal klasse. Ich persönlich stehe ja auf diese Art von Vorträgen. Anhand von "Praxisbeispielen" beleuchten die beiden Web-Frameworks: Es ist mehr eine Pannenshow in Bildern aus allen möglichen Bereichen, mit Übertragung auf die Web-Frameworks. Die Folien danach sind eher klassisch, aber gut, es soll ja auch nicht nur cool sein, sondern auch informativ.
Spring, Hibernate und Sitemesh sind die Grundlagen von Grails, Groovy ist nur der Zuckerguß auf diesen Grundlagen. Und da der Zuckerguß dünn ist, wird die Applikation auch nicht dick, soll heißen langsam durch die doch vergleichsweise geringe Performance. Neben diesen Grundlagen stecken in Grails noch andere Libraries für Ajax, Batch, Sicherheit und Tests. Eigentlich sind es die alten Bekannten aus der Welt der Webentwicklung.
Jetzt kommt ein Crash-Kurs Groovy, den gebe ich hier mal nicht weiter. Für Java-Entwickler ist der Einstieg ja suuper-leicht, aber wie immer dauert es natürlich eine Weile, bis man wirklich in der Denke der Sprache angekommen ist. Ich reite noch mal drauf rum - wer LISP kann, ... naja, lassen wir das. Worauf auch Stefan Roock nochmal hinweist: Groovy und Java integrieren sich nahtlos, man kann von Java-Klassen auf Groovy-Klassen zugreifen und umgekehrt.
Jetzt zu Grails: Zunächst mal die Persistenz: Domain-Objects werden automatisch gemappt. Ich muss also keine Hibernate-Konfiguration, keine JPA-Annotationen oder sonst etwas machen, es geht sofort los. Wobei man zugeben muss, dann man es hier halt nicht über Annotationen oder sonst etwas machen muss, sondern über die Konvention, dass es in einem Package domain liegt und dass man die Felder hasMany oder belongsTo benutzt, die jeweils eine Map bekommen. Constraints werden beispielsweise über eine Closure definiert, die eine DSL enthält. Spannendes Konzept. Stefan Roock weist noch darauf hin, dass man sich leichter tut, wenn man es erst mal so hinnimmt und nicht versucht, es erst mal zu verstehen und dann zu machen. Stimmt wohl, das Konzept ist einfach zu benutzen. Wie die Abbildung auf die Datenbank-Constraints passiert muss man eigentlich gar nicht wissen. Aber es zeigt schön die Groovy-Denke.
Der DynamicFinder ist total interessant, da er wundervoll die Dynamik der Sprache zeigt: Adresse.findAllByPostleitzahlAndGueltigBis(21502, null). Ein MOP (Metaobject Protocol) hat echte Vorteile! Die Zwischenfrage nach der IDE-Unterstützung ist natürlich interessant: IDEA hat die beste Unterstützung, Eclipse und Netbeans ziehen da nach.
GroovyServerPages setzen voll auf Sitemesh und entsprechende Taglibs. Das kann man in Java natürlich so auch selbst machen, aber Grails bringt das halt schon alles mit.
Wir haben Model und View, die Controller verbinden das. Dabei werden Controller in einem eigenen Package und über das Suffix Controller identifiziert. Interessanterweise werden die einzelnen Aktionen nicht als Methoden realisiert, sondern als Closures, die in Feldern gespeichert werden.
Jetzt geht's schon ins Eingemachte: AJAX ist eingebaut (Prototype / Script.acoluo.us, Yahoo! UI als Plugin, Dojo als Plugin). TagLibs lassen sich einfach selbst bauen: Wieder per Konvention in den Ordner taglib die eigene TagLib reinwerfen und schon ist die Taglib fertig. Stefan Roock weist darauf hin, dass man durch die Einfachheit in Grails-Projekten eigene Taglibs viel häufiger einsetzt als in Java-Projekten. Glaube ich sofort.
Testen ist in Grails direkt eingebunden. Es generiert Skelette für Domain-Klassen und Controller, integriert die Ausführung von Tests in die bereitgestellten Skripte etc. Noch ist das ziemlich langsam, weil die VM, das Framework und der Webserver immer mal wieder hoch- und runtergefahren wird.
Jetzt kommt Stefan Roock schon zu RESTful Services mit Grails, sehr interessant, aber doch durchaus vielleicht schon fast zu tief. Die Zuhörer schwitzen zum Teil schon.
Aber, es ist fast geschafft. Jetzt geht's (nach der unvermeidlichen Werbeeinblendung) zur Live-Demo. Also Console auf, TextMate auf und los geht's. Bernd Schiffer baut sich erst mal eine neue Grails-Applikation. Beziehungsweise er lässt sich eine neue Applikation bauen, und zwar vom entsprechenden Grails-Skript.
Die Domain-Klasse wird wieder per Skript erzeugt. Erst mal ist das nicht spannend, aber Plugins für Grails können sich hier einklinken und so wird beispielsweise zu der Domain-Klasse auch eine Test-Klasse erzeugt.
Jetzt kann man die Applikation starten (dazu fährt intern ein Jetty hoch). Noch passiert nicht viel - die Applikation fährt hoch, aber es ist nur die Grails-Standard-Seite zu sehen. Also - Server läuft weiter - macht Bernd Schiffer sich einen entsprechenden Controller. Den sieht man jetzt schon auf der Einstiegsseite. Fehlt noch ein View, aber die entsprechenden Ordner sind auch schon angelegt. Also flugs eine gsp-Seite angelegt.
Bisher alles ohne Server-Neustart zu sehen.
In der Klasse BootStrap gibt's eine init (und eine destroy)-Methode, dort kommt noch ein bisschen Init-Code hin (Domänen-Objekt erzeugen), Server stoppen und starten (sonst wird die BootStrap-init-Methode nicht ausgeführt). Und schon sieht man was.
Jetzt geht's weiter über das Einfügen von Links, mehr Code im Controller etc. Damit sind wir durch. Die Fragen gehen im Rauschen unter, über DataSources kann die zugrundeliegende Datenbank auswählen, Refactorings sind noch nicht wirklich gut unterstützt, es gibt verschiedene Möglichkeiten, (Java) Legacy-Code zu integrieren. Mit DB-Migrate kann man die Migration von Datenbank-Schemata durchführen.
Noch mein Fazit: Der Talk war eine gute Einführung mit einer schönen Mischung aus theoretischer Einsicht und einem praktischen Teil. Groovy ist auf jeden Fall einen Blick wert. Wann kommt jetzt das Buch?
Hey, cool. Endlich hat sich's mal gelohnt, dass mein Notebook so 'nen schwachen Akku hat: Dadurch wollte ich mir einen Platz mit Steckdose sichern, war früher da und muss jetzt wenigstens weder stehen noch am Boden sitzen. Grails ist ein Thema, das brennt.
Der Vortragsstil - zumindest der Einstieg - ist schon mal klasse. Ich persönlich stehe ja auf diese Art von Vorträgen. Anhand von "Praxisbeispielen" beleuchten die beiden Web-Frameworks: Es ist mehr eine Pannenshow in Bildern aus allen möglichen Bereichen, mit Übertragung auf die Web-Frameworks. Die Folien danach sind eher klassisch, aber gut, es soll ja auch nicht nur cool sein, sondern auch informativ.
Spring, Hibernate und Sitemesh sind die Grundlagen von Grails, Groovy ist nur der Zuckerguß auf diesen Grundlagen. Und da der Zuckerguß dünn ist, wird die Applikation auch nicht dick, soll heißen langsam durch die doch vergleichsweise geringe Performance. Neben diesen Grundlagen stecken in Grails noch andere Libraries für Ajax, Batch, Sicherheit und Tests. Eigentlich sind es die alten Bekannten aus der Welt der Webentwicklung.
Jetzt kommt ein Crash-Kurs Groovy, den gebe ich hier mal nicht weiter. Für Java-Entwickler ist der Einstieg ja suuper-leicht, aber wie immer dauert es natürlich eine Weile, bis man wirklich in der Denke der Sprache angekommen ist. Ich reite noch mal drauf rum - wer LISP kann, ... naja, lassen wir das. Worauf auch Stefan Roock nochmal hinweist: Groovy und Java integrieren sich nahtlos, man kann von Java-Klassen auf Groovy-Klassen zugreifen und umgekehrt.
Jetzt zu Grails: Zunächst mal die Persistenz: Domain-Objects werden automatisch gemappt. Ich muss also keine Hibernate-Konfiguration, keine JPA-Annotationen oder sonst etwas machen, es geht sofort los. Wobei man zugeben muss, dann man es hier halt nicht über Annotationen oder sonst etwas machen muss, sondern über die Konvention, dass es in einem Package domain liegt und dass man die Felder hasMany oder belongsTo benutzt, die jeweils eine Map bekommen. Constraints werden beispielsweise über eine Closure definiert, die eine DSL enthält. Spannendes Konzept. Stefan Roock weist noch darauf hin, dass man sich leichter tut, wenn man es erst mal so hinnimmt und nicht versucht, es erst mal zu verstehen und dann zu machen. Stimmt wohl, das Konzept ist einfach zu benutzen. Wie die Abbildung auf die Datenbank-Constraints passiert muss man eigentlich gar nicht wissen. Aber es zeigt schön die Groovy-Denke.
Der DynamicFinder ist total interessant, da er wundervoll die Dynamik der Sprache zeigt: Adresse.findAllByPostleitzahlAndGueltigBis(21502, null). Ein MOP (Metaobject Protocol) hat echte Vorteile! Die Zwischenfrage nach der IDE-Unterstützung ist natürlich interessant: IDEA hat die beste Unterstützung, Eclipse und Netbeans ziehen da nach.
GroovyServerPages setzen voll auf Sitemesh und entsprechende Taglibs. Das kann man in Java natürlich so auch selbst machen, aber Grails bringt das halt schon alles mit.
Wir haben Model und View, die Controller verbinden das. Dabei werden Controller in einem eigenen Package und über das Suffix Controller identifiziert. Interessanterweise werden die einzelnen Aktionen nicht als Methoden realisiert, sondern als Closures, die in Feldern gespeichert werden.
Jetzt geht's schon ins Eingemachte: AJAX ist eingebaut (Prototype / Script.acoluo.us, Yahoo! UI als Plugin, Dojo als Plugin). TagLibs lassen sich einfach selbst bauen: Wieder per Konvention in den Ordner taglib die eigene TagLib reinwerfen und schon ist die Taglib fertig. Stefan Roock weist darauf hin, dass man durch die Einfachheit in Grails-Projekten eigene Taglibs viel häufiger einsetzt als in Java-Projekten. Glaube ich sofort.
Testen ist in Grails direkt eingebunden. Es generiert Skelette für Domain-Klassen und Controller, integriert die Ausführung von Tests in die bereitgestellten Skripte etc. Noch ist das ziemlich langsam, weil die VM, das Framework und der Webserver immer mal wieder hoch- und runtergefahren wird.
Jetzt kommt Stefan Roock schon zu RESTful Services mit Grails, sehr interessant, aber doch durchaus vielleicht schon fast zu tief. Die Zuhörer schwitzen zum Teil schon.
Aber, es ist fast geschafft. Jetzt geht's (nach der unvermeidlichen Werbeeinblendung) zur Live-Demo. Also Console auf, TextMate auf und los geht's. Bernd Schiffer baut sich erst mal eine neue Grails-Applikation. Beziehungsweise er lässt sich eine neue Applikation bauen, und zwar vom entsprechenden Grails-Skript.
Die Domain-Klasse wird wieder per Skript erzeugt. Erst mal ist das nicht spannend, aber Plugins für Grails können sich hier einklinken und so wird beispielsweise zu der Domain-Klasse auch eine Test-Klasse erzeugt.
Jetzt kann man die Applikation starten (dazu fährt intern ein Jetty hoch). Noch passiert nicht viel - die Applikation fährt hoch, aber es ist nur die Grails-Standard-Seite zu sehen. Also - Server läuft weiter - macht Bernd Schiffer sich einen entsprechenden Controller. Den sieht man jetzt schon auf der Einstiegsseite. Fehlt noch ein View, aber die entsprechenden Ordner sind auch schon angelegt. Also flugs eine gsp-Seite angelegt.
Bisher alles ohne Server-Neustart zu sehen.
In der Klasse BootStrap gibt's eine init (und eine destroy)-Methode, dort kommt noch ein bisschen Init-Code hin (Domänen-Objekt erzeugen), Server stoppen und starten (sonst wird die BootStrap-init-Methode nicht ausgeführt). Und schon sieht man was.
Jetzt geht's weiter über das Einfügen von Links, mehr Code im Controller etc. Damit sind wir durch. Die Fragen gehen im Rauschen unter, über DataSources kann die zugrundeliegende Datenbank auswählen, Refactorings sind noch nicht wirklich gut unterstützt, es gibt verschiedene Möglichkeiten, (Java) Legacy-Code zu integrieren. Mit DB-Migrate kann man die Migration von Datenbank-Schemata durchführen.
Noch mein Fazit: Der Talk war eine gute Einführung mit einer schönen Mischung aus theoretischer Einsicht und einem praktischen Teil. Groovy ist auf jeden Fall einen Blick wert. Wann kommt jetzt das Buch?
Randnotiz Treffer
Gerade auf der JAX-Website gelesen, dass es "Beste Gelegenheiten für Networking & Erfahrungsaustausch!" gibt. Stimmt, bin gerade kurz nach seinem Vortrag in Stefan Zörner reingelaufen. Mal sehen, was mein Kollege nachher über Zörners Talk erzählt.
Spring: Vom Framework zum Ökosystem
Ich habe mich für die Session "Spring: Vom Framework zum Ökosystem entschieden". Damit hat Eberhard Wolff gewonnen vor Rod Johnson mit seiner Q&A-Session zur Keynote und ein paar anderen interessanten Sessions. Hoffentlich wird's so interessant wie ich mir das gerade erhoffe. Natürlich stellt sich gerade in dieser Session die Frage, ob Spring mit allem nicht mittlerweile zu groß wird und damit in die Falle tappt, in der Java EE jetzt schon steckt.
Wow, erst mal schmeißt Wolff viiiiele Blasen an die Wand: Die ganzen Spring-Teilprojekte. Eine der Blasen ist Spring Batch. Spring Batch ist die Unterstützung von Batch-Jobs für Java, und dass Batch Jobs in vielen Projekten wichtig sind. Typische Probleme von Batches (ich denke mal, die Unterstützung dafür kommt gleich) sind Wiederaufsetzen nach einem Fehler, Parallelisierung und die Optimierung von Datenbank-Operationen.
[...] (Anmerkung: Hier redet Eberhard Wolff ziemlich detailliert über Spring Batch) Und weiter, und mehr, und noch mehr Batch Details. Ja, ich weiß was ein Batch ist und wie man so was bauen würde. Die Details von Spring Batch kann ich mir anschauen, jetzt wo ich weiß, dass es das gibt. Ich fange gerade an, in meinen Unterlagen zu blättern und nach Alternativen zu suchen. Das ist nicht der Vortrag des Titels, sondern irgendwas anderes. Das ganze geht mir persönlich viel zu tief in Spring Batches, ein deutlich flacherer Überblick hätte mir hier definitiv gereicht. Mehr, unterschiedlicher. Was gibt es noch an Blasen.
Endlich geht's weiter zum nächsten Bubble: Spring Integration. Das löst typische EAI-Probleme, also Messages, Routing, Splitting, Transformation etc. Das Framework basiert auf einem Pipes & Filters Pattern und ist Event-driven. Das heißt, dass sich das Framework um das Message-Listening kümmert und dann die Service-Aufrufe regelt. Beispielsweise übernimmt das Spring Integration Framework das Thread-handling. Super, das ist jetzt mal auf dem korrekten Niveau. Jetzt nur nicht zu sehr abgleiten ins Detail. Wir gehen jetzt mal in den Code, es könnte schon zu detailliert werden. Jaaa, es wird zu detailliert. Gut, es interessiert mich auch, ich raschle nicht, aber es ist eigentlich zu detailliert. Ich tackere das jetzt nicht mit, sondern verweise einfach mal auf die entsprechenden Slides. Ich hoffe mal, dass ich die CD-ROM mit den Slides nachträglich bekomme. Kommt das Ding per Post oder muss man es holen? Worauf ich hier noch hinweisen möchte: Spring Integration hat eine klassische Java-API, man kann aber auch sehr gut und einfach mit Annotations arbeiten.
Spring Web Services ist das nächste Bubble, das Eberhard Wolff vorstellt. Interoperabilität ist das Ziel von Web Services und Contract First ist das Mittel zum Zweck. Wenn man schon mal WebServices hat, dann kann man mehr machen als nur request-response und man möchte ggf. auch direkt auf das XML durchgreifen können.
ContractFirst ist gesetzt, wie soll man sonst Interoperabilität gewährleisten. Eine WSDL von Hand schreiben macht keinen Spaß. Umgekehrt ist der Weg der Generierung der WSDL aus Java auch suboptimal - es ist contract last, die Java Klassen entsprechen nicht den WSDL/XSD-Möglichkeiten, man bindet sich ggf. an die einzelnen WebService-Stacks. Selbst schon erlebt - WebServices sind per se erst mal nicht wirklich interoperabel zwischen verschiedenen Stacks und Sprachen. Jetzt kommen wir wieder zu dem Punkt, dass die WSDL eigentlich nicht en bloc von Hand geschrieben werden sollte, sondern aus verschiedenen Artefakten zusammengeneriert werden sollte.
Spring verwendet ein XML Schema zur Definition der Datenbeschreibung und der Methoden. Die Komplexität des SOAP Stacks (Endpoints, Ports und so weiter und so fort) kann man dann an anderer Stelle machen.
Für das Mapping von Objekten auf XML und umgekehrt kann man die vorhandenen Techniken nehmen - JAXB 1 und 2, Castor, XMLBeans, JiBX, XStream oder was auch immer. Oder man mappt nicht, sondern geht direkt auf die XML-Struktur runter, beispielsweise mit JDOM oder SAX. Die dritte Alternative geht über Annotationen und XPath. Das sieht interessant aus.
In 1.5 ("was wir jetzt gerade shippen") gibt es neu auch JMS und Email Transport.
Weitere Bubbles werden noch nicht mal kurz vorgestellt, da es z.T. noch eigene Talks dafür gibt.
Spring Enterprise bundled verschiedene Dinge zusammen: Zum Beispiel das Advanced Pack for Oracle, die bestimmte Misfeatures des Oracle RAC "ausbügelt". Es gehört auch die SpringSource Tool Suite dazu und die SpringSource Application Management Suite.
Ok, wir haben gesehen, dass Spring mittlerweile auch ein ganzer Zoo von Frameworks ist, aber diese einzelnen Frameworks sind wesentlich loser aneinander gekoppelt als dies bei JEE der Fall ist.
Wow, erst mal schmeißt Wolff viiiiele Blasen an die Wand: Die ganzen Spring-Teilprojekte. Eine der Blasen ist Spring Batch. Spring Batch ist die Unterstützung von Batch-Jobs für Java, und dass Batch Jobs in vielen Projekten wichtig sind. Typische Probleme von Batches (ich denke mal, die Unterstützung dafür kommt gleich) sind Wiederaufsetzen nach einem Fehler, Parallelisierung und die Optimierung von Datenbank-Operationen.
[...] (Anmerkung: Hier redet Eberhard Wolff ziemlich detailliert über Spring Batch) Und weiter, und mehr, und noch mehr Batch Details. Ja, ich weiß was ein Batch ist und wie man so was bauen würde. Die Details von Spring Batch kann ich mir anschauen, jetzt wo ich weiß, dass es das gibt. Ich fange gerade an, in meinen Unterlagen zu blättern und nach Alternativen zu suchen. Das ist nicht der Vortrag des Titels, sondern irgendwas anderes. Das ganze geht mir persönlich viel zu tief in Spring Batches, ein deutlich flacherer Überblick hätte mir hier definitiv gereicht. Mehr, unterschiedlicher. Was gibt es noch an Blasen.
Endlich geht's weiter zum nächsten Bubble: Spring Integration. Das löst typische EAI-Probleme, also Messages, Routing, Splitting, Transformation etc. Das Framework basiert auf einem Pipes & Filters Pattern und ist Event-driven. Das heißt, dass sich das Framework um das Message-Listening kümmert und dann die Service-Aufrufe regelt. Beispielsweise übernimmt das Spring Integration Framework das Thread-handling. Super, das ist jetzt mal auf dem korrekten Niveau. Jetzt nur nicht zu sehr abgleiten ins Detail. Wir gehen jetzt mal in den Code, es könnte schon zu detailliert werden. Jaaa, es wird zu detailliert. Gut, es interessiert mich auch, ich raschle nicht, aber es ist eigentlich zu detailliert. Ich tackere das jetzt nicht mit, sondern verweise einfach mal auf die entsprechenden Slides. Ich hoffe mal, dass ich die CD-ROM mit den Slides nachträglich bekomme. Kommt das Ding per Post oder muss man es holen? Worauf ich hier noch hinweisen möchte: Spring Integration hat eine klassische Java-API, man kann aber auch sehr gut und einfach mit Annotations arbeiten.
Spring Web Services ist das nächste Bubble, das Eberhard Wolff vorstellt. Interoperabilität ist das Ziel von Web Services und Contract First ist das Mittel zum Zweck. Wenn man schon mal WebServices hat, dann kann man mehr machen als nur request-response und man möchte ggf. auch direkt auf das XML durchgreifen können.
ContractFirst ist gesetzt, wie soll man sonst Interoperabilität gewährleisten. Eine WSDL von Hand schreiben macht keinen Spaß. Umgekehrt ist der Weg der Generierung der WSDL aus Java auch suboptimal - es ist contract last, die Java Klassen entsprechen nicht den WSDL/XSD-Möglichkeiten, man bindet sich ggf. an die einzelnen WebService-Stacks. Selbst schon erlebt - WebServices sind per se erst mal nicht wirklich interoperabel zwischen verschiedenen Stacks und Sprachen. Jetzt kommen wir wieder zu dem Punkt, dass die WSDL eigentlich nicht en bloc von Hand geschrieben werden sollte, sondern aus verschiedenen Artefakten zusammengeneriert werden sollte.
Spring verwendet ein XML Schema zur Definition der Datenbeschreibung und der Methoden. Die Komplexität des SOAP Stacks (Endpoints, Ports und so weiter und so fort) kann man dann an anderer Stelle machen.
Für das Mapping von Objekten auf XML und umgekehrt kann man die vorhandenen Techniken nehmen - JAXB 1 und 2, Castor, XMLBeans, JiBX, XStream oder was auch immer. Oder man mappt nicht, sondern geht direkt auf die XML-Struktur runter, beispielsweise mit JDOM oder SAX. Die dritte Alternative geht über Annotationen und XPath. Das sieht interessant aus.
In 1.5 ("was wir jetzt gerade shippen") gibt es neu auch JMS und Email Transport.
Weitere Bubbles werden noch nicht mal kurz vorgestellt, da es z.T. noch eigene Talks dafür gibt.
Spring Enterprise bundled verschiedene Dinge zusammen: Zum Beispiel das Advanced Pack for Oracle, die bestimmte Misfeatures des Oracle RAC "ausbügelt". Es gehört auch die SpringSource Tool Suite dazu und die SpringSource Application Management Suite.
Ok, wir haben gesehen, dass Spring mittlerweile auch ein ganzer Zoo von Frameworks ist, aber diese einzelnen Frameworks sind wesentlich loser aneinander gekoppelt als dies bei JEE der Fall ist.
Future of Java
In der Keynote erzählt Rod Johnson was über die Zukunft von Enterprise Java. In seiner typisch amerikanischen Art führt er erst mal aus, dass Java nicht mehr sexy ist: "No one will date a Java developer". Ruby sei doch so viel sexier für Web development. Ist natürlich nicht so, sonst stände Johnson ja nicht hier, sondern würde Ruby machen. Also, noch viel amerikanischer: Wir ziehen erst mal Statistiken raus - indeed.com job trends gibt ja die nötigen Daten ohne große Arbeit. Also der Vergleich mit Ruby, mit dot.net, alles in bunten Bildern. Fazit: Damit Java-Entwickler weiter gedated werden, muss sich Java ändern. Mal schauen, was Johnson als six plus two predictions präsentiert.
Aber zuerst mal zu den Faktoren, die Änderungen notwendig machen: Zuerst mal ist da die "productivity challenge" - dass man mit Ruby on Rails schneller ist in der Entwicklung von bestimmten Web-Applikationen ist als mit Java hat sich nun schon rumgesprochen. Der Punkt daran ist, dass die Java community an den "low hanging fruits" vorbeispringt. Warum also immer Rakentenphysik, wenn's auch einfach geht. Si!
Der zweite Grund für notwendige Änderungen ist einfach das Alter von Java EE. Java ist einfach nicht mehr schlank, weil sich mittlerweile eine Menge "baggage" angesammelt hat. Gut, ich hätte zwar "garbage" genommen, aber der Effekt ist der gleiche: Man muss das System wieder aufräumen, den Frühjahrsputz machen. Johnson sieht in Java EE 6 genau den Versuch, die Java Plattform auf Vordermann zu bringen. Die beiden Idees hinter Java EE 6 sind Extensibility und Profiles (steht auch im JSR-316). Die Grundlage für die Extensibility ist die Erkenntnis, das man nicht alles in die Plattform stecken muss, sondern dass die Plattform wirklich, ja was, eine Plattform für andere Frameworks sein sollte. Immerhin, die Erkenntnis ist für die Java EE Plattform wirklich neu. Klingt aber gut, denn mir geht das, beispielsweise mit den Appservern als Ergebnis von Java EE, oft so, dass ich viele der angebotenen Dienste nicht brauche. Andere auch nicht, und das ist wohl der Grund, warum der Tomcat als "App-Server light" so beliebt ist. Sorry, ich bin abgeschweift.
Johnson ist mittlerweile schon bei den Profiles. Es wird erst mal drei davon geben und sie sind Ausprägungen der Plattform. Die einfachste Variante "Profile A" (ich denke mal, dass sich der Name noch ändern wird) ist im wesentlichen der Tomcat: Servlets, JSPs, EL und JSTL und solche Sachen. Wichtig sind dabei Änderungen in der Sichtweise: Die Extensibility schlägt wieder zu und so muss man z.B. nicht immer alles von Hand in die web.xml eintragen. Stattdessen wird es eine API dafür geben, so dass Frameworks einfacher auf der Java EE (light) Plattform aufsetzen können.
Profile B ist Profile A plus persistence und zwei Komponenten-Modelle (mit Fragezeichen). Eventuell wird es ein EJB 3.1 light geben, was auch immer das sein wird. Das zweite wird evtl. ein Web Beans Modell sein (JSR-299). Profile C wird ziemlich genau das sein, was wir jetzt schon als Java EE haben. Rod Johnson hat jetzt schon auf den Folien stehen, dass das volle Java EE wenig Relevanz hat.
Für Sun ist das natürlich eine gute Strategie: Mit dieser Strategie kann sich Java vielleicht noch ein paar Jahre unten gegen Ruby und oben gegen Dot.Net verteidigen. Ob es für Entwickler wirklich einen echten Effekt zeigt, wird sich noch zeigen: WebLogic, WebSphere und JBoss werden natürlich ihre Produktstrategie ein Stück weit unabhängig von Sun überdenken. Die Tendenzen dort gehen ja eher dahin, immer mehr in die Produkte zu packen - und sei es nur als Marketing Fake. Aber das ist ein anderes Thema. Rod Johnson kommt zu ähnlichen Schlüssen auf seiner nächsten Folie. Interessant, die nächste Statistik kommt auch (siehe oben) - Tomcat ist die am häufigsten eingesetzte Plattform für Enterprise Java. Was Sun hier also als Strategie fährt ist einfach ihre Anpassung an die Realität. An die Realität, die wir hier im Auditorium schon alle leben.
Jetzt zu den lange angekündigten Predictions:
"Real competition will return to the application server market", jaja, Tomcat kann sich dann auch den Java EE-Stempel aufkleben und damit hat man einen weiteren Marktteilnehmer. Und neben Tomcat noch viele andere. Damit gibt es eben eine niedriger Markteintrittsschwelle. Ok, im wesentlichen hatte ich den Punkt ja oben auch schon, denn der Punkt ist doch, dass die vollen Java EE Appserver Funktionalität realisieren, die nur die wenigsten nutzen. Geht mir im übrigen auch so - im letzten Projekt hatten wir einen WebLogic, benutzt davon haben wir die Servlet Engine für die WebServices und JMS. Das hätten wir auch mit dem Tomcat machen können.
Prediction 2: "Tomorrow's application server will be lightweight and modular". Die JBoss-Leute schreien jetzt "haben wir schon, haben wir schon". Richtig. Und alle anderen werden laut Johnson auf OSGi als technische Basis setzen.
Prediction 3: "Tommorow's application server will not merely implement JCP specifications". Komisch - das tun sie doch heute schon nicht. Und wenn, dann pushen sie ihre originären Sachen als neue Standard-Vorschläge. Aber Johnson führt das noch ein bisschen aus: Es wird nicht nur JCP standards geben, sondern z.B. auch die von der OSGi Allience. Viel interessanter ist der Umkehrschluss, in dem Rod Johnson ausführt, dass der JCP nicht immer das Rad neu erfinden muss. Wer braucht commons logging, wenn es schon log4j gibt. Wer braucht ein neues EJB-Konzept, wenn es Spring gibt. JSR 277, wenn es OSGi gibt. Ob sich diese Einstellung endlich durchsetzen kann? Ich bin kein Fan davon, dass es nur (Gedanken-) Monopole gibt und wer eine bessere Idee hat, der sollte sie auch in Code umsetzen. Aber oft ist es eben keine bessere Idee, manchmal noch nicht mal eine andere. Eben nur eine andere Organisation - das not invented here Phänonomen macht auch vor dem JCP nicht halt. Damit kommt auch die extended prediction: the JCP will run on open source.
Prediction 4: The market will address the gap between Tomcat and WebLogic/WebSphere. Das stimmt, denn das stimmt ja auch jetzt schon. Nur dass sich zum Teil jeder seine eigene Lösung strickt. Man kann auch einen Tomcat so produktiv einsetzen wie den WebLogic.
Prediction 5: The gap between application servers and ESBs will be bridget. Naja, das ist noch ein langer Weg. Es ist zum Beispiel immer noch ein weiter Weg dahin, dass meine Plattform entscheidet, ob es jetzt aus Lastgründen einen lokal deployten Service nutzt oder den gleichen Service auf einer anderen Maschine. Aber solche Features wären für mich ein echter Fortschritt auch für den SOA-Gedanken. Und auf den SOA-Gedanken kommt Rod Johnson auch gerade, klar, der liegt bei dem Thema ja nahe und das Buzzword trägt immer noch.
Prediction 6: The Black knight will be defeated. Oder anders ausgedrückt: EJB ist dying. Jaja, das ist keine Prediction, das ist eine Beobachtung. Wer macht schon EJB, wenn er stattdessen Spring machen kann. Interessante Statistik wieder - in den USA sieht man das mit EJB offensichtlich (noch) etwas anders. Aber - die erste witzige Statistik - die Kurven für die Entwicklung von Java EE und Cobol gleichen sich wie ein Ei dem anderen. Beides Legacy-Techniken.
In der Conclusion gesteht Johnson ein, dass Java EE 6 die Relevanz von Java EE erhöht, aber dass Java nicht mehr die Zukunft bestimmen wird.
Auf zur nächsten Session.
Aber zuerst mal zu den Faktoren, die Änderungen notwendig machen: Zuerst mal ist da die "productivity challenge" - dass man mit Ruby on Rails schneller ist in der Entwicklung von bestimmten Web-Applikationen ist als mit Java hat sich nun schon rumgesprochen. Der Punkt daran ist, dass die Java community an den "low hanging fruits" vorbeispringt. Warum also immer Rakentenphysik, wenn's auch einfach geht. Si!
Der zweite Grund für notwendige Änderungen ist einfach das Alter von Java EE. Java ist einfach nicht mehr schlank, weil sich mittlerweile eine Menge "baggage" angesammelt hat. Gut, ich hätte zwar "garbage" genommen, aber der Effekt ist der gleiche: Man muss das System wieder aufräumen, den Frühjahrsputz machen. Johnson sieht in Java EE 6 genau den Versuch, die Java Plattform auf Vordermann zu bringen. Die beiden Idees hinter Java EE 6 sind Extensibility und Profiles (steht auch im JSR-316). Die Grundlage für die Extensibility ist die Erkenntnis, das man nicht alles in die Plattform stecken muss, sondern dass die Plattform wirklich, ja was, eine Plattform für andere Frameworks sein sollte. Immerhin, die Erkenntnis ist für die Java EE Plattform wirklich neu. Klingt aber gut, denn mir geht das, beispielsweise mit den Appservern als Ergebnis von Java EE, oft so, dass ich viele der angebotenen Dienste nicht brauche. Andere auch nicht, und das ist wohl der Grund, warum der Tomcat als "App-Server light" so beliebt ist. Sorry, ich bin abgeschweift.
Johnson ist mittlerweile schon bei den Profiles. Es wird erst mal drei davon geben und sie sind Ausprägungen der Plattform. Die einfachste Variante "Profile A" (ich denke mal, dass sich der Name noch ändern wird) ist im wesentlichen der Tomcat: Servlets, JSPs, EL und JSTL und solche Sachen. Wichtig sind dabei Änderungen in der Sichtweise: Die Extensibility schlägt wieder zu und so muss man z.B. nicht immer alles von Hand in die web.xml eintragen. Stattdessen wird es eine API dafür geben, so dass Frameworks einfacher auf der Java EE (light) Plattform aufsetzen können.
Profile B ist Profile A plus persistence und zwei Komponenten-Modelle (mit Fragezeichen). Eventuell wird es ein EJB 3.1 light geben, was auch immer das sein wird. Das zweite wird evtl. ein Web Beans Modell sein (JSR-299). Profile C wird ziemlich genau das sein, was wir jetzt schon als Java EE haben. Rod Johnson hat jetzt schon auf den Folien stehen, dass das volle Java EE wenig Relevanz hat.
Für Sun ist das natürlich eine gute Strategie: Mit dieser Strategie kann sich Java vielleicht noch ein paar Jahre unten gegen Ruby und oben gegen Dot.Net verteidigen. Ob es für Entwickler wirklich einen echten Effekt zeigt, wird sich noch zeigen: WebLogic, WebSphere und JBoss werden natürlich ihre Produktstrategie ein Stück weit unabhängig von Sun überdenken. Die Tendenzen dort gehen ja eher dahin, immer mehr in die Produkte zu packen - und sei es nur als Marketing Fake. Aber das ist ein anderes Thema. Rod Johnson kommt zu ähnlichen Schlüssen auf seiner nächsten Folie. Interessant, die nächste Statistik kommt auch (siehe oben) - Tomcat ist die am häufigsten eingesetzte Plattform für Enterprise Java. Was Sun hier also als Strategie fährt ist einfach ihre Anpassung an die Realität. An die Realität, die wir hier im Auditorium schon alle leben.
Jetzt zu den lange angekündigten Predictions:
"Real competition will return to the application server market", jaja, Tomcat kann sich dann auch den Java EE-Stempel aufkleben und damit hat man einen weiteren Marktteilnehmer. Und neben Tomcat noch viele andere. Damit gibt es eben eine niedriger Markteintrittsschwelle. Ok, im wesentlichen hatte ich den Punkt ja oben auch schon, denn der Punkt ist doch, dass die vollen Java EE Appserver Funktionalität realisieren, die nur die wenigsten nutzen. Geht mir im übrigen auch so - im letzten Projekt hatten wir einen WebLogic, benutzt davon haben wir die Servlet Engine für die WebServices und JMS. Das hätten wir auch mit dem Tomcat machen können.
Prediction 2: "Tomorrow's application server will be lightweight and modular". Die JBoss-Leute schreien jetzt "haben wir schon, haben wir schon". Richtig. Und alle anderen werden laut Johnson auf OSGi als technische Basis setzen.
Prediction 3: "Tommorow's application server will not merely implement JCP specifications". Komisch - das tun sie doch heute schon nicht. Und wenn, dann pushen sie ihre originären Sachen als neue Standard-Vorschläge. Aber Johnson führt das noch ein bisschen aus: Es wird nicht nur JCP standards geben, sondern z.B. auch die von der OSGi Allience. Viel interessanter ist der Umkehrschluss, in dem Rod Johnson ausführt, dass der JCP nicht immer das Rad neu erfinden muss. Wer braucht commons logging, wenn es schon log4j gibt. Wer braucht ein neues EJB-Konzept, wenn es Spring gibt. JSR 277, wenn es OSGi gibt. Ob sich diese Einstellung endlich durchsetzen kann? Ich bin kein Fan davon, dass es nur (Gedanken-) Monopole gibt und wer eine bessere Idee hat, der sollte sie auch in Code umsetzen. Aber oft ist es eben keine bessere Idee, manchmal noch nicht mal eine andere. Eben nur eine andere Organisation - das not invented here Phänonomen macht auch vor dem JCP nicht halt. Damit kommt auch die extended prediction: the JCP will run on open source.
Prediction 4: The market will address the gap between Tomcat and WebLogic/WebSphere. Das stimmt, denn das stimmt ja auch jetzt schon. Nur dass sich zum Teil jeder seine eigene Lösung strickt. Man kann auch einen Tomcat so produktiv einsetzen wie den WebLogic.
Prediction 5: The gap between application servers and ESBs will be bridget. Naja, das ist noch ein langer Weg. Es ist zum Beispiel immer noch ein weiter Weg dahin, dass meine Plattform entscheidet, ob es jetzt aus Lastgründen einen lokal deployten Service nutzt oder den gleichen Service auf einer anderen Maschine. Aber solche Features wären für mich ein echter Fortschritt auch für den SOA-Gedanken. Und auf den SOA-Gedanken kommt Rod Johnson auch gerade, klar, der liegt bei dem Thema ja nahe und das Buzzword trägt immer noch.
Prediction 6: The Black knight will be defeated. Oder anders ausgedrückt: EJB ist dying. Jaja, das ist keine Prediction, das ist eine Beobachtung. Wer macht schon EJB, wenn er stattdessen Spring machen kann. Interessante Statistik wieder - in den USA sieht man das mit EJB offensichtlich (noch) etwas anders. Aber - die erste witzige Statistik - die Kurven für die Entwicklung von Java EE und Cobol gleichen sich wie ein Ei dem anderen. Beides Legacy-Techniken.
In der Conclusion gesteht Johnson ein, dass Java EE 6 die Relevanz von Java EE erhöht, aber dass Java nicht mehr die Zukunft bestimmen wird.
Auf zur nächsten Session.
JAX Eröffnung
Tag 1 der JAX 08. Gestern war ich ja schon auf Tag 0, dem Agile Day vor der JAX. Sebastien Meyen -Chefredakteur bei S&S Media, dem Host der JAX - sagt es gerade, es waren ca. 400 Leute da. Jetzt erzählt er erst mal was über den aktuellen Kontext - welche Themen sind interessant (Architekturen, Agilität, Techniken), in welchem Marktumfeld sind wir hier alle unterwegs: Java EE, EJB 3, Alternative Stacks, Vom Web 2.0 zum Enterprise 2.0 und dynamische Sprachen und Scripting.
Sebastian Meyen geht gerade bei den dynamischen Sprachen vor allem auf Groovy ein. Ich persönlich finde das ja sehr nett, denn ich halte - auf der Java Plattform, die ja sehr gelungen ist - Groovy für die bessere Wahl als beispielsweise JRuby. Gut, aber das ist vermutlich der nächste Glaubenskrieg. Zusammengesetzt sieht Meyen folgenden Stack: Unten Java EE & Co., darüber eine "dynamischer" Layer von dynamischen Sprachen oder Rule Engines und darüber noch eine weitere Schicht von domain-specific languages.
Für das Eclipse Forum gibt's noch den Hinweis auf die Opening Session, in der auch der Weg zu Eclipse 4.0 dargestellt wird. Vielleicht sollte ich da noch hingehen? Ich kann mich doch nicht zerreißen.
Hey, interessante Frage von der Bühne: Wer war eigentlich letztes Jahr schon auf der JAX? Ich würde mal schätzen, dass sich so ungefähr ein Fünftel meldet. Und wer war vor zwei Jahren schon da? Überraschung: Die gleichen Leute. Mal sehen, ob ich nächstes Jahr eine von den beiden Fragen mit ja beantworten kann...
Gäääähn, jetzt werden die ganzen "großen und wichtigen Namen" genannt. Lesen kann ich selbst, steht doch alles im Programm. Schade, bis gerade war die Eröffnung doch ganz nett gemacht. Naja, gehört halt dazu...
Sebastian Meyen geht gerade bei den dynamischen Sprachen vor allem auf Groovy ein. Ich persönlich finde das ja sehr nett, denn ich halte - auf der Java Plattform, die ja sehr gelungen ist - Groovy für die bessere Wahl als beispielsweise JRuby. Gut, aber das ist vermutlich der nächste Glaubenskrieg. Zusammengesetzt sieht Meyen folgenden Stack: Unten Java EE & Co., darüber eine "dynamischer" Layer von dynamischen Sprachen oder Rule Engines und darüber noch eine weitere Schicht von domain-specific languages.
Für das Eclipse Forum gibt's noch den Hinweis auf die Opening Session, in der auch der Weg zu Eclipse 4.0 dargestellt wird. Vielleicht sollte ich da noch hingehen? Ich kann mich doch nicht zerreißen.
Hey, interessante Frage von der Bühne: Wer war eigentlich letztes Jahr schon auf der JAX? Ich würde mal schätzen, dass sich so ungefähr ein Fünftel meldet. Und wer war vor zwei Jahren schon da? Überraschung: Die gleichen Leute. Mal sehen, ob ich nächstes Jahr eine von den beiden Fragen mit ja beantworten kann...
Gäääähn, jetzt werden die ganzen "großen und wichtigen Namen" genannt. Lesen kann ich selbst, steht doch alles im Programm. Schade, bis gerade war die Eröffnung doch ganz nett gemacht. Naja, gehört halt dazu...
Montag, 21. April 2008
Agiles Projektmanagement bei Werkverträgen
Ok, es hat etwas gedauert, bis Dirk Sohn in Fahrt kam. Erst hat er sich mühevoll auf einen Life of Brian Witz hingearbeitet ("Ein Schuh"), der Vortrag drohte schon zäh zu werden. Aber kaum hatte er den Schuh umständlich erklärt fiel alle Zurückhaltung von ihm ab und er drehte richtig auf. Dieser Vortrag war definitiv der Höhepunkt. Humoristisch, aber auch inhaltlich.
Das Destillat der Projekterfahrungen, ich sage nur "bottom-up controlling" oder "ein Wiki ist es nicht", war ebenso informativ wie Dirk Sohns Ansichten zur Iteration 0, die - ich habe das auch schon erlebt - mitunter dogmatisch diskutiert wird.
Schön, dass Dirk Sohn am Ende seines Vortrags sogar noch auf die zu Beginn versprochenen Werkverträge kam. Aber eigentlich war das nur die Abrundung des Vortrags.
Das Destillat der Projekterfahrungen, ich sage nur "bottom-up controlling" oder "ein Wiki ist es nicht", war ebenso informativ wie Dirk Sohns Ansichten zur Iteration 0, die - ich habe das auch schon erlebt - mitunter dogmatisch diskutiert wird.
Schön, dass Dirk Sohn am Ende seines Vortrags sogar noch auf die zu Beginn versprochenen Werkverträge kam. Aber eigentlich war das nur die Abrundung des Vortrags.
Product Owner - eine Herausforderung
Das ganze Plenum voller Leute geschätzte zwei bis dreihundert und auf die Frage, ob jemand schon Product Owner ist oder noch werden will meldet sich kein einziger. Vielleicht geht es ja allen so wie mir... die Rolle "in Reinform" wird so wohl wirklich selten gelebt.
Aber immerhin - der Talk ist ein echtes Highlight. Urban Ernst beleuchtet seine Erfahrungen als Product Owner eines 20-Entwickler-Projekts. (Zwischendurch ist mir der Saft ausgegangen - also genauer meinem Notebook - so dass es kein Live-Blogging gibt.)
Ganz nebenbei räumt Urban Ernst noch mit einigen Lebenslügen agiler Entwicklung und insbesondere von Scrum auf: Projektteams organisieren sich nicht einfach so von selbst. Jaja, schon klar - das hat so auch nie jemand gesagt. Aber es ist gut, wenn zur Abwechslung mal wieder jemand darauf hinweist, wieviel Arbeit das in der Realität ist.
Ein reichliches Learning war die Sprint Goal Presentation und die Story Abnahmen, in denen der Product Owner die aktive Rolle übernimmt. Und auch ganz wichtig: Der Prozess läuft wesentlich runder, wenn Product Owner und Scrum Master das gleiche Verständnis vom Prozess haben und so in die gleiche Richtung ziehen.
Ich setze noch einen drauf: Es ist essentiell, dass alle im Projekt den gleichen Prozess leben. Nicht mit der gleichen Intensität, klar. Aber über kurz oder lang macht es das Team mürbe, wenn es verschiedene Vorstellungen des Prozesses gibt. Also noch mal: Schon die Vorstellung des Prozesses. Denn sonst wird das nie ein Prozess.
Aber immerhin - der Talk ist ein echtes Highlight. Urban Ernst beleuchtet seine Erfahrungen als Product Owner eines 20-Entwickler-Projekts. (Zwischendurch ist mir der Saft ausgegangen - also genauer meinem Notebook - so dass es kein Live-Blogging gibt.)
Ganz nebenbei räumt Urban Ernst noch mit einigen Lebenslügen agiler Entwicklung und insbesondere von Scrum auf: Projektteams organisieren sich nicht einfach so von selbst. Jaja, schon klar - das hat so auch nie jemand gesagt. Aber es ist gut, wenn zur Abwechslung mal wieder jemand darauf hinweist, wieviel Arbeit das in der Realität ist.
Ein reichliches Learning war die Sprint Goal Presentation und die Story Abnahmen, in denen der Product Owner die aktive Rolle übernimmt. Und auch ganz wichtig: Der Prozess läuft wesentlich runder, wenn Product Owner und Scrum Master das gleiche Verständnis vom Prozess haben und so in die gleiche Richtung ziehen.
Ich setze noch einen drauf: Es ist essentiell, dass alle im Projekt den gleichen Prozess leben. Nicht mit der gleichen Intensität, klar. Aber über kurz oder lang macht es das Team mürbe, wenn es verschiedene Vorstellungen des Prozesses gibt. Also noch mal: Schon die Vorstellung des Prozesses. Denn sonst wird das nie ein Prozess.
Kollaboration in IT-Projekten
Dr. Georg Molter und Torben Knerr reden jetzt über Team Kollaboration in Java Projekten, stellen Herausforderungen und Anforderungen vor und zeigen dann Kollaborationswerkzeuge auf drei Leveln: Level 1 als Zusammenstellung von Open Source Tools, Level 2 als spezielle Kollaborationstools und Level 3 als in die IDE integrierte Kollaborationsplattformen.
Die Probleme räumlich verteilter Kollaboration sind ja hinlänglich bekannt - nicht nur aus der Softwareentwicklung. Die drei "bedeutsamen" von Molter und Knerr lassen sich eigentlich zusammendampfen auf "schlechte Kommunikation". Das führt dann beispielsweise zu unterschiedlichen Auffassungen der Requirements, zu intransparenter Planung und schwierigem Monitoring. Weitere Implikationen sind die verfügbaren Kommunikationsmittel (Telefon, Chat, Filesharing, Video-Conferencing) etc. inklusive der Performance dieser Kommunikationsmittel.
Voraussetzungen für den Erfolg einer räumlich verteilten kollaborativen Entwicklung sind eine einheitliche Begriffswelt, Prozesse und Tools (z.B. zur Versionsverwaltung, Verwaltung der Testfälle, etc.), ein gemeinsames Verständnis von den Work Items und den Requirements und die Unterstützung durch geeignete Tools zur Kollaboration. Viele "Disziplinen" sind (durch Tools) zu erfüllen, um eine gute Kollaborationsumgebung zu bieten.
Molter und Knerr schnappen sich nun einige der Tools und checken einfach mal durch, in wie weit diese die Disziplinen erfüllen. Die beruhigende Aussage vorweg: In der Java-Welt sind wir gar nicht so schlecht unterwegs. Ich erwarte mal, dass die Tools auf den unterschiedlichen Levels unterschiedlich gut geeignet sind. Die einzelnen Tools möchte ich hier jetzt nicht weitergeben, das war vor allem eine Slide Show mit Screenshots.
Der Talk war leider genau das - eine Slide Show von Screenshots mit einigen Allgemeinplätzen über Kollaboration im Allgemeinen. Ich hoffe auf den Nachmittag.
Die Probleme räumlich verteilter Kollaboration sind ja hinlänglich bekannt - nicht nur aus der Softwareentwicklung. Die drei "bedeutsamen" von Molter und Knerr lassen sich eigentlich zusammendampfen auf "schlechte Kommunikation". Das führt dann beispielsweise zu unterschiedlichen Auffassungen der Requirements, zu intransparenter Planung und schwierigem Monitoring. Weitere Implikationen sind die verfügbaren Kommunikationsmittel (Telefon, Chat, Filesharing, Video-Conferencing) etc. inklusive der Performance dieser Kommunikationsmittel.
Voraussetzungen für den Erfolg einer räumlich verteilten kollaborativen Entwicklung sind eine einheitliche Begriffswelt, Prozesse und Tools (z.B. zur Versionsverwaltung, Verwaltung der Testfälle, etc.), ein gemeinsames Verständnis von den Work Items und den Requirements und die Unterstützung durch geeignete Tools zur Kollaboration. Viele "Disziplinen" sind (durch Tools) zu erfüllen, um eine gute Kollaborationsumgebung zu bieten.
Molter und Knerr schnappen sich nun einige der Tools und checken einfach mal durch, in wie weit diese die Disziplinen erfüllen. Die beruhigende Aussage vorweg: In der Java-Welt sind wir gar nicht so schlecht unterwegs. Ich erwarte mal, dass die Tools auf den unterschiedlichen Levels unterschiedlich gut geeignet sind. Die einzelnen Tools möchte ich hier jetzt nicht weitergeben, das war vor allem eine Slide Show mit Screenshots.
Der Talk war leider genau das - eine Slide Show von Screenshots mit einigen Allgemeinplätzen über Kollaboration im Allgemeinen. Ich hoffe auf den Nachmittag.
Einführung von agilen Prozessen
"Wie wird man agil?" ist die Frage, an der sich Jutta Eckstein in ihrem Talk entlanghangelt. Interessante Frage, weil die Einführung doch immer wieder ein schwieriger Prozess ist. Im übrigen: Veränderung ist immer ein schwieriger Prozess, warum sollte die Veränderung zu einem agilen Vorgehen also leichter gehen. Nach der "klassischen" Unterscheidung in bottom-up und top-down (heißt hier "guerilla tactics" und "command and control", aber die Begriffe sind mir persönlich zu kriegerisch) konstatiert Jutta Eckstein, dass idealerweise alle am gleichen Strang ziehen - Managment, Kunde, Entwickler... Naja, wann passiert das in der Realität schon? In meiner jedenfalls nicht. Aber genau darum geht es ja Jutta Eckstein. Wie führt man agiles Vorgehen trotzdem erfolgreich ein?
Folgende Punkte sind demnach wichtig:
In einer Reihe von Retrospektiven sammelt man zuerst mal die Erfahrungen vergangener Projekte oder des aktuellen Projekts. Das Statement von Jutta Eckstein ist, dass als Ergebnis dieser Reflexion über das eigene Vorgehen und das gewünschte Vorgehen in der Regel etwas agiles hervorgeht.
Readiness / Enabling Workshops schaffen - meistens mit den Entscheidern, weniger mit den Entwicklern - das Verständnis und legen den Grundstein für das weitere Vorgehen. Wichtige Fragen dabei sind "Was machen wir schon?", "Was ist einfach umzusetzen?", "Was ist wirklich schwierig?" und "Was ist unmöglich?". Klar, raus kommt die Entscheidung, ob man überhaupt agil vorgehen kann und was man gegebenfalls noch zu tun hat.
Wenn man die Entscheidung hat, dann kann man loslegen. Hier kommt der Consultant durch - verkaufen, verkaufen, verkaufen. Mindestens hier kann man Schulungen verkaufen. Was sollte man aber zum loslegen machen? Training und Coaching sollte hier einfach die ersten Schritte begleiten, also einfach mal die ersten Iterationen planen etc. Gleichzeitig braucht man einen, wie Jutta Eckstein das ausdrückt, "Passionate change agent", also jemand, der mit Leidenschaft für die Einführung der Agilität einsteht. Ich fühle mich angesprochen.
Leider geht Jutta Eckstein nicht (direkt) darauf ein, wie man das Team dazu bringt, im Verlauf des Prozesses immer mehr Verantwortung von sich aus zu übernehmen. Sie sagt nur, dass der Erfolg der Einführung von drei Rollen entscheident abhängt: Dem project lead, dem passionate change agent und dem technical leader.
Um dauerhaften Erfolg zu haben, muss man den Spagat zwischen "Anfängern" auf der einen Seite und "Agilen" auf der anderen Seite schaffen. Geht nur mit Rezept für die Anfänger, auch wenn das der Agilität eigentlich widerspricht. Natürlich sind immer wiederkehrende Retrospektiven hilfreich, um die eigenen Erfahrungen zur reflektieren und den Prozess an die eigenen Bedürfnisse anzupassen. Wirklich hilfreich ist es natürlich, wenn der Leidenschaftliche im Laufe des Projekts auf die anderen Teammitglieder abfärbt.
Damit sind wir durch den Talk durch. Wenn ich jetzt mal eine Retrospektive mache, dann hoffe ich mal, dass das nur die erste Iteration im Projekt "Agile Day" war, denn bisher kamen für mich keine brandneuen Erkenntnisse durch. An den wirklichen Knackpunkten hat sich Jutta Eckstein - natürlich auch durch die Kürze der Zeit gebremst - ausgeschwiegen. Für mich sind die Knackpunkte auf diesem Feld nämlich die Unterstützung des agilen Prozesses durch die Entwickler auf der einen Seite (der Veränderungsprozess ist in der Regel doch extrem von einzelnen Personen abhängig) und durch die übrigen an einem Projekt beteiligten andererseits. Insbesondere Vertrieb, Mitarbeiter-Plaung und Controlling sehe ich da als interessante Faktoren: Der Vertieb meint, agiles Vorgehen schlechter verkaufen zu können als ein Festpreisprojekt. Für die Mitarbeitereinsatzplaung ist es nötig, nicht nur genaue "Schätzungen" abzugeben - die natürlich keiner als Schätzungen anerkennt, aber das ist ein anderes Thema - die Mitarbeiter machen ja in der Regel nicht nur dieses eine (agile) Projekt, sondern auch noch andere Projekte, und so weiter und so fort.
Das Controlling kann naturgemäß mit Agilität nur sehr schwer umgehen - wie soll man beispielsweise den Fertigstellungsgrad bei etwas messen, das einfach per Definition nie fertig ist, sondern sich ständig in einem Prozess der Änderung befindet.
Ich hoffe, der Tag erhellt noch ein paar von diesen Fragen. Die Titel klingen ja interessant.
Folgende Punkte sind demnach wichtig:
In einer Reihe von Retrospektiven sammelt man zuerst mal die Erfahrungen vergangener Projekte oder des aktuellen Projekts. Das Statement von Jutta Eckstein ist, dass als Ergebnis dieser Reflexion über das eigene Vorgehen und das gewünschte Vorgehen in der Regel etwas agiles hervorgeht.
Readiness / Enabling Workshops schaffen - meistens mit den Entscheidern, weniger mit den Entwicklern - das Verständnis und legen den Grundstein für das weitere Vorgehen. Wichtige Fragen dabei sind "Was machen wir schon?", "Was ist einfach umzusetzen?", "Was ist wirklich schwierig?" und "Was ist unmöglich?". Klar, raus kommt die Entscheidung, ob man überhaupt agil vorgehen kann und was man gegebenfalls noch zu tun hat.
Wenn man die Entscheidung hat, dann kann man loslegen. Hier kommt der Consultant durch - verkaufen, verkaufen, verkaufen. Mindestens hier kann man Schulungen verkaufen. Was sollte man aber zum loslegen machen? Training und Coaching sollte hier einfach die ersten Schritte begleiten, also einfach mal die ersten Iterationen planen etc. Gleichzeitig braucht man einen, wie Jutta Eckstein das ausdrückt, "Passionate change agent", also jemand, der mit Leidenschaft für die Einführung der Agilität einsteht. Ich fühle mich angesprochen.
Leider geht Jutta Eckstein nicht (direkt) darauf ein, wie man das Team dazu bringt, im Verlauf des Prozesses immer mehr Verantwortung von sich aus zu übernehmen. Sie sagt nur, dass der Erfolg der Einführung von drei Rollen entscheident abhängt: Dem project lead, dem passionate change agent und dem technical leader.
Um dauerhaften Erfolg zu haben, muss man den Spagat zwischen "Anfängern" auf der einen Seite und "Agilen" auf der anderen Seite schaffen. Geht nur mit Rezept für die Anfänger, auch wenn das der Agilität eigentlich widerspricht. Natürlich sind immer wiederkehrende Retrospektiven hilfreich, um die eigenen Erfahrungen zur reflektieren und den Prozess an die eigenen Bedürfnisse anzupassen. Wirklich hilfreich ist es natürlich, wenn der Leidenschaftliche im Laufe des Projekts auf die anderen Teammitglieder abfärbt.
Damit sind wir durch den Talk durch. Wenn ich jetzt mal eine Retrospektive mache, dann hoffe ich mal, dass das nur die erste Iteration im Projekt "Agile Day" war, denn bisher kamen für mich keine brandneuen Erkenntnisse durch. An den wirklichen Knackpunkten hat sich Jutta Eckstein - natürlich auch durch die Kürze der Zeit gebremst - ausgeschwiegen. Für mich sind die Knackpunkte auf diesem Feld nämlich die Unterstützung des agilen Prozesses durch die Entwickler auf der einen Seite (der Veränderungsprozess ist in der Regel doch extrem von einzelnen Personen abhängig) und durch die übrigen an einem Projekt beteiligten andererseits. Insbesondere Vertrieb, Mitarbeiter-Plaung und Controlling sehe ich da als interessante Faktoren: Der Vertieb meint, agiles Vorgehen schlechter verkaufen zu können als ein Festpreisprojekt. Für die Mitarbeitereinsatzplaung ist es nötig, nicht nur genaue "Schätzungen" abzugeben - die natürlich keiner als Schätzungen anerkennt, aber das ist ein anderes Thema - die Mitarbeiter machen ja in der Regel nicht nur dieses eine (agile) Projekt, sondern auch noch andere Projekte, und so weiter und so fort.
Das Controlling kann naturgemäß mit Agilität nur sehr schwer umgehen - wie soll man beispielsweise den Fertigstellungsgrad bei etwas messen, das einfach per Definition nie fertig ist, sondern sich ständig in einem Prozess der Änderung befindet.
Ich hoffe, der Tag erhellt noch ein paar von diesen Fragen. Die Titel klingen ja interessant.
Neues von der JAX 08
So, es gibt mal wieder was neues in meinem Blog: Ich bin gerade auf der JAX, genauer auf dem Agile Day. Auf der Zugfahrt habe ich gerade noch den Tonabnehmer von Frank Westphal zum Thema gehört und dabei auch einige interessante Aspekte zu dem mittlerweile doch relativ "alten" Thema Agilität gehört, die sich auch mit meinem Erfahrungshorizont decken: Eine interessante Frage ist beispielsweise, wie man Agilität in das gesamte Unternehmen trägt, wie man agile Software-Entwicklung beispielsweise mit einem bestehenden Controlling integriert. Agiles Controlling, gibt's das? Mal sehen, was zu solchen Themen auf der JAX passiert.
Abonnieren
Posts (Atom)
Posts
