Realiza el desafío de desarrollo de aplicaciones de mensajería de IBM MQ

Zambúllete y ve lo sencilla que puede ser una solución de mensajería del mundo real.

Sigue las instrucciones paso a paso para desarrollar una aplicación de mensajería que interactúa con un gestor de filas y aplicaciones que hemos proporcionado en un contenedor. Mientras lo haces, dominarás nuevos conceptos y habilidades de mensajería que serán necesarios para aprobar la prueba para obtener el certificado digital IBM MQ Developer Essentials.

Requisitos Previos

Para completar este desafío, será necesario lo siguiente en el entorno local:

  • Java Development Kit (JDK) para desarrollar y ejecutar aplicaciones
  • Clases de JMS en el archivo JMS.jar
  • Clases de IBM e IBM MQ para JMS, en el archivo com.ibm.mq.allclient.jar
  • La muestra de JmsPutGet.java
  • Código de muestra para este desafío de desarrollo de MQ, en mq-dev-badge-sample

El desafío

¡Felicidades! Acabas de empezar un trabajo nuevo como desarrollador para un revendedor de entradas de conferencias.

El líder de tu equipo te dio la tarea de crear una aplicación nueva de mensajería que se integra con un servicio de reservas de conferencias de MQ y automatiza el proceso de asignación de entradas. Esto garantizará que tu nueva organización mantenga el ritmo de la demanda de los clientes. Ya hemos creado el servicio de reservas de eventos, que incluye un gestor de filas, y lo hemos puesto a disposición como una imagen de Docker. Solo es necesario crear la imagen y ejecutarla.

Después, desarrollarás la aplicación de reventa para este desafío. Hemos proporcionado una plantilla de aplicaciones Java en GitHub con comentarios y fragmentos de código adicionales. Solo es necesario rellenar los huecos desarrollando las partes de procesamiento de mensajería y JMS del caso.

Tu código hará lo siguiente

  • Conectarse a un gestor de filas (el que proporcionamos)
  • Subscribirse al tema newTickets
  • Enviar un request message para comprar un lote de entradas, establecer una reply-to destination y un message expiry de 15 minutos (no queremos comprometer una compra de forma indefinida)
  • Obtener un response message de la fila de confirmación que se especifica como el reply-to destination
  • Imprimir el resultado

Por si te quedas estancado en el proceso, hemos incluido un hoja de referencia y empaquetado una respuesta modelo para tu referencia.

Hemos proporcionado tres formas de enfrentar el desafío:

  1. Escribir el código ahora mismo, sobre la marcha
  2. Revisar la aplicación de la respuesta modelo
  3. Intentar corregir un defecto sencillo

Arquitectura del servicio de mensajería de la aplicación cliente

Cuando las entradas empiezan a estar disponibles para su venta, el servicio del tercero genera un mensaje de reventa para notificar a sus suscriptores (¡ese eres tú!).

Después, los revendedores de entradas solicitan un lote de entradas para el evento de la conferencia. Cuando las entradas estén asignadas, el revendedor puede distribuirlas a sus clientes.

Echemos un vistazo al diagrama de arquitectura. Tú desarrollarás la aplicación de reventa.

Diagrama arquitectónico de la aplicación de mensajería del revendedor

Los mensajes se publican en el tema newTickets cada 30 segundos por el servicio de reservas del evento.

La carga útil del mensaje contiene un EventId y el número de entradas disponibles.

La aplicación de reventa utiliza la carga útil que recibió para elaborar un mensaje de solicitud. Finalmente, el servicio de reserva se basa en la fila de compra y responde a cada mensaje del destino JMSReplyTo (fila de confirmación) con una carga útil establecida, de la siguiente manera:

Accepted - <number_of_tickets_allocated> o Rejected - Sold out

Cómo destacar la aplicación de mensajería del cliente que crearás

Estás creando la aplicación del revendedor de entradas, que es una aplicación cliente de IBM MQ.

