Die Brücke in die Zukunft der Softwareentwicklung

Eclipse Flux: Zwischen Desktop und Cloud

Martin Lippert
© Shutterstock/hxdyl

Eine ausgereifte und mit reichlich Funktionen gefüllte Desktop-IDE ist aus dem Entwicklungsalltag nicht wegzudenken. Das war nicht immer so – und könnte sich in ein paar Jahren auch wieder ändern. Cloud-basierte Entwicklungswerkzeuge stecken zwar noch in den Kinderschuhen, könnten aber in einigen Jahren herkömmliche Desktop-IDEs für viele Aufgaben ablösen. Um diesen Schritt so einfach wie möglich zu gestalten, wird im neuen Projekt Eclipse Flux Technologie entwickelt, die bestehende Desktop-IDEs und Cloud-basierte Entwicklungswerkzeuge verbindet und zeigt, wie zukünftige Cloud-IDEs implementiert werden können.

Wer könnte sich heute noch vorstellen, ohne eine umfangreiche IDE schnell und effizient Software zu entwickeln? Ich nicht. Die umfangreiche Unterstützung beispielsweise für die Entwicklung mit Java ist einfach viel zu nützlich, um auf sie verzichten zu können oder zu wollen. Allein Content Assist, Auto Completion und automatisierte Refactorings sind aus dem Alltag eines Entwicklers nicht mehr hinwegzudenken – ganz zu schweigen von der direkten Integration von Unit Testing in die Entwicklungsumgebung, um nur einige wenige Features zu nennen, die eine gute IDE unentbehrlich machen. Und was sollte sich daran schon ändern?
Beobachtet man, wie sich die Entwicklung von Anwendungen in den vergangenen Jahren verändert hat, stellt man schnell fest, dass viele etablierte Technologien in Frage gestellt und durch neuartige Technologien und Projekte ersetzt wurden. Viele Anwendungen laufen nicht mehr „einfach nur“ auf einem Anwendungsserver, sondern werden in Cloud-Umgebungen betrieben, um mit größeren Datenmengen umgehen zu können, mehr Komfort zu bieten, und/oder ausfallsicherer zu sein. Firmen wie Google, Facebook, Twitter, Netflix und viele andere zeigen eindrucksvoll, wie moderne Anwendungen in Cloud-basierten Umgebungen implementiert und betrieben werden können und was diese Anwendungen dann in der Lage sind zu leisten. Im Vergleich dazu kommen die existierenden Desktop-IDEs wie Dinosaurier aus einer vergangenen Zeit daher. Man kann sich die Frage stellen, wieso Google das gesamte Internet in 100 ms durchsuchen kann, meine IDE aber mehrere Sekunden braucht, um eine Typhierarchie zu öffnen oder herauszufinden, wie die Call-Hierarchie einer bestimmten Methode genau aussieht. Zugegeben, der Vergleich ist nicht ganz fair. Aber er regt zum Nachdenken an – mich zumindest.

Cloud-IDEs

