Oracles Project Avatar – Komplettansatz für moderne Webanwendungen

Avatar ist ein Web-Framework, das eine Thin-Server-Architektur (TSA) nutzt und bei der Entwicklung moderner HTML5-Webanwendungen hilft. Es unterstützt dazu sowohl sogenannte View Components (Client) als auch Service-Komponenten (Server).

In Pocket speichern vorlesen Druckansicht 3 Kommentare lesen
Lesezeit: 16 Min.
Von
  • Markus Eisele
Inhaltsverzeichnis

Avatar ist ein Web-Framework, das eine Thin-Server-Architektur (TSA) nutzt und bei der Entwicklung moderner HTML5-Webanwendungen hilft. Es unterstützt dazu sowohl sogenannte View Components (Client) als auch Service-Komponenten (Server). Client-Komponenten werden in HTML5 und unter zusätzlicher Verwendung eines umfangreichen Sets von Widgets und Data Bindings – und etwas JavaScript – implementiert. Server-Komponenten dagegen sind vollständig in JavaScript umgesetzt und laufen "on top" auf einem Java-EE-7-Server, der dazu mit einem Avatar Scripting Container (Avatar.js) zu erweitern ist.

Seit einigen Jahren verändern sich die leichtgewichtigen Clients, die als Browser bekannt wurden, grundlegend. Spätestens seit der Einführung von Standards wie HTML5, CSS3 und den schnellen JavaScript-Engines eignen sich moderne Browser schon lange nicht mehr nur zur Anzeige einfacher HTML-Seiten, sondern haben sich zu leistungsstarken Anwendungsplattformen entwickelt.

Die Gründe für diese Entwicklung sind vielschichtig. Die Orientierung moderner Anwendungen in Richtung leichtgewichtiger Clients und schneller ladende Oberflächen hat ihren Ursprung sicherlich in den kostspieligen und komplexen Verteilmechanismen für native Anwendungen, die viele Unternehmen vermeiden wollten. Aber auch die steigende Leistungsfähigkeit der Rechner in Kombination mit den dazugewonnen Möglichkeiten der HTML- und CSS-Spezifikationen machen komplexe Webanwendungen immer interessanter.

Die Notwendigkeit zum serverseitigen, endgerätoptimierten Generieren von HTML nutzenden Oberflächen mit JavaServer Faces (JSF) oder gar JavaServer Pages (JSP) entfallen dank moderner HTML-Standards genauso wie komplexe, bildbasierte Layouts. Und auch die Anbindung von Hardware über den Browser scheint keine reine Fantasie mehr zu sein. Zudem wachsen die Kommunikationsfähigkeiten beständig. Wurden früher asynchron XML-Schnipsel über HTTP verschickt, kann JavaScript heute mit WebSocket und über REST ausgetauschten JSON-Datenpaketen sowie vielem mehr umgehen.

Was Designer und Front-End-Entwickler schon länger zu schätzen wissen, hat immer mehr Einfluss auf die Art, wie serverseitige Anwendungen entstehen. Statt Model, View und Controller (MVC) auf dem Server zu halten und nur die Repräsentation auf den Client zu transportieren sind die sogenannten Ein-Seiten-Anwendungen entstanden. In ihnen realisieren Entwickler nahezu alles in JavaScript. Lediglich Datenbereitstellung und komplexe Berechnungen obliegen dem Server. Diese Art der Anwendung entsteht entlang eines neuen Architektur-Stils, der auch als "Thin-Server-Architektur" (TSA) bekannt ist.

Java und vor allem Java EE hatte dieser Entwicklung lange Zeit nichts entgegenzusetzen. Die Verbreitung von JavaScript-Serverkomponenten auf Basis von beispielsweise Node.js beweist eindrucksvoll, wie stark der Trend tatsächlich ist. Aber auch Oracle sieht die Entwicklung und hat nicht zuletzt mit der Einführung der invokedynamic-Direktive in Java 7 den Grundstein für ein performantes JavaScript auf der JVM geschaffen. Mit der eigenen JavaScript-Implementierung Nashorn ließ sich direkt eine eindrucksvolle Referenzimplementierung schaffen.

Bereits Ende 2012 mehrten sich die Zeichen, dass das Ende von Oracles Bemühungen um JavaScript damit noch lange nicht erreicht war. Auf den Nashorn-Sessions der JavaOne im gleichen Jahr sprach man zudem erstmals von einer Node.jar-Umsetzung, also einer Java-Portierung von Node.js. Von Anfang an dabei war das EclipseLink-Team, das diverse Arten der Integration von JPA mit Nashorn und Node.jar aufzeigen konnte. Lange Zeit blieb es um beide Themen ruhig. Während die Nashorn-Implementierung stetig Fortschritte machte und ihren Weg in das im März 2014 erscheinende Java 8 findet, wurde nicht mehr über Node.jar gesprochen.

