Bringen Sie bestehende Linux-Desktop-Anwendungen ohne Neuschreiben in den Browser. Erfahren Sie, wie Linux Web Launcher Wayland, XWayland und die Sitzungsinfrastruktur von Webswing nutzt, um die vorhandenen Oberflächen bereitzustellen.
Unternehmensweite Anwendungsportfolios beschränken sich selten auf eine einzige Technologie. Neben Java-Desktop-Anwendungen setzen viele Organisationen auf Linux-basierte Editoren, Dateibetrachter, Terminals, Diagnosewerkzeuge und spezialisierte Anwendungen, die im Arbeitsalltag weiterhin wichtig sind.
Die Anwendungen selbst können nach wie vor zuverlässig sein. Die Schwierigkeit liegt häufig in ihrer Bereitstellung: unterschiedliche Zugriffswege, separate Infrastruktur, zusätzliche Lizenzen, fragmentierter Support und Arbeitsabläufe, bei denen Nutzer zwischen voneinander getrennten Umgebungen wechseln müssen.
Der Webswing-Ansatz Linux Desktop to Web soll diese Lücke schließen. Die Anwendung läuft weiterhin in ihrer ursprünglichen Linux-Umgebung auf dem Server, während ihre Benutzeroberfläche über den Browser bereitgestellt wird. Möglich macht das der Linux Web Launcher (LWL). Er basiert auf einem eigens entwickelten Wayland-Compositor und ist in das bestehende Webswing-Frontend, den Server, die Sitzungsverwaltung und die Administrationsinfrastruktur integriert.
Unsere Übersicht zu Linux Apps zeigt typische Anwendungsfälle, Bereitstellungsoptionen und eine Demo im Browser.
Die Anwendung bleibt in ihrer ursprünglichen Linux-Laufzeitumgebung
Linux Desktop to Web erfordert weder ein Neuschreiben der Anwendung noch ein separates Konvertierungsprojekt für jedes GUI-Toolkit. Die Linux-Anwendung läuft auf dem Server in der Umgebung, für die sie entwickelt wurde. Was sich ändert, ist die Bereitstellungsschicht zwischen Anwendung und Nutzer.
Linux Web Launcher stellt die Display-Umgebung bereit, die die Anwendung benötigt. Er erfasst ihre gerenderte Ausgabe und verbindet sie mit der bewährten Webswing-Pipeline für die Bereitstellung im Browser. Nutzereingaben werden an die Anwendung zurückübertragen. So wird der Browser zum Zugangspunkt, während die Software in ihrer ursprünglichen Laufzeitumgebung bleibt.
Dieser Ansatz ist besonders hilfreich, wenn eine Anwendung wertvoll ist, ihr Ersatz aber schwierig, riskant oder schlicht unnötig wäre.
Warum Webswing auf der Ebene des Display-Servers arbeitet
Linux-Desktop-Anwendungen können auf unterschiedlichen UI-Technologien basieren, benötigen jedoch alle einen Display-Server. Dessen Ebene ist daher ein praktischer gemeinsamer Integrationspunkt.
Ein Wayland-Compositor verwaltet Anwendungsverbindungen und grafische Flächen, setzt die endgültige Szene zusammen, leitet Eingabeereignisse weiter und gewährleistet die Isolation zwischen Clients. Linux Web Launcher implementiert dafür einen eigenen Compositor. Er unterstützt native Wayland-Anwendungen sowie X11-Anwendungen über XWayland. Die Architektur ist somit nicht an ein einzelnes Anwendungs-Toolkit gebunden.
Die Integration auf dieser Ebene hat drei wichtige Konsequenzen:
Webswing erfasst die tatsächliche Anwendungsausgabe, statt die Oberfläche Steuerelement für Steuerelement nachzubauen.
Anwendungen können ohne physischen Bildschirm auf dem Server laufen und erhalten trotzdem eine vollständige Display-Umgebung.
Dieselbe Integration lässt sich für unterschiedliche Linux-Desktop-Anwendungen nutzen, statt sie für jedes UI-Framework neu aufzubauen.
Wie die Architektur des Linux Web Launchers zusammenspielt
Die Architektur lässt sich in vier zusammenarbeitende Schichten gliedern.
1. Die Linux-Anwendung
Die Anwendung läuft auf dem Server als Wayland-Client oder, bei einer X11-Anwendung, über XWayland. Sie behält ihre eigene UI-Logik und übergibt Aktualisierungen ihrer grafischen Flächen nach dem üblichen Linux-Desktop-Modell.
2. Der eigene Compositor und die Capture-Middleware
Der eigens entwickelte Wayland-Compositor verwaltet Anwendungsfenster, die Komposition der grafischen Flächen und die Eingaben. Er aktualisiert die Szene und rendert die resultierende Ausgabe in einen Puffer. Darunter bilden Standardkomponenten der Linux-Grafikarchitektur wie Mesa 3D, DRM/KMS und der Linux-Kernel die Grundlage für das Rendering.
Die Capture-Middleware liest die gerenderte Ausgabe aus dem Grafikpuffer. Ein Frame-Emitter reiht anschließend Aktualisierungen in eine Warteschlange ein, entfernt Duplikate, kodiert bei Bedarf die Frames und erstellt die Nachricht, die über Webswing gesendet wird.
3. Der Webswing-Server und die Sitzungsschicht
Ein Verbindungsmanager sendet die Aktualisierung über WebSocket. Der Webswing-Server empfängt und dekodiert die Nachricht. Der Session-Router ermittelt die richtige Nutzersitzung und leitet die Anwendungsdaten an sie weiter.
Diese Schicht nutzt die bereits in Webswing vorhandene Infrastruktur: das Browser-Frontend, die serverseitige Sitzungsverwaltung und die Admin Console für Konfiguration und Monitoring der Anwendungen. Die Bereitstellung von Linux-Anwendungen wird damit Teil desselben Betriebsmodells und erfordert keinen separaten Bereitstellungs-Stack.
4. Die Präsentationsschicht im Browser
Im Browser empfängt die WebSocket-Verbindung die Aktualisierung. Ein Dispatcher validiert und dekodiert die Nutzdaten. Die Render-Pipeline bündelt Zeichenanforderungen und entfernt doppelte Arbeit, bevor der Renderer die Zeichenoperationen in der richtigen Reihenfolge der grafischen Flächen ausführt. Die Weboberfläche wendet die resultierenden Aktualisierungen an und erfasst Nutzereingaben.
Von der Aktualisierung einer Linux-Fläche bis zum Browser: drei Phasen
Der gesamte Ausgabepfad besteht aus drei Phasen: Komposition, Transport und Präsentation.
Komposition
Die Linux-Anwendung übergibt eine Aktualisierung einer grafischen Fläche. Der Compositor aktualisiert seinen Szenengraphen und den Ausgabezustand und rendert die neue Ausgabe in einen Puffer. Die Capture-Middleware liest die gerenderte Fläche. Der Frame-Emitter reiht Aktualisierungen ein, führt sie zusammen und entfernt Duplikate, bevor er den Frame kodiert und die ausgehende Nachricht erstellt.
Transport
Der Verbindungsmanager sendet die kodierte Aktualisierung über WebSocket. Der Webswing-Server empfängt und dekodiert sie, und der Session-Router leitet die Nutzerdaten an die richtige Browsersitzung weiter. Dieses sitzungsbezogene Routing ist wichtig, wenn viele Nutzer oder Anwendungsinstanzen dieselbe Webswing-Umgebung verwenden.
Präsentation
Der Browser empfängt die Nachricht und wandelt sie in Rendering-Anweisungen um. Der Dispatcher prüft die Nutzdaten, die Render-Pipeline bündelt die Arbeit und der Renderer führt die Zeichenoperationen unter Berücksichtigung der Flächenreihenfolge aus. Die Weboberfläche aktualisiert die Browseransicht und erfasst Tastatur- und Zeigereingaben für die Rückübertragung an die Anwendung.
Das Ergebnis ist eine interaktive Linux-Desktop-Anwendung, die über den Browser bereitgestellt wird, während die Anwendung selbst auf dem Server bleibt.
Was Anwendungsteams dadurch gewinnen
Ein Neuschreiben der Anwendung ist keine Voraussetzung
Ziel ist es, eine bestehende Linux-Desktop-Anwendung im Browser zugänglich zu machen, ohne vorher ihre Oberfläche neu aufzubauen oder ihre Geschäftslogik zu ändern. Teams können Bereitstellung und Zugriff unabhängig von langfristigen Modernisierungsentscheidungen angehen.
Keine separate Integration für jedes Anwendungs-Toolkit
Da Linux Web Launcher auf der Ebene des Display-Servers arbeitet, benötigt Webswing keine separate Browserimplementierung für jedes Desktop-UI-Toolkit. Wayland stellt die gemeinsame Schicht bereit, während XWayland den Ansatz auf X11-Anwendungen erweitert.
Das native Erscheinungsbild der Anwendung bleibt erhalten
Die Architektur erfasst und rendert die tatsächliche Ausgabe der Anwendung. Nutzer arbeiten weiterhin mit der vertrauten Oberfläche, und die Anwendung bleibt in der Laufzeitumgebung, für die sie entwickelt wurde.
Ein gemeinsames Bereitstellungsmodell für Java- und Linux-Arbeitsabläufe
Der Mehrwert reicht über den Zugriff auf eine einzelne Linux-Anwendung hinaus. Webswing kann als gemeinsame Schicht für die Bereitstellung im Browser und die Sitzungsverwaltung in technologisch gemischten Anwendungsportfolios dienen.
Eine Java-Anwendung kann Teil desselben Arbeitsablaufs sein wie ein Linux-Editor, Dateibetrachter, Terminal oder Diagnosewerkzeug. Dateien lassen sich zwischen Technologien übergeben und Anwendungen als Teil eines gemeinsamen Prozesses starten. Webswing kann dabei einen einheitlichen Browserzugang für den gesamten Arbeitsablauf bereitstellen.
Der architektonische Kompromiss: Anwendungsausgabe statt semantischer Web-Steuerelemente
Linux Web Launcher arbeitet mit der Anwendungsausgabe auf Pixelebene. Er wandelt nicht automatisch jedes Desktop-Steuerelement in eine semantische Browserkomponente um.
Diese Unterscheidung ist wichtig. Ziel ist die originalgetreue, vom Toolkit unabhängige Bereitstellung einer bestehenden Anwendung, nicht deren automatische Umwandlung in ein neu gestaltetes natives Web-Frontend. Organisationen sollten den Ansatz als Architektur zur Anwendungsbereitstellung bewerten: eine Möglichkeit, funktionierende Software zu erhalten, im Browser zugänglich zu machen und in moderne Betriebsabläufe einzubinden, ohne sie zuerst neu schreiben zu müssen.
Praktische Anwendungsfälle
Der Ansatz eignet sich für mehrere typische Szenarien:
Unterstützende Systemanwendungen: kontrollierter Browserzugriff auf Terminals, Diagnosewerkzeuge und andere Hilfsprogramme, die neben einer zentralen Geschäftsanwendung verwendet werden.
Spezialisierte Anwendungen außerhalb von Java: Bereitstellung von Dateieditoren, Betrachtern und anderer Linux-Desktop-Software, die sonst eine separate Zugriffslösung erfordern würde.
Gemischte Java- und Linux-Arbeitsabläufe: Eine Java- und eine Linux-Anwendung können Teil desselben browserbasierten Prozesses sein, einschließlich Dateiübergabe und Anwendungsstart.
Verwaltete Anwendungssitzungen: Webswing kann Linux-Anwendungen in sein bestehendes Modell zur Nutzer- und Sitzungsverwaltung einbinden.
Datei- und Druckabläufe im Browser: Die Technologie kann kontrollierten Dateizugriff, Verarbeitung und Isolation, technologieübergreifenden Dateiaustausch und virtuelles Drucken unterstützen.
Diese Szenarien spiegeln eine typische Unternehmensrealität wider: Nutzer interessiert nicht, welches Toolkit oder welche Laufzeitumgebung hinter einer Aufgabe steht. Sie benötigen einen zusammenhängenden Arbeitsablauf, während die IT eine handhabbare Lösung zur Bereitstellung und zum Betrieb der beteiligten Anwendungen braucht.
Webswing über Java hinaus erweitern
Webswing konzentrierte sich traditionell darauf, Java-Desktop-Anwendungen in den Browser zu bringen. Linux Desktop to Web erweitert diese Produktausrichtung auf eine breitere Anwendungslandschaft.
Der Grundgedanke bleibt derselbe: bewährte Software auf dem Server weiterbetreiben, unnötige Abhängigkeiten auf Endgeräten beseitigen und den Browser als Oberfläche für die Bereitstellung nutzen. Mit Linux Web Launcher lässt sich dieses Modell auf Anwendungen außerhalb des Java-Ökosystems ausdehnen. Dabei werden die Webswing-Komponenten weiterverwendet, die bereits Konfiguration, Sitzungen, Transport und Browser-Rendering übernehmen.
Linux Web Launcher ist in Webswing 26.2 enthalten und unterstützt native Wayland-Anwendungen sowie X11-Anwendungen über XWayland. Um eine passende Anwendung oder einen technologieübergreifenden Arbeitsablauf zu besprechen, besuchen Sie unsere Linux-Apps-Seite oder kontaktieren Sie sales@webswing.org.
Architektur und Demo im Detail
Die ursprüngliche technische Einführung finden Sie im Webinarartikel: Webinar: Einführung in Webswing 26.1 und über Java hinaus – Linux-Anwendungen in Webswing.
Die vollständige Aufzeichnung mit Architekturüberblick, Konfiguration in der Admin Console und Anwendungsdemo finden Sie hier: Vollständige Webinaraufzeichnung auf YouTube ansehen.
arrow_back_ios
