JavaOne: Oracle kündigt eine neue Version der JavaScript-Plattform an

Oracle präsentiert Avatar 2.0: Wohin geht die Reise?

Niko Köbler
© shutterstock.com/ScandinavianStock

Es ist schon ein Stück JavaOne-Tradition: Seit drei Jahren präsentiert Oracle auf der jährlich stattfindenden Entwicklerkonferenz in San Francisco Neuigkeiten rund um die JavaScript-Plattform Avatar. So auch in diesem Jahr.

Avatar startete ursprünglich als reines HTML5-/JavaScript-Framework. Seither ist es auf der Serverseite mit einer Node.js-Implementierung für die JVM (namens Avatar.js) sowie Java-EE-spezifischen Erweiterungen angereichert worden. „Project Avatar“, wie das Open-Source-Projekt hieß, ist aber nie über die Version 1.0-ea (für „early access“) hinausgekommen. In den letzten sechs Monaten ist kein einziger Commit im produktiven Code mehr im öffentlichen Repository erschienen – lediglich Tests und Kommentare wurden hinzugefügt oder geändert. Jetzt hat John Clingan, der Principal Product Manager des Oracle Glassfish-Teams, verantwortlich für die Avatar-Tätigkeiten, auf der diesjährigen JavaOne die Neuigkeiten im Avatar-Umfeld bekanntgegeben.

Gab es in der Vergangenheit immer wieder Verwirrungen um die Namensgebung von Avatar.js (die reine Node.js-Laufzeitumgebung für die JVM) und Project Avatar (die Java-EE-Feature-Erweiterungen), war jetzt nur noch die Rede von Avatar 2.0.

Application Server: passé

Die größte Änderung ist sicherlich, dass zur Ausführung von Avatar nun kein Java EE Application Server mehr notwendig ist. Bislang wurden die Produkte Glassfish 4 und seit Juni auch Oracles WebLogic in der Version 12.1.3 unterstützt bzw. benötigt. Avatar 2.0 läuft jetzt in einer eigenständigen JVM in einem eigenen Prozess und kann somit einfach über die Kommandozeile gestartet werden. Somit kann auch, wie bei Node.js, vom bereits integrierten HTTP-Modul Gebrauch gemacht werden, und man unterliegt hier nicht mehr den Beschränkungen bei der Nutzung der HTTP-Stacks. Mit diesem Feature können noch mehr Standard-Node-Applikationen, die das HTTP-Modul verwenden, in Avatar 2.0 eingesetzt werden. Über eine Management-Integration in den WebLogic Server denkt man derzeit noch nach. Dass diese auch kommen wird, ist sehr wahrscheinlich.

Parallele Event Loops

Ein großer Vorteil von Avatar 2.0 gegenüber Standard-Node-Umgebungen ist, dass sich mehrere parallele Event Loops in jeweils eigenen Threads ausführen lassen, diese aber nur einen einzelnen JVM-Prozess auf Betriebssystem-Ebene benötigen. Somit muss nur ein einzelner Prozess überwacht und gemanaged werden. Alle Event-Loops teilen sich über einen eingebauten HTTP-Load-Balancer einen einzelnen Port. Mit einem 16-Core-Prozessor können somit z. B. 16 Event Loops (jeder Loop in einem Thread pro Core) in nur einem einzelnen Prozess mit nur einem gemanagten Port betrieben werden. Will man mit Node.js diese Infrastruktur betreiben, ist schon ein deutlich komplexerer Aufwand nötig.

Die einzelnen Event-Loops können untereinander über einen internen Event- bzw. Message Bus oder über Shared State kommunizieren. Damit ist der Austausch von Daten und Zuständen zwischen verschiedenen Threads zur Laufzeit möglich. Ein Event Bus Listener für ein bestimmtes Topic kann einfach mittels 

// listen for messages on topic 'hello'
bus.on('hello', function(body, msg) {
    print(name + ' got message: ' + JSON.stringify(body));
});

