WebSocket con Java

WebSockets con JavaEn este artículo aprenderemos a implementar WebSocket con Java, ya que en el pasado ya había dado una completa Introducción a los WebSocket y explicamos que estos fueron introducidos como una mejora en HTML5, pero también dijimos que los WebSocket son ejecutados por el navegador, y estos requieren de dos partes, un WebSocket cliente (Navegador) y un WebSocket Server (Backend). Pues bien, ya habíamos platicado como es que los WebSocket funcionan del lado del navegador, es por eso que ahora hablaremos de la otra cara, los WebSocket Server.

 

Como el título de este articulo lo dice, hablaremos de cómo implementar los WebSocket utilizado Java como BackEnd, pero cabe mencionar que todos los lenguajes de programación deberían de tener sus propias API’s para soportar conexiones del lado del servidor.  Los WebSocket fueron agregados a apartar de la versión Java EE 7 bajo la especificación JSR 356, es por ello que todos los Application Server certificados para Java EE 7 deberán de tener una implementación estándar de dicha especificación. Basta de charla y pasemos a cómo implementar un WebSocket con Java.

 

Implementando un WebSocket con Java

 

Para explicar cómo funcionan los WebSocket vamos a implementar un ejemplo muy simple, crearemos una barra de progreso la cual se cargará del valor 0 al 100 simulando que un proceso se está ejecutando en el BackEnd. En el formulario tendremos un botón que iniciara el proceso, cuando el usuario presione el botón, enviaremos un mensaje al BackEnd por medio del WebSocket, en ese momento, el BackEnd iniciara con un proceso de notificaciones el cual enviará por medio del WebSocket un mensaje con las actualizaciones de la barra de progreso. Este ejemplo está desarrollado con Java 8 y Wildfly 9.0.

WebSocket con Java

 

Este ejemplo está compuesto de 4 archivos:

  • html: página principal del proyecto, sobre la que mostraremos la barra de progreso.
  • js: Archivo de JavaScript en donde está programado el WebSocket y el procesamiento de los mensajes de envío y recepción.
  • css: archivo de clases de estilo (opcional).
  • java: Clase donde implementamos el WebSocket Server con Java, esta se ejecuta del lado del servidor.

 

WebSocket con Java

Todo el código del proyecto lo puedes descargar de GitHub: https://github.com/oscarjb1/ProgressWebSocket.git

 

Index.html

 

Primero que nada, veremos el documento index.html para entender como esta armada la pantalla:

 

Lo primero que hacemos en el Header es importar al archivo styles.css del cual no hay mucho que decir, salvo que es utilizado para darle una apariencia más agradable a la página, y el archivo websocket.js del cual hablaremos más adelante.

 

El siguiente punto importante es el formulario, en el definimos un botón que al presionarlo ejecutara la función formSubmit() que está definido en el archivo websocket.js, que iniciara con el proceso de carga del progress bar.

También tenemos un progress, el cual será actualizado a medida que el WebSocket reciba las notificaciones del BackEnd, para lo cual utilizaremos el ID (progress) para identificarlo más adelante. Finalmente, debajo del progress tenemos un label el cual será actualizado con el progreso del progress bar.

 

Tanto el progress como el label son actualizados por Javascript a medida que el servidor manda los datos por medio del WebSocket.

 

 

Websocket.js

 

Por su nombre, podríamos pensar que se trata de una librería o algún script ya desarrollado, pero la realidad es que es un Script totalmente custom y desarrollado a la medida para esta solución.

 

La primera línea es la más importante, pues en esta se establece la conexión con el servidor, la clase WebSocket es una clase estándar que nos permitirá comunicarnos con el Servidor de una forma simple, esta clase tiene como parámetro la URL sobre la cual escucha el BackEnd, más adelante veremos cómo está formada esta URL, por lo pronto asumamos que existe un WebSocket Server que está escuchando.

En la línea 2 definimos la función que procesara los mensajes entrantes, es decir, cuando el BackEnd envíe un mensaje al navegador, este lo atenderá por medio del método definido, en este caso, establecemos el método onMessage para procesar los mensajes entrantes.

