On the ROXX: Flex, REST, Akka, Scala, MongoDB

Im Praxiseinsatz

Beginnen wir mit der gewählten Technologie für die Benutzeroberfläche: Flex. Wie in Listing 1 angedeutet, bietet Flex eine ganze Menge Komfort, um schicke Benutzeroberflächen mit sehr wenig Aufwand zu erstellen. Die Einarbeitungszeit für erfahrene Java-Entwickler hält sich in Grenzen, und man wird stets durch eine sehr hochwertig wirkende Oberfläche belohnt. Allerdings hält Flex auch die eine oder andere Hürde parat. So können beispielsweise Fehler im Data Binding recht schwierig zu finden sein. Auch muss man wissen, wie der Flash-Player in Produktion mit Errors (vergleichbar mit Java Exceptions) umgeht: Diese werden nämlich einfach verworfen und nie bis zum User durchgereicht. Außerdem enthalten Errors keinen Stacktrace, solange man nicht mit der Debugging-Variante des Flash-Players arbeitet. Der Build-Prozess für Flex-Applikationen kann mit Ant professionalisiert und automatisiert werden. Außerdem ist es möglich, das Projekt in Library-Projekte zu unterteilen und so zu modularisieren. Eine unverständliche, aber dennoch beherrschbare Schwierigkeit wirft Flex im Zusammenspiel mit REST auf: Alle Requests außer POST und GET werden automatisch in einen der vorherigen umgewandelt, bevor die HTTP-Pakete auf die Reise gehen. In unserem Fall ist die Lösung simpel: Wir senden nur POST Requests mit einem Custom Header, der den eigentlichen Request-Typ enthält. In unserem Fall GET, PUT, POST oder DELETE. Da wir auch den Server unter unserer Kontrolle haben, ist es dort ein Leichtes, mit einem vor Akka Mist hängenden Servlet-Filter den HTTP Request anhand des Header-Eintrags wieder umzubiegen. Ein wirkliches Problem entsteht hierbei jedoch, wenn man den Server nicht unter Kontrolle hat. In diesem Fall müsste eine aufwändige Proxy-Lösung aufgesetzt werden.

Der letzte und vielleicht wichtigste Punkt zum Thema Flex/Flash: Kann man davon ausgehen, dass alle potenziellen User den Flash-Player installiert haben? Diese Frage lässt sich leider nicht kurz und allgemeingültig beantworten. Nur so viel: Für eine Kletterrouten-Datenbank wäre es sicherlich sinnvoller, eine HTML5-Lösung (JavaScript + HTML) zu verwenden, um möglichst viele User mit Browser-Bordmitteln bedienen zu können. Noch viel relevanter ist dieser Punkt für einen Onlineshop – hier wäre Flash natürlich ein absolutes No-Go. Deutlich interessanter ist Flex dann schon z. B. für firmeninterne Applikationen, oder allgemeiner formuliert: einen fest definierten Benutzerkreis, der den Flash-Player ggf. installieren muss oder ohnehin installiert hat.

Ebenfalls an dieser Stelle erwähnt werden müssen die aktuellen Entwicklungen im Flash-Umfeld: Im November 2011 hat Adobe bekanntgegeben, das Flex SDK an die Apache Foundation zu übergeben und den Flash-Player für Mobilgeräte nicht weiterzuentwickeln [7], [8]. Außerdem arbeiten Adobe und Google an Produkten zur Konvertierung von Flash-Artefakten in HTML5 (Adobes Wallaby [9]: Konvertierung von .fla nach HTML5 und Googles Swiffy [10]: Konvertierung von .swf nach HTML5). Angesichts dieser letzten Entwicklungen erscheinen HTML5-basierte Frontends derzeit die sinnvollere Alternative zu sein. Ein möglicher Kandidat für ein JavaScript-basiertes UI wäre JQuery-UI [11] – aber auch so genannte Full-Stack-Frameworks, die vom Client bis zum Server Unterstützung bieten, so z. B. Leon [12].

