Lleva tus aplicaciones de escritorio Linux existentes al navegador sin reescribirlas. Descubre cómo Linux Web Launcher utiliza Wayland, XWayland y la infraestructura de sesiones de Webswing para ofrecer sus interfaces originales.
Las carteras de aplicaciones empresariales rara vez se limitan a una sola tecnología. Además de las aplicaciones de escritorio Java, muchas organizaciones dependen de editores, visores, terminales, herramientas de diagnóstico y aplicaciones especializadas basadas en Linux que siguen siendo importantes para el trabajo diario.
Las aplicaciones en sí pueden seguir siendo fiables. La dificultad suele estar en cómo se ponen a disposición de los usuarios: distintos métodos de acceso, infraestructuras separadas, licencias adicionales, soporte fragmentado y flujos de trabajo que obligan a pasar de un entorno desconectado a otro.
El enfoque Linux Desktop to Web de Webswing está diseñado para resolver este problema. La aplicación sigue ejecutándose en su entorno Linux original en el servidor, mientras su interfaz de usuario se ofrece a través del navegador. El componente que lo hace posible es Linux Web Launcher (LWL), basado en un compositor Wayland propio e integrado con el frontend, el servidor, la gestión de sesiones y la infraestructura de administración de Webswing.
Consulta nuestra página de aplicaciones Linux para conocer los casos de uso habituales, las opciones de despliegue y una demo en el navegador.
La aplicación permanece en su entorno de ejecución Linux original
Linux Desktop to Web no requiere reescribir la aplicación ni realizar un proyecto de conversión para cada toolkit. La aplicación Linux se ejecuta en el servidor, en el entorno para el que fue creada. Lo que cambia es la capa de acceso entre la aplicación y el usuario.
Linux Web Launcher proporciona el entorno de visualización que necesita la aplicación, captura su salida renderizada y la conecta con el mecanismo de Webswing para ofrecer aplicaciones a través del navegador. Las interacciones del usuario se transmiten de vuelta a la aplicación. Así, el navegador se convierte en el punto de acceso, mientras el software permanece en su entorno de ejecución original.
Este enfoque resulta especialmente útil cuando la aplicación sigue aportando valor, pero sustituirla es difícil, arriesgado o simplemente innecesario.
Por qué Webswing trabaja a nivel del servidor de visualización
Las aplicaciones de escritorio Linux pueden utilizar distintas tecnologías de interfaz, pero todas necesitan un servidor de visualización. Esto convierte esa capa en un punto de integración común y práctico.
Un compositor Wayland gestiona las conexiones de las aplicaciones y sus superficies gráficas, compone la escena final, dirige los eventos de entrada y mantiene el aislamiento entre clientes. Linux Web Launcher implementa un compositor propio para esta función. Admite aplicaciones nativas de Wayland y aplicaciones X11 a través de XWayland, por lo que la arquitectura no está vinculada a un único toolkit.
Trabajar en este nivel tiene tres consecuencias importantes:
Webswing captura la salida real de la aplicación en lugar de reconstruir su interfaz control por control.
Las aplicaciones pueden ejecutarse en el servidor sin una pantalla física y seguir disponiendo de un entorno de visualización completo.
La integración se puede compartir entre distintas aplicaciones de escritorio Linux, en lugar de reconstruirla para cada framework de interfaz.
Cómo encajan las capas de la arquitectura de Linux Web Launcher
La arquitectura se puede entender como cuatro capas que colaboran entre sí.
1. La aplicación Linux
La aplicación se ejecuta en el servidor como cliente Wayland o, en el caso de una aplicación X11, a través de XWayland. Conserva su propia lógica de interfaz y envía las actualizaciones de sus superficies siguiendo el modelo habitual del escritorio Linux.
2. El compositor propio y el middleware de captura
El compositor Wayland propio gestiona las ventanas de las aplicaciones, la composición de superficies y las entradas. Actualiza la escena y renderiza la salida resultante en un búfer. Por debajo, componentes gráficos estándar de Linux como Mesa 3D, DRM/KMS y el kernel de Linux proporcionan la base para la renderización.
El middleware de captura lee la salida renderizada del búfer gráfico. A continuación, un emisor de fotogramas pone las actualizaciones en cola, elimina duplicados, codifica los fotogramas cuando es necesario y construye el mensaje que se enviará a través de Webswing.
3. El servidor Webswing y la capa de sesiones
Un gestor de conexiones envía la actualización por WebSocket. El servidor Webswing recibe y decodifica el mensaje, mientras el enrutador de sesiones identifica la sesión de usuario correcta y le reenvía los datos de la aplicación.
Esta capa reutiliza la infraestructura que ya existe en Webswing: el frontend del navegador, la gestión de sesiones en el servidor y Admin Console para configurar y supervisar las aplicaciones. De este modo, la distribución de aplicaciones Linux forma parte del mismo modelo operativo, en lugar de requerir una infraestructura de acceso independiente.
4. La capa de presentación del navegador
En el navegador, la conexión WebSocket recibe la actualización. Un despachador valida y decodifica los datos, la canalización de renderización agrupa las solicitudes de dibujo y elimina el trabajo duplicado, y el renderizador ejecuta las operaciones en el orden correcto de las superficies. La interfaz web aplica las actualizaciones resultantes y captura las entradas del usuario.
De una actualización de superficie Linux al navegador: un ciclo de tres fases
El recorrido completo de la salida se organiza en tres fases: composición, transporte y presentación.
Composición
La aplicación Linux envía una actualización de superficie. El compositor actualiza su grafo de escena y el estado de la salida, y renderiza la nueva salida en un búfer. El middleware de captura lee la superficie renderizada y el emisor de fotogramas pone las actualizaciones en cola, las combina y elimina duplicados antes de codificar el fotograma y construir el mensaje de salida.
Transporte
El gestor de conexiones envía la actualización codificada por WebSocket. El servidor Webswing la recibe y decodifica, y el enrutador de sesiones reenvía los datos del usuario a la sesión correcta del navegador. Este enrutamiento por sesión es importante cuando muchos usuarios o instancias de aplicaciones comparten el mismo entorno Webswing.
Presentación
El navegador recibe el mensaje y lo convierte en instrucciones de renderización. El despachador comprueba los datos, la canalización de renderización agrupa el trabajo y el renderizador aplica las operaciones de dibujo respetando el orden de las superficies. La interfaz web actualiza la vista del navegador y captura las entradas del teclado y del puntero para devolverlas a la aplicación.
El resultado es una aplicación de escritorio Linux interactiva a la que se accede desde el navegador, mientras la propia aplicación permanece en el servidor.
Qué aporta este enfoque a los equipos de aplicaciones
Reescribir la aplicación no es un requisito previo
El objetivo es permitir el acceso a una aplicación de escritorio Linux existente desde el navegador sin reconstruir antes su interfaz ni modificar su lógica de negocio. Los equipos pueden abordar la distribución y el acceso por separado de las decisiones de modernización a largo plazo.
Sin una integración específica para cada toolkit
Como Linux Web Launcher trabaja en la capa del servidor de visualización, Webswing no necesita una implementación independiente para el navegador por cada toolkit de interfaz de escritorio. Wayland proporciona la capa común y XWayland amplía el enfoque a las aplicaciones X11.
Se conserva la apariencia nativa de la aplicación
La arquitectura captura y renderiza la salida real de la aplicación. Los usuarios siguen trabajando con la interfaz que ya conocen y la aplicación permanece en el entorno de ejecución para el que fue diseñada.
Un único modelo de acceso para flujos de trabajo Java y Linux
El valor no se limita al acceso a una aplicación Linux individual. También permite utilizar Webswing como capa común de acceso desde el navegador y gestión de sesiones para carteras de aplicaciones que combinan tecnologías.
Una aplicación Java puede formar parte del mismo flujo de trabajo que un editor, visor, terminal o herramienta de diagnóstico de Linux. Los archivos se pueden transferir de una tecnología a otra, las aplicaciones se pueden iniciar como parte de un proceso compartido y Webswing puede proporcionar un punto de entrada uniforme desde el navegador para todo el flujo de trabajo.
El compromiso arquitectónico: salida de la aplicación, no controles web semánticos
Linux Web Launcher trabaja con la salida de la aplicación a nivel de píxeles. No transforma automáticamente cada control de escritorio en un componente semántico del navegador.
Esta distinción es importante. El objetivo es ofrecer una aplicación existente de forma fiel e independiente del toolkit, no convertirla automáticamente en un nuevo frontend web nativo. Las organizaciones deberían evaluarlo como una arquitectura de distribución de aplicaciones: una forma de conservar el software que funciona, permitir su acceso desde el navegador e integrarlo en flujos operativos modernos sin tener que reescribirlo primero.
Casos de uso prácticos
Este enfoque resulta relevante en varios escenarios habituales:
Aplicaciones auxiliares del sistema: acceso controlado desde el navegador a terminales, herramientas de diagnóstico y otras utilidades que se utilizan junto con una aplicación empresarial principal.
Aplicaciones especializadas ajenas a Java: acceso a editores de archivos, visores y otro software de escritorio Linux que, de otro modo, requeriría una solución de acceso independiente.
Flujos de trabajo que combinan Java y Linux: una aplicación Java y una aplicación Linux pueden participar en un mismo proceso en el navegador, incluidas la transferencia de archivos y la ejecución de aplicaciones.
Sesiones de aplicación gestionadas: Webswing puede incorporar las aplicaciones Linux a su modelo existente de gestión de usuarios y sesiones.
Flujos de archivos e impresión en el navegador: la tecnología puede admitir el acceso controlado a archivos, su procesamiento y aislamiento, el intercambio entre tecnologías y la impresión virtual.
Estos escenarios reflejan una realidad empresarial habitual: a los usuarios no les importa qué toolkit o entorno de ejecución hay detrás de una tarea. Necesitan un flujo de trabajo coherente, mientras que TI necesita una forma manejable de ofrecer y operar las aplicaciones implicadas.
Ampliar Webswing más allá de Java
Webswing se ha centrado tradicionalmente en llevar las aplicaciones de escritorio Java al navegador. Linux Desktop to Web extiende esa misma dirección del producto a un panorama de aplicaciones más amplio.
La idea de fondo sigue siendo la misma: mantener el software probado en el servidor, eliminar dependencias innecesarias en los dispositivos de los usuarios y utilizar el navegador como superficie de acceso. Con Linux Web Launcher, este modelo puede abarcar aplicaciones ajenas al ecosistema Java y reutilizar los componentes de Webswing que ya se encargan de la configuración, las sesiones, el transporte y la renderización en el navegador.
Linux Web Launcher está incluido en Webswing 26.2, con soporte para aplicaciones nativas de Wayland y aplicaciones X11 a través de XWayland. Para explorar una aplicación o un flujo de trabajo que combine tecnologías, visita nuestra página de aplicaciones Linux o contacta con sales@webswing.org.
Descubre la arquitectura y la demo en detalle
Para conocer la presentación técnica original, lee el artículo del webinario: Webinario: Introducción a Webswing 26.1 y más allá de Java – aplicaciones Linux en Webswing.
La sesión completa, con la explicación de la arquitectura, la configuración de Admin Console y la demo de la aplicación, está disponible aquí: Ver la grabación completa del webinario en YouTube.
arrow_back_ios