En la línea 4 definimos el método onMessage el cual implementa toda la lógica de procesamiento de los mensajes entrantes, el parámetro event corresponde al evento recibido y mediante event.data es posible recuperar el mensaje que envió el Servidor. Veamos qué es lo que hace. Primero que nada, en las líneas 5-6 obtenemos la referencia el botón y lo deshabilitamos para impedir que se presione mientras esta en procesamiento. En la línea 8 convertimos el mensaje enviado por el Server en un Json para poderlo procesar. En las líneas 10-11 obtenemos una referencia al progress y actualizamos el valor de la barra de progreso, para lo cual establecemos la propiedad value por el valor enviado por el Servidor. En las líneas 13-19 establecemos el valor del label, indicando el progreso recibido por el servidor, en caso de finalizar (100%), la etiqueta cambia a Finish y el botón se habilitado nuevamente.

 

Finalmente, en las últimas líneas, tenemos el método formSubmit, el cual es ejecutado por el botón cuando es presionado, este método manda un mensaje dummy al servidor mediante el método send del WebSocket.

 

ServerDashboardWebSocket.java

 

Esta es la parte principal para implementar un WebSocket con Java, ya que desde aquí es de donde se aceptan las conexiones del navegador y se procesan los mensajes de envío y recepción.

 

 

Primero que nada, observemos que esta es una clase común y corriente, no extiende ni implementa ninguna clase, sin embargo, esta anotada con @ApplicationScope y @ServerEndpoint. Si ya has trabajado con JavaEE es muy probable que conozcas la primera, la cual no pertenece al API de WebSocket, pero es utilizada para crear un Bean disponible durante toda la vida de la aplicación. La segunda, @ServerEndpoint es en la que debemos de poner atención, con tan solo marcar una clase con ella, le estamos diciendo al Application Server que esta se trata de un WebSocket Server el cual estará escuchando en la URL http://<HOST>:<PORT>/<APPLICATION>/progress, la última parte de la url (/progress) es la que definimos en la anotación @ServerEndpoint por lo que tenemos que tener cuidado de que coincida con la URL que definimos en el archivo websocket.js.

 

También podemos ver que tenemos una Set de Session. Las Session son objetos que representan las conexiones de los navegadores, por lo que tendremos un Set para no perder la referencia a todas las conexiones.

 

A continuación, veremos una serie de métodos anotados, estas anotaciones le dicen a Application Server que método debe de ejecutar ante cualquier evento. Veamos los diferentes métodos.

 

Método open, está marcado con la anotación @OnOpen y se ejecutara cada vez que una nueva conexión se establezca con el servidor, el parámetro Session representa la conexión y la almacenamos en el Set de sesiones.

 

Método close, esta anotado con @OnClose y se ejecutara cada vez que una sesión se desconecte. Recibe el objeto Session que se desconectó para poder identificarla.

 

Método onError, esta anotado con @OnError, y se ejecutara ante cualquier error, el error es enviado como parámetro.

 

Método handleMessage, anotado con @OnMessage, será ejecutado cada vez que llegue un nuevo mensaje de alguno de los navegadores. Este recibe como parámetro el mensaje enviado y el objeto Session que mando el mensaje. Este es el método más importante en nuestro ejemplo, porque una vez recibido un mensaje, iniciara una serie de envíos de mensajes al navegador. Observemos que haremos un ciclo del 1 al 100 y en cada interación enviaremos al Navegador un mensaje con el progreso, al finalizar cada interación, dormiremos el hilo 100 milisegundos para apreciar mejor como se llena la barra. Utilizamos el método getBasicRemote() para que nos regrese una implementación de envío asíncrono y seguido ejecutamos el método sendText, el cual se utiliza para mandar un mensaje de texto al navegador.

 

 

Resumen:

 