registriert werden. Das Senden von Nachrichten (aus anderen, parallelen Threads) ist möglich mit 

// publishing to 'hello' topic:
bus.publish('hello', { x : 'x', y : 'y' });

Daten, die über den Event-Bus gesendet werden, sind nicht persistent – ist zum Sendezeitpunkt kein Empfänger vorhanden, verschwindet die Nachricht im Nirvana. Sollen Nachrichten dagegen für eine längere Zeit vorgehalten werden, da sie zu einem späteren Zeitpunkt benötigt werden, z. B. zur Wiederherstellung eines bestimmten Zustandes, dann kann der Shared State verwendet werden, der über ein Map API implementiert ist. 

var state = avatar.application.state;
state.put('key', {'value': 'myValue'});
var object = state.get('key');

Oracle greift hier sogar auf Coherence als Cache-Implementierung zurück, so dass sogar eine verteilte Kommunikation nicht nur über mehrere Threads in der JVM, sondern auch über mehrere Knoten und JVMs möglich wird. Da Coherence auch den JCache JSR-107 implementiert, ist sogar denkbar, dass andere Anwendungen, die nicht auf Avatar 2.0 basieren, an dieser Shared-State-Kommunikation teilnehmen können.

Aufmacherbild: „Javascript concept blue background with blue text“ von shutterstock.com / Urheberrecht: ScandinavianStock

[ header = Seite 2: Avatar Persistence ]

Avatar Persistence

Unter dem Titel „Avatar Persistence“ stellte Oracle ein Model-Store-API vor, das es ermöglicht, mit einem einheitlichen API (JSON-)Objekte in unterschiedlichen Datenbanken zu speichern. Diese Datenbanken können sowohl relationaler oder auch nicht-relationaler Natur sein (NoSQL). Da Avatar Persistence auf JPA (mit der EclipseLink-Implementierung) basiert, ist lediglich mit dem Austausch des JDBC-Treibers die Kommunikation mit einer anderen Datenbank möglich. Das folgende Beispiel verdeutlicht den Umgang mit dem neuen Model-Store-API: 

// define a connection to a data store
var store = avatar.newStore(‘mysql’, {
    host: 'localhost',
    port: 3306,
    database: 'test',
    username: 'root'
});

// define object 'Family'
var Family = avatar.newModel('family', {
        "name" : {
            type : "string",
            primary : true
        },
        "description" : "string"
    });
// define object 'Product'
var Product = avatar.newModel('product', {
        "name" : {
            type : "string",
            primary : true
        },
        "price" : "number",
        "quantity" : "integer"
    });

// create a relation between the two objects
Family.hasMany(Product, {
    as : 'products',
    foreign : 'family'
});

// bind the objects to the store
store.bind(Family, Product);

// create an Product object and save it to the store
store.connect(function() {
  Product.create({
    name: 'myProduct',
    price: 1.00,
    quantity: 2,
  }, function(err, product) {
    console.log(JSON.stringify(product));
    store.disconnect(function() {
      // done
    });
  });
});

Bislang wurde die JDBC-Kommunikation mit der Oracle Database, MySQL und Derby Datenbank positiv getestet. Auf der NoSQL-Seite wird die Oracle NoSQL-Datenbank bereits unterstützt. Ein MongoDB-Treiber soll folgen.

Als kleines Zusatzgeschenk erhält man mit dem Model-Store-API eine asynchrone Verarbeitung von JDBC-Calls. Da JDBC von Natur aus blockierend arbeitet, kapselt Avatar die Aufrufe und gibt die Ergebnisse als Promise zurück.

Weitere Neuigkeiten