Para ayudarte a enfocarte en tu MVP (producto mínimo viable), este diagrama muestra los elementos de la aplicación IBM MQ JMS que es necesario crear en relación con el servidor de MQ y con el servicio de revendedor que hemos proporcionado en un contenedor de Docker. Las principales acciones de la aplicación del cliente tienen nombre y número.

Diagrama arquitectónico de la aplicación cliente de MQ

Cuando acabes de desarrollar tu aplicación, esta hará lo siguiente:

  1. Se conectará con un gestor de filas
  2. Se suscribirá a un tema
    • Recibirás una publicación
    • Procesarás una publicación
    • Cuando recibas una publicación, elaborarás y enviarás un mensaje de solicitud a la fila de compra para comprar cero o más entradas. El mensaje de solicitud tiene estas propiedades:
      • indica cuántas entradas hay que pedir
      • para un EventID determinado
      • establece un reply-to destination para la confirmación (de la respuesta)
      • establece la message expiry a 15 minutos
  3. Pone el mensaje de solicitud en una fila de compra (solicitud)
    • (La aplicación coordinadora de compras de entradas obtiene datos de esta fila)
    • (Procesa el mensaje y asigna un número de entradas, si hay alguna disponible)
    • (Pone un mensaje en la fila de confirmación (respuesta). El mensaje de respuesta tiene estas propiedades:
      • dice cuántas entradas se han asignado, si es que hay alguna
      • para un EventID determinado
  4. Obtiene datos de la fila de respuestas
  5. Imprime el número de entradas al evento que se han comprado

La aplicación de mensajería cliente debe tener el siguiente comportamiento:

  • Manejar un mensaje publicado en el tema newTickets cada 30 segundos.
  • Preguntar al usuario cuántas entradas disponibles quiere comprar.
  • Manejar la respuesta que proporciona el servicio de reservas de eventos de conferencias después de procesar tu mensaje de solicitud.
  • Imprimir la salida de la respuesta para stdout.

Comprueba tus requisitos previos

Primero, comprobemos que tienes instalado el Java Development Kit. Envía este comando:

java -version

Deberías ver un resultado similar a:

resultado del comando de la versión de java

Es necesario JDK 8, 1.8.n_nnn.

Si no tienes instalado Java, ve a la página OpenJDK, selecciona OpenJDK 8 y tu plataforma. En algunas plataformas, es posible obtenerlo e instalarlo con la línea de comando. Tan solo asegúrate de que obtienes el JDK (Java Development Kit), para desarrollar, y no el JRE (Java Runtime Environment).

Si completaste el tutorial Desarrollar una aplicación de JMS de punto a punto, ya deberías tener el JDK (Java Development Kit) y el directorio MQClient con los archivos com.ibm.mq.allclient.jar y javax.jms-api-2.0.1.jar. Serán necesarios estos archivos .jar para ejecutar la aplicación del desafío. Si tienes los archivos JDK y .jar en el directorio MQClient, es posible saltar al siguiente paso, obtener el código del desafío.

Si no completaste ese tutorial, hagamos la preparación:

  1. Crea el directorio MQClient para guardar los archivos necesarios para la muestra, por ejemplo, en tu directorio inicial:

     mkdir MQClient
    
  2. Cambia el directorio MQClient, y obtén el archivo com.ibm.mq.allclient.jar con curl.

     curl -o com.ibm.mq.allclient-9.1.4.0.jar https://repo1.maven.org/maven2/com/ibm/mq/com.ibm.mq.allclient/9.1.4.0/com.ibm.mq.allclient-9.1.4.0.jar
    
  3. Desde la carpeta MQClient, obtén el archivo JMS .jar con curl.

     curl -o javax.jms-api-2.0.1.jar https://repo1.maven.org/maven2/javax/jms/javax.jms-api/2.0.1/javax.jms-api-2.0.1.jar
    

Obtén el código del desafío

Es necesario descargar el código del desafío del certificado digital, que se almacena en el repositorio de Github ibm/messaging/mq-dev-badge-sample.

Ve a nuestro repositorio de Github ibm/messaging/mq-dev-badge-sample, y haz clic en el botón clonar o descargar. Es posible clonar con SSH, utilizar HTTPS, o descargar el ZIP con el código. Clona o descomprime el repositorio en el repositorio MQClient.

  1. Cuando tengas el código localmente, cámbialo al directorio de código de la muestra:

    cd mq-dev-badge-sample

  2. Ejecuta el comando print-working-directory para asegurarte de que estás en el lugar adecuado:

    pwd

    Deberías ver que tu ruta acaba en

    ~/MQClient/mq-dev-badge-sample

  3. Escribe ls para listar los contenidos del directorio:

    ls

    Deberías ver estos directorios y archivos:

    ├-- MQTicketService │ ├-- Dockerfile │ . │ . │ └-- TicketGenerator ├-- ModelAnswer ├-- ModelAnswerWithDefectToFix └-- TicketReseller

El directorio MQTicketService tiene Dockerfile con la definición para crear una imagen y levantar un contenedor con el servidor de MQ (gestor de filas). También tiene TicketGenerator con el código Java de las aplicaciones/servicios que interactuarán con tu aplicación cuando las desarrollas y ejecutas. Estas aplicaciones por el lado del servidor se inician dentro del contenedor en el mismo momento que el gestor de filas.

Levantar el sistema de reserva de eventos

Antes de que empieces a desarrollar tu aplicación de revendedor, veamos cómo funcionan el servicio de reservas de eventos o el lado del servidor.

Primero, crearemos una imagen de Docker y ejecutaremos el contenedor con MQ y la aplicación que publica la disponibilidad de entradas y responde a las solicitudes de tu aplicación.

Cuando veamos que funciona, dejaremos que acabe y la reiniciaremos cuando estemos listos para probar la aplicación del desafío.

Sigue estos pasos para levantar el servicio de reserva de eventos:

  1. Dentro del directorio mq-dev-badge-sample, cambia al directorio MQTicketService:

     cd MQTicketService
    
  2. El Dockerfile que tenemos en esta ubicación tiene todo definido para ejecutar MQ dentro del contenedor y las aplicaciones del publicador y de respuestas. Ejecuta el comando para crear la imagen:

     docker build . -t mqbadge:latest
    
  3. Docker obtendrá todos los requisitos previos y creará la imagen. Una vez hecho esto, comprueba que tienes creada la imagen mqbadge:

     docker images
    

    Verás lo siguiente: Salida del comando docker images

  4. Ejecuta el contenedor desde la imagen:

     docker run -e LICENSE=accept -e MQ_QMGR_NAME=QM1 -e LOG_FORMAT=json -e MQ_APP_PASSWORD=passw0rd -p 1414:1414 -p 9443:9443 -ti --name mqebs mqbadge:latest
    

    Verás muy rápidamente el resultado del servicio del contenedor en tu línea de comando. Busca los eventos que se empiezan a publicar: Salida de la ejecución de las imágenes de Docker

El sistema de reserva de eventos ahora se está ejecutando dentro del contenedor. Observa que el contenedor se inició sin la opción --detach para que los registros se muestren en la pantalla mientras el contenedor se está ejecutando.

El proceso del contenedor incluye lo siguiente:

  • La aplicación publicadora, que envía una publicación acerca de las entradas disponibles cada 30 segundos
  • Coordinador de compras de entradas, que procesa solicitudes de compra y asigna un lote de entradas.
    Importante: Este es el núcleo del negocio de reservas de eventos, donde se procesan las solicitudes de compra y se asignan las entradas. IBM MQ Messaging tiene un papel crucial dentro del código de procesamiento de eventos de conferencias, proporcionando una entrega garantizada de mensajes de alto valor entre el servicio de reserva de eventos de conferencias y los revendedores de entradas. Es vital que el negocio de reservas de eventos de conferencias haga esto de forma adecuada, ya que el exceso de venta de entradas o la falta de respuestas a las solicitudes puede dañar a su reputación.
  • Servidor IBM MQ, que es el gestor de filas que aloja el tema de la suscripción newTickets, la fila de compra para los mensajes de solicitudes y la fila de confirmación para los mensajes de respuestas.

Las filas se crearon de forma administrativa ejecutando comandos de MQSC cuando se inició el contenedor de Docker. En la consola de MQ también se pueden crear objetos de filas con la interfaz de MQ REST o de forma programática.

Ahora estás listo para empezar a desarrollar tu aplicación de reventa. Pero, primero, veamos cómo funciona la aplicación ModelAnswer con el servicio de reserva de eventos.

Ejecuta la aplicación ModelAnswer para verla en acción

Abre otro terminal y ve al directorio MQClient/mq-dev-badge-sample/ModelAnswer.

Desde ese directorio, ejecuta el comando para compilar la aplicación:

javac -cp ../../com.ibm.mq.allclient-9.1.4.0.jar:../../javax.jms-api-2.0.1.jar com/ibm/mq/demo/*.java

Este comando solo funciona si los archivos .jar están en el directorio MQClient. Ve las secciones Comprueba tus requisitos previos y Obtén el código del desafío para asegurarte de que tu código estás creado correctamente.

Comprueba que la aplicación se compiló correctamente mirando a los archivos:

`ls com/ibm/mq/demo`

Deberías ver las clases compiladas junto con los archivos de Java:

Salida del directorio de la aplicación compilada

Vuelve a la ventana original del terminal donde se paró el contenedor con el servicio.

Pon lado a lado las dos ventanas del terminal para que sea posible interactuar fácilmente con ellas.

dos ventanas de terminal de lado a lado

En el terminal del contenedor de Docker de la izquierda, es necesario reiniciar el contenedor y ver la salida del servidor y de la ejecución de la aplicación. Inicia el contenedor:

```
docker restart mqebs
```

Obtén la salida del contenedor en el terminal:

```
docker container attach mqebs
```

En el terminal de la derecha, prepara el comando para ejecutar la aplicación ModelAnswer, pero espera a que empiecen a aparecer los eventos en el terminal del servidor antes de introducir el comando:

```
java -cp ../../com.ibm.mq.allclient-9.1.4.0.jar:../../javax.jms-api-2.0.1.jar:. com.ibm.mq.demo.Reseller
```

dos ventanas de terminal de lado a lado con comandos

Ahora, cuando ejecutes el comando para iniciar la aplicación ModelAnswer deberías ver:

dos ventanas de terminal de lado a lado con comandos

Cuando se publique el siguiente conjunto de entradas disponibles, deberías ver una ventana en el terminal de ModelAnswer que te solicita el número de entradas que quieres reservar:

dos ventanas de terminal de lado a lado con comandos

Ingresa el número de entradas que quieres reservar en el terminal de la aplicación ModelAnswer. Deberías ver los mensajes del intercambio en ambos terminales.

dos ventanas de terminal de lado a lado con comandos

El contenedor saldrá cuando no haya más eventos de entradas para publicar.

dos ventanas de terminal de lado a lado con comandos

La aplicación ModelAnswer no saldrá hasta que ingreses un número de entradas para el último evento anunciado. Deberías ver que la aplicación se desconecta porque las aplicaciones del contenedor también se desconectaron y el gestor de filas de MQ paró las hebras y cerró las conexiones.

dos ventanas de terminal de lado a lado con comandos

Ahora que has visto cómo la aplicación y el servicio interactúan, escribe tu propio código de Java en el directorio TicketReseller, o corrige el defecto y la ejecución de las cosas en el directorio ModelAnswerWithDefectToFix.

Cómo desarrollar para la aplicación de reventa

Es posible que por comodidad quieras usar un IDE de Java como Eclipse. En caso contrario, puedes desarrollar tu código en tu editor favorito como Atom.

Abre el directorio TicketReseller o ModelAnswerWithDefectToFix en el editor que elijas.

El código de muestra está desglosado en varias clases. Para completar el desafío, es necesario hacer actualizaciones de código en estas clases:

  • SessionBuilder.java
  • TicketSubscriber.java
  • TicketRequester.java

Los comentarios de los fragmentos de código de estas clases deberían guiarte en lo que hace falta hacer. Consulta las secciones anteriores para saber lo que tu aplicación necesita hacer, obtener ayuda para la compilación y encontrar ejemplos acerca de cómo funcionan las aplicaciones.

¿Es necesario depurar?

¿Algo salió mal? Echa un vistazo a la hoja de referencia.

Cómo mejorar tu aplicación

Para aprender más acerca de aplicaciones cliente de mensajería listas para producción, es necesario considerar la seguridad y la persistencia de los mensajes. También podrías considerar la transaccionalidad de tus mensajes.

¿Por qué utilizar mensajes?

Las aplicaciones de reventa y el sistema de eventos de conferencias están vinculados de forma flexible. La mensajería asíncrona nos permite integrar estos componentes y crear en un búfer, o amortiguador. Si alguno de los componentes pierde la conectividad, falla o experimenta variaciones de rendimiento, la capa de mensajería se encargará de cualquier inestabilidad. El código de nuestra aplicación está simplificado porque la capa de mensajería se encarga de las cosas difíciles, como la seguridad, la recuperación y la persistencia del intercambio de mensajes entre los componentes.

La API de mensajería brinda una estructura para que la lógica de la aplicación de reventa se lance cuando se entrega un mensaje, en vez de estar constantemente preguntando al servidor para ver si hay trabajo. Esto quita carga innecesaria de la red y de la aplicación de eventos de conferencias. IBM MQ permite que la solución escale a medida que aumenta la demanda.

Estilo de mensajería de publicar/suscribir

Publicar/suscribir es uno de los estilos de mensajería que IBM MQ implementa. El otro es punto a punto. En punto a punto, los mensajes se intercambian entre dos aplicaciones individuales. En publicar/suscribir, uno o más publicadores pueden publicar para uno o más suscriptores de un tema.

Así es como el sistema de mensajería publicar/suscribir se implementa en nuestra solución: Estilo de mensajería de publicar/suscribir para esta solución de mensajería

El servicio de reserva de eventos es el publicador, y la aplicación de reventa es uno de los suscriptores. Hablemos acerca de los otros componentes de este sistema de mensajería:

  • Los temas son objetos y tienen propiedades.
  • La propiedad principal de un tema es una cadena del tema.
  • El publicador es el que publica los mensajes en una cadena de mensajes.
  • Cada publicación es para una única cadena de temas. Los suscriptores registran su interés o se suscriben a una cadena de temas.
  • Cuando un publicador elabora un mensaje en una cadena de temas, uno o más suscriptores de esa cadena de temas reciben el mensaje de la publicación.
  • En un escenario de punto a punto, una aplicación de JMS puede utilizar el objeto de destino de JMS que se correlaciona con un tema de la misma manera que si usase el destino para correlacionarse con una fila. Para que la publicación llegue correctamente al suscriptor, tanto en el publicador como el suscriptor deben coincidir en la cadena de temas. El suscriptor obtendrá las publicaciones solo por el tiempo por el que está suscrito a un tema.
  • Si una publicación se envía antes de que se cree la suscripción por una aplicación específica, la aplicación no la obtendrá.

Patrón de mensajería de Solicitud/Respuesta

La respuesta a la solicitud, un patrón de integración o de mensajería en el que la aplicación que envía un mensaje a otra aplicación, requiere que la aplicación receptora la responda de alguna manera. A menudo, esto se basa en el estilo de mensajería de punto a punto y puede ser síncrona (la aplicación remitente espera la respuesta antes de caducar por tiempo de espera) y asíncrona (también llamada solicitud/verificación, donde la aplicación remitente se desconecta, pero establece una verificación para manejar una respuesta).

Tu aplicación de reventa es la aplicación remitente, y el servicio de reserva de eventos es la aplicación receptora. Estilo de mensajería de publicar/suscribir para esta solución de mensajería

La aplicación remitente normalmente establece un reply-to-destination y una correlation-id para que la respuesta pueda llegar a la aplicación remitente adecuada.

Para el servicio de reserva de eventos, el destino de reply-to se definió de forma administrativa en el gestor de filas. Sin embargo, el solicitante podría crear de forma dinámica un destino temporal desde su sesión de JMS para completar el intercambio.

Cómo proteger tu aplicación

Descubre cómo es posible configurar tu gestor de filas y aplicación cliente para [usar TLS para cifrar mensajes][/tutorials/mq-secure-msgs-tls] mientras fluyen por internet entre el servidor y el cliente.

Cómo establecer la persistencia de los mensajes en la aplicación

Cuando se diseña una aplicación, es importante considerar la persistencia de los mensajes. IBM MQ da soporte a la mensajería persistente y no persistente. En nuestro caso de reserva de evento, utilizamos la mensajería persistente como ajuste predeterminado en las filas predefinidas de MQ.

En el caso grave de un corte del sistema, los mensajes no persistentes se podrían perder después de la recuperación. Aunque en la mayoría de los casos, la mensajería no persistente puede intercambiar los mensajes de forma más rápida, lo que no es la solución adecuada para todas las aplicaciones.

Por ejemplo, la persistencia puede ser importante para un mensaje de valor alto, pero bajo para un escenario en el que se trasmiten constantemente mensajes informativos. En el último caso, el diseño del sistema puede permitir algún nivel de pérdidas mensajes.

Es posible leer más acerca de la persistencia de mensajes en el IBM MQ Knowledge Center.

¿Qué ocurre con la transaccionalidad de mis mensajes?

A menudo, las aplicaciones de producción son más sofisticadas que nuestra muestra, con interacciones que implican varios recursos, como actualizaciones de mensajes o de bases de datos, que se coordinan en una única operación atómica. Se dice que los recursos que se gestionan de esta manera ocurren en una unidad de trabajo o transacción.

Por ejemplo, una transacción bancaria sencilla puede implicar que en una cuenta se debiten USD 100 y en la otra se deposite la misma cantidad. Se utiliza un coordinador transaccional para garantizar que ambas operaciones se realicen correctamente, o que no se realice ninguna.

A medida que aumenta la complejidad de la aplicación, se utilizan estructuras de escala empresarial para coordinar transacciones que ocurren entre varias aplicaciones o sistemas backend. Estructuras de escala empresarial como las que proporcionan:

Cómo enfocarse en el rendimiento de la aplicación

Si quieres asegurarte de que tu aplicación va a tener un comportamiento bueno y confiable, echa un vistazo a estas mejores prácticas para desarrolladores.

Resumen y próximos pasos

¡Felicidades! Comprobaste nuestro repositorio de GitHub con tres formas de interactuar nuestra muestra. Asegúrate de que lees la hoja de referencia de MQ, porque está llena de trucos de experto que todos los desarrolladores de MQ deberían conocer.

Si acabaste y estás listo para realizar la prueba y obtener tu certificado digital de MQ Developer Essentials, vuelve a la página de certificado Digital IBM MQ Developer Essentials ¡y haz clics a lo largo de la prueba!

Aviso

El contenido aquí presentado fue traducido de la página IBM Developer US. Puede revisar el contenido original en este link.