Repasemos como funciona todo, cuando entramos a la página, esta carga el archivo websocket.js y establece conexión inmediata con el Servidor, en este momento el método open de la clase ServerDashboardWebSocket.java es ejecutado para recibir la nueva sesión. Seguido, el usuario presiona el botón start y envía mediante el función websocket.send un mensaje al Servidor, el Servidor recibe el mensaje mediante el método handleMessage de la clase ServerDashboardWebSocket.java, el cual envía una serie de mensaje como respuesta al navegador, por su parte, el navegador procesa los mensajes entrantes mediante la función onMessage de JavaScript, en esta función se actualiza la barra de progreso.

 

Artículos relacionados

Novedades de la etiqueta Table en HTML5 La etiqueta Table es sin duda la mejor opción para representar elementos en formato tabular o en tabla, debido a que permite crear rejillas perfectas ...
IDE vs Editor de texto Una de las grandes preguntas que todo desarrollador se hace al iniciar su vida profesional es, ¿qué es mejor un IDE o un editor de texto?, o simplemen...
Java 9 – análisis de las novedades Java 9 trae importantes novedades, pero todo sobre sale el sistema de módulos, para conocer todo acerca de java 9, te invito a veas mi articulo "J...

Oscar Blancarte

Ideológico, Innovador y emprendedor, Padre, Tecnólogo y Autor, amante de la ciencia y la tecnología en todos sus colores y sabores. Arquitecto de software & Full Stack Developer con experiencia en la industria del desarrollo de software y la consultoría. Amante de la programación y el Ajedrez.

11 comentarios en “WebSocket con Java

    1. Hola Diego, esa es una fantástica pregunta!, te cuento como funciona. Recuerda que el WebSocket se crea desde JavaScript, por tal motivo, cada vez que el navegador se refresca carga de nuevo la página y destruye todo lo que existía previamente. Entonces la respuesta es SI, cada vez que actualizas la pestaña o cambias de página el WebSocket se desconecta y cuando la página vuelve a cargar crear otra Sesión.

      Si lo que quieres es mantener existente el mismo WebSocket durante toda la estancia del usuario deberás usar Ajax para cargar dinámicamente el contenido sin tener que cambiar de página, de esta forma la página actual prevalece y solo se carga el contenido nuevo con una petición Ajax. Otra estrategia que puedes usar, que si bien no mantiene la sesión abierta, es que cada vez que te reconectes ligues la sesión con algún dato del usuario, así cada vez que se reconecte, sabrás que es la misma persona aunque la sesión sea distinta.

      Espero que sea la respuesta que esperabas.
      Saludos.

  1. Buen articulo.

    Tengo una duda, usando websockets en un cluster de tomcat, ¿podemos enviar un mensaje a todas las sesiones? del cluster ( no solo al nodo que origine el evento)

  2. Hola Oscar , como puedo hacer para que no se desconecte del websocket , hacer que se quedara el canal abierto por cada conexion que se realice

    1. Hola Jorge, esa parte se configura desde el backend, tendrás que guardar la referencia a la sesión en un nivel de aplicación, ya que si guarda la referencia en una variable local, se desconectará apenas termine la ejecución del método. Por otra parte, puedes utilizar los eventos de los websocket para callar una desconexión del lado del navegador, para que en tal caso, vuelva a conectarse inmediatamente.

      saludos.

  3. Hola Oscar, como podria manejar diferentes eventos OnMessage? Lo que ocurre es que trato de hacer una pizarra compartida, entonces necesito en OnMessage para dibujar en el canvas lo que otros hagan, pero tambien quiero estar “pendiente” de si un usuario abandona la sala, o ingresa otro usuario, y eso lo voy a gestionar de otra manera, la cuestion es que no se como manejar por separado esos 2 eventos. Excelente post!

    1. Hola Jean disculpa la demora, lo que podrías hacer, es que todos los mensajes tenga una propiedad “type”, la cual te permite distinguir que tipo de mensaje es, así, cuando te llegue un tipo determinado, lo procesas de una manera, y cuando te llega otro “type”, lo procesas de otra forma.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *