Suche
Ein Open Source verfügbarer Ansatz

Open Dolphin: Enterprise JavaFX

Dierk König

Wie soll man vorgehen, wenn man eine echte Enterprise-Applikation mit JavaFX bauen oder gar eine bestehende auf JavaFX migrieren möchte? Hier bietet Open Dolphin [1] einen architektonischen Ansatz, der den Wechsel zwischen UI-Toolkits erleichtert und einen Investitionsschutz für die Fachlogik garantiert.

Open Dolphin wurde in der JavaOne Strategy Keynote als Integrationsbeispiel von JavaFX und Java Enterprise vorgestellt. Als Demo diente eine Applikation (Abb. 1), mit der man die Container in einem Containerhafen überwachen und steuern kann. Ein Video dieser Demo findet sich unter [2].

Abb. 1: JavaFX-Demo – Containerhafen

Diese Demo ist auf zwei Arten typisch für JavaFX-Enterprise-Applikationen:

  • Erstens möchte man von den reichhaltigen Visualisierungmöglichkeiten von JavaFX profitieren.
  • Zweitens hat der Anbieter dieser Software seit vielen Jahren ein serverseitiges Programmiermodell in Betrieb und das möchte er erhalten.

Sei freundlich!

Natürlich braucht nicht jede Geschäftsanwendung eine ausgefeilte 3-D-Erlebniswelt für ihre Daten – auch wenn das häufig sinnvoller ist, als man vermuten würde. Zumindest jedoch erwarten die Anwender heute ein Benutzungserlebnis wie sie es von Smartphones und Tablets her kennen, mit sinnvoller Eingabeunterstützung, direkter Manipulation, weichen Übergängen und sofortiger Anzeige der Auswirkungen auf das Ergebnis. Professionelle Desktopanwendungen müssen genauso anwenderfreundlich sein!

Abbildung 2 demonstriert eine auf den ersten Blick konventionelle Anwendung für die Zusammenstellung von finanziellen Portfolios. Sie ist im Lieferumfang von Open Dolphin enthalten. Schon beim Anschauen des Videos [3] fallen aber die Besonderheiten auf:

  • sofortige, konsistente Aktualisierung aller Anzeigen und Ergebnisse
  • weiches Ein- und Ausblenden
  • animierte Übergänge und Materialisierung
  • trotz Serveranbindung keine Wartezeiten

Abb. 2: Portfoliodemo

Diese Effekte werden durch eine Kombination von Open Dolphin und JavaFX bewirkt. Open Dolphin stellt das Presentation Model bereit und bestimmt damit, was angezeigt werden soll. JavaFX bindet sich an das Presentation Model und übernimmt das Wie der Darstellung, also die Visualisierung des Zustands und der Übergänge.

Die Konsistenz der Darstellung und die sofortige Aktualisierung ist eine Eigenschaft von Open Dolphin. Die Views kennen einander nicht mehr. Es gibt auch keinen „Presenter“ mehr, der alle Views kennen muss. Die Views binden sich an ihr Presentation Model. Das wars.

Migration durch Ignoranz

Nun ist es aber Open Dolphin vollständig egal, ob sich ein JavaFX oder Swing oder SWT oder Eclipse RCP oder NetBeans oder sonst eine Java-basierte View auf die Presentation Models als Listener registriert. Sie werden alle gleichermaßen freundlich bedient.

Das ist der Trick für die Austauschbarkeit des UI-Toolkits: zuerst die Visualisierung abkapseln und dann ersetzen. Auf diese Art ermöglicht es Open Dolphin, sich heute schon auf eine zukünftige Migration zu JavaFX vorzubereiten, oder sofort mit JavaFX anzufangen, aber sich für eventuelle Änderungen abzusichern. Die Open-Dolphin-Performancedemo (Abb. 3) zeigt, wie die gleiche Logik mit Swing und mit JavaFX dargestellt werden kann. Auch hierzu gibt es ein passendes Video [4].

Abb. 3: Performancedemo

Bereit sein und parallel arbeiten