Betrachtet man die Werkzeuge, die man als Entwickler heutzutage schon zusätzlich zur integrierten IDE verwendet, fällt auf, dass viele dieser Werkzeuge bereits Web- und/oder Cloud-basiert sind: der Bug-Tracker, der CI-Build, das Git Hosting, Stackoverflow als Support-Site und nicht zu vergessen: die Google-Suche selbst. Die Arbeit am eigentlichen Sourcecode, dem Herzstück bei der Entwicklung, findet aber nach wie vor in der IDE statt. Warum eigentlich? Könnte das nicht auch in der Cloud stattfinden, quasi als integrierte Cloud-IDE? In der Tat existieren bereits eine Reihe von Projekten und Firmen, die sich dem Thema der Cloud-IDEs verschrieben haben. Produkte und Projekte wie Cloud9 IDE, Koding, Codebox, Codenvy u. Ä. werden entwickelt und stehen als Cloud-basierte Entwicklungsumgebungen per Browser-UI zur Verfügung. Den meisten dieser IDEs ist gemeinsam, dass sie versuchen, die bisherige Desktop-IDE mehr oder weniger exakt in einer Cloud- und Browser-basierten Umgebung nachzubauen. Im Bereich Eclipse gibt es das Eclipse-Orion-Projekt, eine Integrationsplattform für browserbasierte Entwicklungswerkzeuge. Im Gegensatz zu anderen Cloud-IDEs versucht Orion nicht zwangsläufig, die existierenden Desktop-IDEs nachzuahmen, sondern orientiert sich stärker an etablierten Webparadigmen. Allen Ansätzen sind aber zwei Dinge gemeinsam: Einerseits stellen sie den Entwickler vor eine Entweder-oder-Entscheidung. Man kann entweder in seiner Desktop-IDE weiterarbeiten oder in die neue Cloud-IDE-Welt wechseln. Es ist schwierig, beide IDEs gemeinsam zu verwenden. Das liegt vor allem natürlich daran, dass Cloud-basierte IDEs davon ausgehen, dass sich die gesamte Entwicklungsumgebung (inklusive der Projekte, Quelltexte und zusätzlicher Werkzeuge) in der Cloud befindet. Der eigene Rechner wird zu einer Art „browserbasiertem Terminal“ degradiert. Werkzeuge, die ich auf meinem eigenen Rechner lokal verwende, müssen in der Cloud-Umgebung ebenfalls eingerichtet werden. Ist dies nicht möglich, muss man auf diese Werkzeuge verzichten.
Andererseits fokussieren die existierenden Cloud-IDEs weitgehend auf die Unterstützung von Webtechnologien und -sprachen. Kompilierte Sprachen wie Java werden fast gar nicht unterstützt, und wenn, dann auf einer Ebene, die im Vergleich zu heutigen Desktop-IDEs wie die pure Steinzeit aussieht.

Die Lösung: Eclipse Flux

Das neue Projekt Eclipse Flux verfolgt das Ziel, diese Lücken zu schließen. Es stellt eine Architektur und Technologie bereit, mit der sich Tooling für Sprachen wie Java für Cloud-basierte Entwicklungsumgebungen implementieren lässt, das dem heutiger Desktop-IDEs in nichts nachsteht. Gleichzeitig verbindet es existierende Desktop-IDEs mit zukünftigem Cloud-Tooling in einer Art und Weise, die die Grenze zwischen diesen beiden Welten aufhebt. Eine schrittweise Migration von Desktop-IDEs zu Cloud-IDEs wird dadurch ebenso möglich wie die wahlweise und gleichzeitige Verwendung beider Varianten. Fehlt also einer der beiden Seiten eine wichtige Funktion, kann die andere dafür verwendet werden. Der Entwickler wird nicht mehr gezwungen, sich mit einem Schlag komplett in die Cloud-Umgebung zu begeben, sondern kann dies schrittweise tun, wann immer es passt und Sinn ergibt.

Welten verbinden

Eclipse Flux basiert auf der Idee, dass Entwickler die existierenden Desktop-IDEs und lokal installierte Werkzeuge zunächst einmal in der gleichen Art und Weise weiterverwenden können wie bisher. Projekte, Workspaces, Dateien – alle Ressourcen eines Projekts verbleiben auf dem eigenen Rechner und können normal bearbeitet und verwendet werden. Man wird nicht gezwungen, eine Art Cloud-Workspace einzurichten und/oder in einem ausschließlich in der Cloud verfügbaren Bereich zu arbeiten. Aktiviert man jedoch Eclipse Flux für ein lokales Projekt innerhalb der IDE, beginnt im Hintergrund eine Art Cloud-Synchronisation. Das Projekt verbleibt im Workspace der IDE und auf dem lokalen Rechner, wird aber zusätzlich ständig mit der Cloud synchronisiert (Abb. 1). Das funktioniert ähnlich wie Dropbox oder Google Drive, allerdings auf zwei bis drei unterschiedlichen Ebenen. Während die gängigen Dateisynchronisationswerkzeuge lediglich Veränderungen an Dateien synchronisieren, erlaubt es Eclipse Flux zusätzlich, Live-Editing zu synchronisieren. Das bedeutet, dass bereits das Editieren einer Datei in Echtzeit mit der Cloud synchronisiert wird. Dabei unterscheidet Flux zwischen dem Live-Editing und dem Speichern einer Datei und synchronisiert beides getrennt voneinander.