Nashorn ist mittlerweile zu 100 Prozent zu ECMA-262 kompatibel und bei Vergleichen außerdem deutlich schneller als die bisherige, von Mozilla gestellte Referenzimplementierung des JSR 223 (Scripting for Java) mit dem Namen Rhino. Oracle konnte die mit Java 7 gelegten funktionalen Grundlagen offensichtlich konsequent nutzen, um weitreichende Optimierungen für Java 8 vorzusehen. Damit avanciert die JVM zur optimalen Ablaufumgebung für JavaScript.

Dennoch war lange Zeit nicht klar, was mit dem anfänglich diskutierten Node.js-Port passieren würde. Das änderte sich erst im September 2013: Nach langem Warten hat Oracle das Projekt Avatar in diversen Keynotes und Sessions vorgestellt.

Avatar-Architektur (GlassFish mit Avatar Integration) (Abb.1)

(Bild: https://avatar.java.net/essentials.html)


Hinter dem ungewöhnlichen Namen "Avatar", den viele bisher nur als Titel eines James-Cameron-Films aus dem Jahr 2009 kennen, verbergen sich unterschiedliche Teile. Grundlage ist das Java Development Kit 8 zusammen mit der aktuellen Nashorn-Implementierung. Darauf aufsetzend existiert die eigentliche Avatar Runtime, die einen Compiler und eine Integration in den jeweiligen Java EE Server (Server Runtime) enthält. Avatar wird für den GlassFish 4 vorkonfiguriert ausgeliefert, auch wenn die Server Runtime lediglich die Servlet API verwendet.

Die für Avatar geschriebenen Anwendungen bestehen aus Views und/oder Services und können die Avatar API (Avatar.js) zur Implementierung verwenden. Services sind serverseitige Schnittstellen und bedienen sich wahlweise des Representational State Transfer (REST), der WebSockets oder der Server Send Events. Darüber hinaus können die eingebauten Node-Module und fast alle Module von Drittanbietern verwendet werden, solange sie keine nativen Anteile enthalten. Durch Nashorns Java-Integration lassen sich beliebige Bibliotheken der Sprache verwenden.

Da die View- und Service-Komponenten nicht eng aneinander gebunden sind, kann der Entwickler frei entscheiden, ob er beide oder nur einen Typen wählt und die jeweils andere Komponente auf traditionelle Art und Weise implementiert.

Die auf der JavaOne 2013 vorgestellte Avatar-Version enthielt noch einen kompletten GlassFish 4.0 und war gut 100 MByte groß. Das ist seit einigen Monaten anders, und das eigentliche Framework umfasst nur noch knapp 4,5 MByte. Es steht auf der Projekt-Webseite zum Herunterladen bereit und ist unter der GNU General Public License Version 2 (GPL) mit einer Class Path Exception lizenziert. Weitere notwendige Komponenten sind ein aktueller GlassFish Open Source Edition 4.0 Server (b89) sowie ein JDK 8 (b103 oder neuer), das sich aktuell als erster Release Candidate herunterladen lässt.

Nach dem Auspacken des GlassFish-Archivs in ein beliebiges Verzeichnis (beispielsweise <path_to>\glassfish4) ist die Datei avatar-1.0-ea.zip in das Unterverzeichnis d:\glassfish4\glassfish zu entpacken. Mehr Schritte erfordert die Installation nicht. Ist jetzt das JDK 8 vorhanden, lässt sich bei Bedarf noch die Konfigurationsdatei <path_to>\glassfish4\glassfish\config\asenv.bat/conf um den Eintrag:

AS_JAVA=<path_to>\jdk1.8.0

ergänzen. Damit kann der Nutzer sicherstellen, dass GlassFish mit dem notwendigen JDK startet. Für die weitere Arbeit sind zwei Umgebungsvariablen zu verändern:

AVATAR_HOME=D:\glassfish4
PATH=%AVATAR_HOME%\glassfish\bin;<path_to>\jdk1.8.0\bin

Avatar kommt mit einer Reihe von Beispielen und empfiehlt dem Einsteiger auch das direkte Verändern und Anpassen um erste Erfolge zu erzielen.

Eine einfache Beispielanwendung lässt sich direkt mit dem Kommando:

avatar new --example=hello

anlegen.