Die „eventuellen Änderungen“ kommen meist schneller als man denkt. Es sind nicht nur technologische Neuerungen, neue Toolkits oder deren Versionen. Manchmal gibt es einfach neue Optionen. Die Containerapplikation zum Beispiel haben wir zuerst vollständig in 2-D gebaut. Dann gab es plötzlich die Möglichkeit für 3-D und wir brauchten lediglich die Visualisierung erweitern. Die Modi sind sogar zur Laufzeit umschaltbar.

Nun unterscheiden sich die UI-Toolkits nicht nur in ihren Widgets, sondern auch im Threading Model. Auch dafür schafft Open Dolphin einen wichtigen Mehrwert. Alle visuellen Komponenten werden garantiert immer im UI Thread gehandhabt. Alle Controller Actions werden immer asynchron ausgeführt. Das ist möglich, weil sie ausschließlich auf Presentation Models operieren. Man kann die Nebenläufigkeit so gut wie nicht mehr falsch machen. Der UI Thread wird nie blockiert, genauso wenig wie die Steuerungslogik.

Logische und physische Verteilung

Soweit betrafen die Strukturen und Verfahren von Open Dolphin nur den Client. Enterprise-Applikationen laufen aber typischerweise auf dem Server. Deshalb bietet Open Dolphin die Möglichkeit, sämtliche Logik auf dem Server zu installieren. Die Presentation Models werden dann automatisch zwischen Client und Server synchronisiert. Abbildung 4 zeigt eine Skizze dieser Architektur.

Abb. 4: Open-Dolphin-Architektur

Open Dolphin hat eine logische MVC-Trennung, wobei das M im Sinne von Presentation Model zu verstehen ist. View und Controller sind immer logisch und durch Threads getrennt. Typischerweise – aber nicht zwingend – werden sie auch physisch verteilt. Dann liegen die Views auf dem Client und die Controller und ihre Actions auf dem Server. Die Fachlogik liegt also dort, wo sie zentral verwaltet und gepflegt werden kann und die beste Verbindung zu den Unternehmensdatenquellen hat. Der zentrale Server ist auch der natürliche Ort, über den sich die Clients falls notwendig gegenseitig synchronisieren können. Die TrainControlDemo [5] und die ManyEventsDemo [6] machen davon ausgiebig Gebrauch.

Die Demos beeindrucken auch durch die Schnelligkeit der Datenübertragung. Das liegt an dem schlauen Einsatz der Nebenläufigkeit und den kleinen Übertragungspaketen. Zwischen Client und Server werden ausschließlich Commands gesandt – in kleinen Paketen und meist ohne dass der Benutzer es überhaupt bemerkt. Der Transportmechanismus zwischen Client und Server ist austauschbar.

Doing is believing

Open Dolphin selbst kommt mit vielen Demos, an denen man die verschiedenen Eigenschaften und Funktionen ausprobieren kann. Den besten Einstieg in Open Dolphin findet man aber mit einem einfachen Beispiel. Zu diesem Zweck gibt es auf GitHub [7] das Projekt DolphinJumpStart. Es kommt mit einem Maven Build und JavaFX Views, die in Java geschrieben sind (sonst machen wir uns gerne das Leben einfacher und nehmen GroovyFX).

Nehmen wir an, unsere View hätte folgendes Textfeld:

TextField field = new TextField()

Nun möchten wir den Inhalt dieses Textfelds an ein Open Dolphin Presentation Model binden. Dafür brauchen wir ersteinmal ein Model. Es soll unter der ID „input“ auffindbar sein und ein Attribut mit dem Namen „text“ haben:

PresentationModel input = 
  clientDolphin.presentationModel("input", new ClientAttribute("text"));

Jetzt können wir die „text“ Property des Textfelds an das Attribut binden:

JFXBinder.bind("text").of(field).to("text").of(input);

Der Inhalt des Textfelds wird nun bei jeder Änderung automatisch mit dem Presentation Model synchronisiert und der Server asynchron benachrichtigt.

Sagen wir, wir wollten den vom Benutzer eingegebenen Text auf dem Server verwenden, z. B. ausdrucken. Dann würden wir eine Action registrieren, wie in Listing 1 dargestellt.