Abb. 1: Der Navigator in Eclipse zeigt, dass ein Projekt mit Flux verbunden ist – mehr verändert sich in der Eclipse-IDE nicht

Diese Synchronisation von Ressourcen und Projekten bildet das Rückgrat von Eclipse Flux und erlaubt völlig neue Möglichkeiten. Durch sie können nun auch andere Werkzeuge, die ausschließlich in der Cloud vorhanden sind, auf diese zugreifen und mit ihnen arbeiten. Der naheliegende Schritt ist natürlich, den Code mit einem browserbasierten Editor bearbeiten zu können (Abb. 2). Damit wird es möglich, die eigenen Projekte und Ressourcen von überall aus zu verändern, ohne eine lokale IDE einrichten zu müssen. Ein moderner Browser reicht aus. Da auch der Browsereditor auf Basis des zugrunde liegenden Synchronisationsmechanismus implementiert ist, spiegeln sich Änderungen sofort in der eigenen Desktop-IDE wider – ob sie parallel geöffnet ist oder zu einem späteren Zeitpunkt gestartet wird. Der Zustand der Projekte und Ressourcen wird über den Flux-Mechanismus synchron gehalten.

Abb. 2: Auf die verbundenen Projekte lässt sich jetzt auch mit dem Browser zugreifen

Dadurch wird es möglich, sowohl die Desktop-IDE als auch neu hinzukommende Cloud- und browserbasierte Werkzeuge parallel zu benutzen und je nach Situation das passende Werkzeug zu wählen. Und wer weiß? Je besser und je mächtiger die Cloud- und browserbasierten Werkzeuge werden, desto seltener verwendet man vielleicht die Desktop-IDE in der Zukunft. Aber selbst wenn man im Laufe der Zeit immer mehr zu den Cloud- und browserbasierten Werkzeugen greift, kann man jederzeit die alten Desktop-IDEs zur Hand nehmen. So wird eine schrittweise und völlig nahtlose Migration von Desktop-IDEs zu Cloud-basiertem Developer-Tooling möglich, und die strikte Trennung beider Welten wird komplett aufgehoben.

Aufmacherbild: the night of modern bridge von Shutterstock / Urheberrecht: hxdyl

[ header = Seite 2: Echtes Sprach-Tooling ]

Echtes Sprach-Tooling

Dateien im Browser editieren zu können, ist mit Sicherheit noch kein ausreichender Grund, auch nur annähernd in Erwägung zu ziehen, dass browserbasierte Codeeditoren eine ausgereifte Desktop-IDE ablösen könnten. Dazu ist mehr nötig, vor allem ein hervorragendes Sprach-Tooling, zu dem ich die vielen liebgewonnen Features zähle, die die Arbeit in heutigen Desktop-IDEs so angenehm machen: Errors und Warnings schon während des Editierens, Content Assist, Auto Completion, Navigation, Refactoring, Unit-Test-Integration, Source Level Debugging und viele, viele mehr. Aber wie soll ein browserbasierter Codeeditor diese Features implementieren, möglichst noch für diverse Sprachen gleichzeitig? Muss alles neu in JavaScript implementiert werden, damit es anschließend komplett im Browser ablaufen kann – und der browserbasierte Codeeditor so zu einem echten Monstrum wird? Eclipse Flux geht einen anderen Weg, um Cloud-basierte Entwicklungswerkzeuge zu realisieren. Im ersten Schritt nimmt der browserbasierte Codeeditor an dem zugrunde liegenden Synchronisationsmechanismus teil, wobei sowohl das Speichern einer Datei synchronisiert wird als auch das Live-Editing in Echtzeit. Und statt alle möglichen Sprachunterstützungen selbst zu implementieren, überlässt es Eclipse Flux Cloud-basierten Mirco-Services, diese Features zu implementieren. Was bedeutet das? Bisher haben an dem Synchronisationsmechanismus die Desktop-IDE und der browserbasierte Editor teilgenommen. Die Micro-Services, die „irgendwo“ in der Cloud laufen, schließen sich diesem Mechanismus ebenfalls an und synchronisieren Ressourcen und Projekte in einem für sie geeigneten und für sie lokalen Bereich. Durch die Synchronisation des Live-Editing sehen diese Micro-Services exakt den gleichen Stand, den auch der Entwickler in einem browserbasierten Editor oder seiner Desktop-IDE sieht. Auf dieser Basis können die einzelnen Micro-Services nun aktiv werden und implementieren, was immer sie als Dienst anbieten möchten. Nehmen wir das Sprach-Tooling für Java als Beispiel. Dazu implementieren wir einen Java-Reconciling-Micro-Service. Er nimmt am Synchronisationsmechanismus teil und führt immer dann ein Reconciling durch, wenn sich die Dabei beim Live-Editing verändert. Das Ergebnis dieser Arbeit, die Errors und Warnings, die man während des Tippens in den Desktop-IDEs so liebgewonnen hat, werden im Anschluss wieder an den browserbasierten Codeeditor zurückgespielt, der sie einfach nur anzeigt – ohne selbst irgend etwas dafür getan zu haben (Abb. 3).

Abb. 3: Errors und Warnings erscheinen im browserbasierten Editor in Echtzeit

Ähnlich können weitere Features implementiert werden, beispielsweise Content Assist. Der browserbasierte Editor versendet eine Nachricht (mehr dazu siehe unten), ein Micro-Service in der Cloud versteht diese „ich brauche Content Assist“-Nachricht, kann aufgrund der synchronisierten Projekte und Ressourcen den Content Assist berechnen und an den Codeeditor zurücksenden. Auf die gleiche Art und Weise kann man sich diverse weitere Micro-Services vorstellen, die auch Navigation oder Refactorings implementieren (Abb. 4).

Abb. 4: Echter Java-Content-Assist im Browsereditor

So wird es möglich, auf Basis dieser in der Cloud laufenden Micro-Services echtes Language-Tooling zu implementieren, ohne dass man den browserbasierten Codeeditor zu einem allumfassenden Monstrum werden lässt.

Services entscheiden selbst

Ein wichtiger Vorteil der Cloud-basierten Micro-Services ist es, dass sie selbst (relativ autonom) entscheiden können, wofür sie zuständig sein möchten. Es muss nicht den einen Service für Reconciling geben, der alle möglichen Sprachen kennt und verarbeiten kann. Während der eine Reconciling-Service auf Veränderungen einer Java-Datei reagieren kann, könnte ein anderer Errors und Warnings produzieren, wenn beispielsweise eine Scala-Datei bearbeitet wird.
Dieses Grundkonzept gilt für alle Cloud-basierten Micro-Services. Jeder einzelne Service kann selbst entscheiden, für welche Datei oder welches Projekt er seine Dienste anbietet. Dadurch entsteht schon in der grundlegenden Struktur des Systems eine gewisse Ausfallsicherheit, da mehrere Instanzen des gleichen Service parallel arbeiten können. Sollte also der Java-Reconciling-Service verschwinden, könnte eine andere, parallel laufende Instanz sofort übernehmen, ohne dass der Entwickler etwas davon mitbekommt. Und vor allem: ohne dass komplizierte Failover-Mechanismen implementiert werden müssen. Gleichzeitig arbeiten die unterschiedlichen Services „by Design“ parallel zueinander. Da jeder Service für sich selbst entscheidet, wann er aktiv wird und bei welchen Ereignissen (Code wird editiert, Datei wird gespeichert etc.), arbeiten alle Services unabhängig und parallel zueinander. Es muss deshalb keine zusätzliche Parallelisierung in den Services realisiert werden, um die Geschwindigkeit des Gesamtsystems zu verbessern. Und obwohl mit diesem Überblick über die grundlegende Architektur des Systems sicherlich noch nicht alle Fragen beantwortet sind, wird deutlich, dass sie völlig neue Möglichkeiten eröffnet. Einen ersten Einblick bekommt man, wenn man sieht, dass schon ein erster Prototyp existiert, der Unterstützung für Xtext in Eclipse Flux implementiert. Als völlig separater Micro-Service in der Cloud kann dort Xtext als Sprache mit Reconciling, Navigation, Content Assist u. Ä. unterstützt werden. Eine weitere wichtige Eigenschaft der Micro-Services ist, dass ihnen keinerlei Beschränkungen auferlegt sind, wie sie implementiert werden müssen. Anders als bei der Plug-in-Entwicklung für Eclipse gibt es eine umfassende Plattform, auf deren Basis die Micro-Services implementiert werden müssen. Jeder Service kann für sich selbst entscheiden, in welcher Sprache und unter Benutzung welcher Bibliotheken und Frameworks er realisiert werden möchte. So kann beispielsweise ein Reconciling-Service für Java das Eclipse-Plattform-Modell verwenden und mittels JDT den Service implementieren. Er könnte aber auch auf Basis des javac-Compilers realisiert werden, falls beispielsweise eine neue Java-Version unterstützt werden soll. Durch die extrem lose Kopplung der Services könnten sogar beide Services parallel laufen und jeweils selbst entscheiden, wer aktiv werden möchte. So könnte der JDT-basierte Java-Micro-Service immer dann aktiv werden, wenn ein entsprechendes Projekt mit Java-Code bis zum Java-8-Level bearbeitet wird. Verwendet das Projekt allerdings schon Java 9, könnte der JDT-basierte Service einfach nichts tun, und der javac-basierte Java-Micro-Service würde die Aufgaben übernehmen.