Genug der UIs. Kommen wir zur zweiten Ebene unseres Technologie-Stacks aus Abbildung 2, Servlets 3.0 im Zusammenspiel mit Akka. Seit dem Start des ROXX-Projekts ist einige Zeit vergangen. Jetty 8, mit voller Servlets-3.0-Unterstützung, ist seit geraumer Zeit in der finalen Version releast und hat damit einige während der Entwicklung aufgetretene Probleme bedeitigt. Die Akka Actors bieten eine hervorragende Möglichkeit, hoch parellelisierbaren Code zu erstellen und sind auch im Nicht-Scala-Umfeld eine Überlegung wert (Java API). Derzeit ist Akka vor allem im Bankensektor stark vertreten. Zudem wird das Aktoren-Modell aber bereits seit vielen Jahren im Telekommunikationsbereich eingesetzt. Beides spricht durchaus für einen gewissen Reifegrad. Auch in diesem Projekt hat Akka nie zu einem Problem geführt. Das Konzept REST ist eigentlich unstrittig für Webapplikationen und in den allermeisten Fällen eine sehr gute Wahl. Im konkreten Fall, im Zusammenspiel mit dem Flash-Player, jedoch nicht besonders gut geeignet, da der Flash-Player den zuvor beschriebenen Einschränkungen unterliegt und einige Workarounds nötig macht. JSON als Datenformat dürfte ebenfalls in den meisten Fällen eine gute Wahl sein. Gegenüber XML ist die zu übertragende Datenmenge deutlich geringer und kann durch Verwendung von BSON noch weiter verringert werden. MongoDB dürfte, als Vertreter der No-SQL-Fraktion, für die meisten Web-2.0-Projekte die sinnvolle Alternative zu relationalen Datenbanken sein. Neben den Vorteilen bei Skalierbarkeit, Datenverteilung und Datensicherung ist vor allem auch der Entwicklungsprozess deutlich einfacher und damit schneller. Möglich wird dies durch die Tatsache, dass kein Schema benötigt wird. Es müssen also nicht massenweise SQL-Statements abgesetzt werden, um eine Objektstruktur zu verändern. Dennoch ist hier ein Wort der Warnung angebracht: Man sollte nicht leichtsinnig ein Produktivprojekt mit einer NoSQL-Datenbank starten, ohne zuvor Erfahrungen mit dem konkreten System gesammelt zu haben. Wenn es schnell gehen soll und NoSQL als Waffe der Wahl auserkoren ist, so empfiehlt es sich, zumindest zeitweise externe Hilfe in Anspruch zu nehmen. MongoDB ist inzwischen als NoSQL-Datenbank auf dem Markt gesetzt und kann somit einen gewissen Pool an fähigen Entwicklern bieten. Zudem wird MongoDB dadurch gestützt, dass die Gründerfirma 10gen [13] kommerziellen Support anbietet.

Der letzte Punkt gilt ebenso für den Kern der Serverseite: Scala als Sprache. Scala bietet hervorragende Möglichkeiten, kompakten Code zu schreiben und dadurch hoch produktiv zu arbeiten. Dennoch sollte klar sein, dass Scala, trotz der Nähe zu Java, eine vollkommen eigenständige Sprache ist. Und diese will gelernt sein! Die Frage, ob Scala nun eine komplexe oder eine eher einfache Sprache ist, wird im Moment heiß diskutiert [14]. In jedem Fall muss Scala als Sprache von allen beteiligten Entwicklern akzeptiert und verstanden werden. Außerdem muss an dieser Stelle erwähnt werden, dass im gesamten Scala-Umfeld deutlich mehr Bewegung herrscht als im Java-Umfeld. Das bedeutet einerseits, dass man schneller von Neuerungen profitiert. Im Umkehrschluss bedeutet das aber auch, dass man stets die neuesten Entwicklungen verfolgen und alle Abhängigkeiten auf einem möglichst aktuellen Stand halten sollte. In diesem Zusammenhang empfiehlt es sich ganz besonders, ausreichend Unit Tests zu schreiben, um beim Aktualisieren von Bibliotheken bestmöglich auf unerwartete Änderungen regieren zu können. Auch in diesem Bereich bietet Scala wunderbare Möglichkeiten. So macht sich das Testframework ScalaTest beispielsweise die Möglichkeit von Scala zu Nutze, interne DSLs zu definieren, um den Umgang mit Mocking-Frameworks wie mockito [15] zu vereinfachen. Aus dieser Kombination (ScalaTest mit einer DSL für Tests und mockito mit DSL) resultieren Testfälle, die fast wie natürliche Sprache aussehen, sich daher sehr leicht lesen lassen und sehr übersichtlich sind. Auch im vorgestellten Showcase ROXX kommt ScalaTest mit mockito zum Einsatz.

Fazit

Mit dem vorgestellten Stack lassen sich in kurzer Zeit und mit sehr wenig Code optisch hochwertige Webanwendungen erzeugen. Da Flex als UI-Framework nur für einen bestimmten Nutzerkreis tauglich ist und die aktuellen Entwicklungen um das SDK keine eindeutige Richtung erkennen lassen, sollten HTML5-Lösungen als Alternative in Betracht gezogen werden. Der Server-Stack hingegen setzt eine nicht unerhebliche Menge an Expertenwissen voraus, ist aber dennoch jedem Entwickler mit etwas Pioniergeist zu empfehlen – nicht zuletzt deshalb, weil Performance und Skalierbarkeit, zwei Aspekte, die vom vorgestellten Stack bestmöglich unterstützt werden, in heutigen Webprojekten eine zentrale Rolle spielen. Und diese Anforderungen werden wohl eher größer als kleiner.

Johannes Hohenbichler arbeitet bei der WeigleWilczek GmbH im Bereich Software-Development und entwickelt dort Applikationen, unter anderem auf Basis von Flex, Java, Scala und REST, Eclipse RCP und EJB. In seiner Freizeit ist er begeisterter Kletterer, was das Zustandekommen von ROXX erklärt.

Philipp Burgmer arbeitet ebenfalls bei der WeigleWilczek GmbH im Bereich Software-Development. Er beschäftigt sich unter anderem mit Scala, funktionaler Programmierung, Eclipse RCP/Eclipse 4 und User Interfaces. Private begeistert ihn die Fotografie und DJing.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.