jax08: Advanced GlassFish

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.

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?