Der Phantasie keine Grenzen gesetzt

Bisher haben wir die Micro-Services vor allem im Bereich Language-Tooling betrachtet und erläutert, wie sich wichtige Features für den Codeeditor damit implementieren lassen. Dabei sind die Micro-Services keinesfalls auf solche Aufgaben beschränkt. Durch die extrem lose Kopplung über den Synchronisationsmechanismus können diverse Ideen für weitere Micro-Services entstehen. Einige Beispiele zum Gedankenanregen:

  • Unit-Test-Service: Bei jeder Veränderung werden im Hintergrund (in der Cloud) Unit Tests ausgeführt und über ein spezielles UI das Ergebnis zurückgeliefert.
  • Ein Continuous-Build-Service: Veränderungen triggern ein Continuous-Build-System, ggf. inkl. automatisiertem Deployment beim Speichern einer Datei, während der Status des Builds ständig visualisiert wird.
  • Ein Git-Backup-Service: Veränderungen an einer Datei werden automatisiert in ein Git Repository zurückgespielt (beispielsweise in einen separaten Live-Edit-Branch oder Ähnliches).
  • Ein GitHub-Service: Die eigenen Projekte auf GitHub sind automatisiert in einer Eclipse-Flux-Umgebung vorhanden und können ohne zusätzlichen Aufwand editiert und navigiert werden. Dies könnte realisiert werden, indem der GitHub-Service am Synchronisationsmechanismus teilnimmt und dabei nicht die Rolle eines Konsumenten einnimmt, sondern die eines Repositorys, in dem Projekte gespeichert werden (ähnlich der Komponente, die in der Desktop-IDE lokal vorhandene Projekte mit Eclipse Flux verbindet).
  • und viele, viele mehr …

Je mehr man über diese völlig unterschiedlichen Micro-Services nachdenkt, desto mehr Ideen für weitere Services entstehen. Eclipse Flux befindet sich hier definitiv noch in einer sehr frühen und experimentellen Phase.

Im Team arbeiten – aber kein Ersatz für Git