Das Client-Framework, das ein komfortables Binding mithilfe der auch in JSF genutzten Expression Language zur Verfügung stellte und Widgets auf Basis von jQuery UI renderte, ist komplett entfallen. Von Anfang an war das Framework keine ausgereifte Lösung. Bereits vor einem Jahr sagte Oracle, dass man auf der UI-Seite auf das Framework seiner Wahl (z. B. Angular, Knockout, Backbone, ember, etc…) zurückgreifen könne, da zwischen Server und Client ja „nur“ ein protokollbasierte Kommunikation stattfinde und die Client-Komponenten nicht vom Server abhingen. Aus dem „kann“ ist nun ein „muss“ geworden: Die gesamte Client-Bibliothek verschwindet.

Ähnlich sieht es im Bereich JMS aus. Hier gab es bereits eine integrierte Lösung, die, wie bereits im o. a. JDBC-Layer, die synchronen JMS-Calls (der JMS 1.1/Java EE 6 Spezifikation) in einen asynchronen Aufruf verpackte. Da nun jedoch der Application Server als Laufzeitumgebung entfallen ist, ist auch keine JMS-Umgebung mehr vorhanden. Immerhin will man bei Oracle einen Remote-Thin-Client entwickeln, der auf dem eigenen internen t3-Protokoll basiert, um darüber JMS-Ressourcen auf einem WebLogic App Server ansprechen zu können.

Ebenfalls durch den Wegfall des Application Servers sind die REST-, Push- und Socket-Services dem Rotstift zum Opfer gefallen. Oracle spricht hier davon, dass die Mehrheit der Anwender das Feedback gegeben habe, lieber auf Node.js aufbauende Implementierungen zu verwenden und die Services darin zu definieren. Für REST-Services könnte dies das Express-Package sein, für Socket-Services Node-WS und für Server-Sent-Events ein entsprechendes Package aus der Node-Paketverwaltung NPM.

Wie genau Avatar 2.0 aussehen wird, kann hoffentlich bald beurteilt werden: Der Sourcecode ist noch nicht verfügbar, soll aber „in einigen wenigen Wochen bis Monaten“ auf der Projektseite veröffentlicht werden. Bislang ist dort noch das „alte“ Project Avatar zu sehen. Aus der Community wünscht sich Oracle reichlich Feedback. Hierzu darf und kann gerne die Mailingliste genutzt werden.

Geschrieben von
Niko Köbler
Niko Köbler
Niko Köbler ist freiberuflicher Software-Architekt, Developer & Trainer für Java & JavaScript-(Enterprise-)Lösungen, Integrationen und Webdevelopment. Er ist Co-Lead der JUG Darmstadt, schreibt Artikel für Fachmagazine und ist regelmäßig als Sprecher auf internationalen Fachkonferenzen anzutreffen. Niko twittert @dasniko.
Kommentare
  1. Lars Roewekamp2014-10-08 07:41:03

    Ich war selbst auf der JavaOne und habe versucht - jenseits der offiziellen Präsentation - Informationen zu dem Projekt Avatar zu bekommen. Leider war man vor Ort extrem verschlossen, was mich mutmaßen lässt, dass wie in der vergangenen 3 Jahren, das Marketing einmal wieder deutlich weiter ist als die Entwicklung.

    Erschreckend ist für mich, dass die Projekt-Webseite nach wir vor den Stand von vor 12 Monaten (zufällig genau den der JavaOne 2013) aufweist und dies obwohl dieser laut Artikel obsolet ist. Das erinnert leider sehr an die ersten Iterationen von javaFX.

    1. Niko Köbler2014-10-20 14:34:59

      Ich kann nur von dem berichten, was man mir direkt und auch offiziell während der Session gesagt hat. Beides deckt sich erfreulicherweise. Auch hatte ich keine Mühen mit dem Produktmanagement und den Entwicklern am Avatar-Stand in der Ausstellung in Details zu gehen. Man ist mir sehr offen entgegengetreten.
      Dass die Website noch auf die Version 1.0 hinweist, ist ärgerlich, wurde aber auch auf der JavaOne kommuniziert. Und wenn's an die Anfänge von JavaFX erinnert, ok, aber dafür ist auch JavaFX mittlerweile mehr als nur gut geworden! ;-)

Schreibe einen Kommentar

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