serverDolphin.action("PrintText", new NamedCommandHandler() {
  public void handleCommand(NamedCommand namedCommand, List<Command> commands) {
    Object text = serverDolphin.getAt("input").getAt("text").getValue();
    System.out.println("server text field contains: " + text);
  }
});

Anstoßen kann man die Serveraktion vom Client aus per:

clientDolphin.send("PrintText");

Wie es Euch gefällt

Das war natürlich nur die allereinfachste Anwendung von Open Dolphin, um das Prinzip zu zeigen. Selbst wenn man sich nur das Binding anschaut, verbergen sich dort vielerlei Perlen – wie das Binden an den Dirty State oder an weitere Metainformationen.

Am wichtigstem beim Binding ist aber die Stabilität. Gerade bei Master-Detail-Views (Abb. 5) hat man häufig das Problem, dass man bei Selektionsänderungen die Detail-View neu binden muss, was alle Arten von Schwierigkeiten nach sich ziehen kann. Bei Open Dolphin ist das nicht notwendig. Das Binding bleibt immer stabil. Ein Video zur Push-Demo findet sich unter [8].

Abb. 5: Push-Demo

Mach mit!

Einen guten Überblick über die Eigenschaften von Open Dolphin gibt der Architekturteil der Dokumentation. Die Dokumentation selbst wird mit der 1.0-Version von Open Dolphin fertiggestellt, die für Ende März angekündigt ist. Bis dahin ist auch das API finalisiert.

Zu Open Dolphin gibt es viele Ressourcen im Netz, vor allem Videos über die Demos und die technischen Präsentationen. Open Dolphin ist Open Source mit Apache-2-Lizenz und liegt auf GitHub. Wir freuen uns über Fragen und sonstige Beiträge!

Die ersten größeren Applikationen mit Open Dolphin sind im Bau und zum Teil schon in Betrieb. Zusätzlich gibt es einige interessante Prototypen und Proof-of-Concept-Implementierungen. Die Early Adopters sind eine beständige Quelle neuer Anregungen. Sie haben zum Beispiel herausgefunden, dass sich Open Dolphin perfekt für das funktionale Testen der Applikation eignet. Man legt einfach die erwarteten Presentation Models an, sendet ein Command und überprüft, ob die Applikations- und Präsentationslogik die Presentation Models wie erwartet verändert hat. Um einen der Entwickler zu zitieren: „Das ist UI Testing ohne UI!“

Wer zu JavaFX umsteigen will, seine Investitionen absichern oder sonst Java-Desktop-Applikationen Enterprise-ready machen möchte, der sollte sich Open Dolphin genauer ansehen. Mit JavaFX für iOS und Android ergeben sich für Open Dolphin zukünftig auch noch völlig neue Einsatzgebiete im Mobile Computing.

Geschrieben von
Dierk König
Dierk König
Dierk König ist Fellow bei der Canoo Engineering AG, Basel. Er betreibt die Open-Source-Projekte Canoo WebTest und Dolphin und ist Committer in den Projekten Groovy, Grails und GPars. Er publiziert und spricht auf internationalen Konferenzen zu Themen moderner Softwareentwicklung. Er ist Autor des Buchs „Groovy in Action“.
Kommentare
  1. Marco2014-03-13 11:40:48

    Die Idee eines übergreifenden MVC-Frameworks finde ich gut, ist aber aus meiner Sicht ein alter Hut - nutzen wir in meinem beruflichen Umfeld schon seit 13 Jahren. Nur dass unsere Firma das leider nie zu OpenSource gemacht hat. Ich finde Euren Ansatz, obwohl viel neuer, längst nicht so gut. Die Code-Beispiele sind leider auch eher abschreckend.

    1. Dierk König2014-03-15 14:32:13

      Hallo Marco,
      was findest Du denn an Eurer Lösung besser und wie sollte der code für Dich aussehen?
      OpenSource heisst ja, dass jeder seine Verbessungsvorschläge einbringen kann!

Schreibe einen Kommentar

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