Da der Synchronisationsmechanismus in der Lage ist, in Echtzeit das Editieren von Dateien zu synchronisieren (ähnlich wie Google Drive), liegt es nahe, in diesem Zusammenhang über Kollaboration nachzudenken. Und in der Tat wäre es auf dieser technischen Basis nicht besonders schwierig, Collaborative-Editing von Quellcode zu implementieren – und es ist auch durchaus geplant, dieses Feature in einer zukünftigen Version von Flux umzusetzen.
Allerdings sei hier ausdrücklich erwähnt, dass der Synchronisationsmechanismus von Eclipse Flux nicht als Ersatz für eine Versionskontrolle gedacht ist und auch nicht dazu genutzt werden sollte, um mit einem Team gemeinschaftlich und in Echtzeit an einem Projekt zu arbeiten. Der Synchronisationsmechanismus von Eclipse Flux ist explizit nur für einen einzelnen Benutzer gedacht und bezieht sich immer auf einen einzelnen Benutzer. Natürlich können Tausende von Benutzern das System gleichzeitig verwenden, aber die Projekte und Ressourcen werden pro Benutzer strikt voneinander getrennt. Also selbst wenn mehrere Teammitglieder Eclipse Flux verwenden und die gleichen Projekte mit Flux verbinden, handelt es sich aus Sicht von Flux immer um komplett getrennte Projekte und Ressourcen. Deshalb ist Flux auch nicht als Ersatz für eine Versionsverwaltung gedacht, ganz im Gegenteil. Der Synchronisationsmechanismus kann völlig losgelöst von und zusätzlich zu einer Versionsverwaltung wie Git verwendet werden. Allerdings ist geplant, den Synchronisationsmechanismus soweit mit Git zu verknüpfen, dass beispielsweise Commits und Branch-Wechsel ebenfalls synchronisiert werden, sodass auch der Zustand des Git Repositorys synchron bleibt – jedenfalls, soweit dies nötig ist.

[ header = Seite 3: Hinter den Kulissen ]

Hinter den Kulissen

In den vorangegangenen Abschnitten haben wir die grundsätzliche Struktur und Architektur von Eclipse Flux betrachtet. Gehen wir einen Schritt weiter und betrachten die technische Basis, auf der Eclipse Flux (zumindest der aktuelle Prototyp) implementiert ist. Die grundlegende technische Struktur des Systems besteht aus einem Messaging-System, mit dem alle beteiligten Komponenten asynchron Nachrichten austauschen können. Das ist der einzige Kommunikationsweg in Eclipse Flux. Es gibt kein RESTful-API, keine direkten Serviceaufrufe, keine APIs in Codeform und keine Plattformimplementierung, auf deren Basis Erweiterungen umgesetzt werden müssten. Stattdessen wird ausschließlich über asynchrone Nachrichten kommuniziert, die in Form von JSON-Nachrichten versendet und empfangen werden (wobei das JSON-Format hier nicht entscheidend ist). Das bedeutet, dass jede Komponente (gemeint sind hier die technischen Komponenten wie der Browsereditor und die Desktop-IDE, aber auch die Cloud-basierten Micro-Services) sich mit diesem Messaging-System verbindet (inkl. Benutzerauthentifizierung) und von diesem Zeitpunkt an Nachrichten mit den anderen Komponenten austauschen kann. Dabei werden Nachrichten entweder an alle Komponenten verteilt (Broadcast) oder an eine Komponente direkt versendet.

Abb. 5: Die grundlegende Architektur von Eclipse Flux – im Überblick

Auf dieser Basis ist beispielsweise die Synchronisation der Projekte und Ressourcen realisiert. Das Flux-Plug-in für die Eclipse-IDE sendet und empfängt solche Synchronisationsnachrichten, sobald der Benutzer ein Projekt seines Workspace mit Flux verbunden hat. Wird beispielsweise ein Projekt neu mit Flux verbunden, sendet das Eclipse-Plug-in eine projectConnected-Nachricht als Broadcast. Andere Komponenten, beispielsweise ein auf Basis von MongoDB implementierter Backup-Service, kann diese Nachricht auswerten und mittels einer weiteren Nachricht nachfragen, welche Ressourcen sich in diesem neuen Projekt befinden. Auf eine solche Nachricht würde das Eclipse-Plug-in wiederum mit einer Nachricht antworten, die über den Inhalt des Projekts Auskunft gibt. Diese Art der Nachrichten wird auf allen Ebenen eingesetzt. Startet beispielsweise der browserbasierte Codeeditor, versendet er eine Nachricht mit der Bitte, ihm den Inhalt einer bestimmten Ressource zuzusenden. Eine andere Komponente, die die entsprechende Ressource in der korrekten Version zur Verfügung hat, kann diese an den Codeeditor zurücksenden. Dabei macht es keinen Unterschied, ob dies durch ein in der Cloud laufendes Backup-Repository passiert oder eine laufende Eclipse-Desktop-IDE zufällig verbunden ist und die Ressource ebenfalls besitzt und zurücksenden kann. Durch diese Form der asynchronen Kommunikation entsteht eine Reihe von interessanten Effekten. Beispielsweise spielt es für das System keine Rolle mehr, wie viele Instanzen eines Cloud-Backup-Repositorys vorhanden sind. Jede einzelne Instanz nimmt an dem Synchronisationsmechanismus teil, reagiert auf Dateiänderungen und kann den Inhalt von Ressourcen bei Bedarf versenden. Fällt aufgrund von technischen Schwierigkeiten eine Instanz aus, müssen keine Nachrichten an eine andere Instanz umgeleitet werden oder Ähnliches. Eine andere Instanz würde automatisch die Aufgaben übernehmen.

Beispiel: Reconciling

Das Synchronisieren von Projekten und Ressourcen bildet zwar das Rückgrat der Flux-Architektur, ist aber bei Weitem nicht die einzige Kommunikation, die über den asynchronen Nachrichtenkanal stattfindet. Der Reconciling-Service nutzt die Nachrichten zur Synchronisation, um die lokalen Kopien der Projekte und Ressourcen auf dem neuesten Stand zu halten. Die Reconciling-Ergebnisse (die Errors und Warnings) werden ihrerseits auch über den Nachrichtenkanal an alle Interessierten gesendet. So kann der Editor diese Errors und Warnings anzeigen, ohne selbst genau zu wissen, wer diese produziert hat. Neue Sprachen oder Sprachvarianten können unterstützt werden, in dem entsprechende neue Services in der Cloud bereitgestellt werden. Der eigentliche Browser-basierte Code-Editor muss nicht angepasst werden.
Es gibt natürlich Grenzen für diesen Ansatz. Aktuell wird beispielsweise das Syntax-Highlighting vom browserbasierten Editor übernommen – und zumindest dieser Teil müsste natürlich für eine gänzlich neue Sprache angepasst werden. Trotzdem wird es spannend zu erkunden, wie weit der Eclipse-Flux-Ansatz getrieben werden kann.

Abb. 6: Der Phantasie sind keine Grenzen gesetzt – zusätzliche Services verbinden sich über das Messaging-System mit Flux

Ausblick

Eclipse Flux befindet sich noch in einer sehr frühen Phase. Auch der existierende Code geht noch nicht über eine prototypische Implementierung der Konzepte hinaus. Da wird noch viel Arbeit auf das Team zukommen, und es wird noch eine ganze Weile dauern, bis die ersten Varianten von Eclipse Flux im Produktiveinsatz genutzt werden können. Und es gibt sicherlich noch mehr offene als beantwortete Fragen. Dennoch ist bereits jetzt erkennbar, dass Eclipse Flux einen sehr interessanten und neuartigen Weg geht, um sowohl die Desktop-IDEs mit zukünftigen Cloud-IDEs zu verbinden als auch umfangreiches Sprach-Tooling selbst für kompilierte Sprachen in der Cloud zu implementieren. Wer Flux in Aktion sehen möchte, kann sich den Demo-Screencast auf YouTube ansehen – dort heißt das Projekt übrigens noch „Flight“.

Geschrieben von
Martin Lippert
Martin Lippert
Martin Lippert ist Lead der Spring-Tool-Suite-Entwicklung und arbeitet bei Pivotal (im SpringSource-Team) mit einem internationalen Team an Entwicklungswerkzeugen rund um Spring- und Cloud-Techniken. Als Mitgründer der it-agile GmbH gilt er zudem als Spezialist für agile Softwareentwicklung.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: