Parte 5 - Caso de uso

Indice
Parte 4 - Descripción técnica del servicio

 

Código del ejemplo

https://github.com/davsuapas/QueueService

Video demostrativo del proceso

En este video se puede ver un ejemplo de utilización del servicio.

Descripción del proceso

Para demostrar la viabilidad del sistema y teniendo en cuenta los objetivos anteriormente mencionados, crearemos un proceso de negocio test que mostrará en consola el mensaje enviado por un supuesto cliente y el nombre del canal asociado al escuchador de la cola. El nombre del canal se indicará explícitamente a través del fichero de configuración que luego describiremos con más detalle. Con esto queremos demostrar que mediante el fichero de configuración xml podemos enviar metadatos al proceso de negocio. Un ejemplo podría ser la cadena de conexión de una base de datos. Para el ejemplo que nos atañe nos valdrá con el nombre del canal. El proceso de negocio se encuentra embebido dentro de un ensamblado .net y con esto demostramos que los procesos de negocio se encuentran totalmente desacoplados del servicio de colas. El servicio de colas posee mecanismos propios para en-rutar los mensajes a cada proceso de negocio a través de sus canales.

Por otro lado, también se creará un simulador para él envió de mensajes a dos colas diferentes llamadas “canal1” y “canal2”. Este simulador enviará 50 mensajes por canal que serán procesados por el servicio de colas y en-rutados a su proceso de negocio asociado que ya describimos anteriormente.

Por último he creado un host que alojará el servicio de colas de alto rendimiento. Este servicio una vez programado no será necesario volverlo a reprogramar. Toda la configuración es realizada a través de metadatos mediante un fichero de configuración xml. Todas las opciones de configuración se encuentran detalladas en la parte 4 de este blog. Para el caso de uso que nos atañe configuraremos dos canales de escucha diferentes a una misma conexión del servicio de colas y cada una soportará un pool de dos hilos máximos de ejecución para procesar mensajes.

En la figura de abajo podemos apreciar el flujo del mensaje que es enviado por el simulador.

El simulador envía los diferentes mensajes al servidor de colas. En nuestro caso dos colas llamadas “Canal1” y “Canal2”. El servicio de colas recepciona los mensajes de las diferentes colas y en-ruta los mensajes a los canales correctos y a su vez en-ruta los mensajes a los procesos correspondientes que consumirán los mensajes. Estos mensajes en nuestro caso serán procesados por dos hilos por canal.

Descripción de cada módulo

Modulo: Proceso de negocio

Nombre: TestBusinessProcess
Nombre ensamblado (dll): TestBusinessProcess.dll
Clase: HelloWorldProcess

Se encarga de ejecutar el mensaje enviado a la cola. Para que un mensaje pueda ser en-rutado correctamente al proceso de negocio, la clase que lo procesa, debe heredar de ProcessExecute y debe poseer un atributo Export con un nombre que defina la clase y que será el nexo de unión entre el servicio de colas y el proceso de negocio. En nuestro caso lo llamaremos “HelloWorldProcess”. Si nuestro proceso necesitara liberar recursos podría heredar del interface IDisposable. Si el sistema de colas detecta este interface lo llamará.

[Export("HelloWorldProcess", typeof(IProcessExecute))]
public class HelloWorldProcess : ProcessExecute, IDisposable

Como comentamos anteriormente los procesos pueden recibir metadatos del fichero de configuración. Esta información es recibida a través del método GetConfiguration mediante un nodo xml. Utilizando mecanismos de ayuda como Util.GetValueOrDefault podemos obtener fácilmente la información del atributo xml. En nuestro caso “Param1”. Este método siempre debe devolver un objeto con la información del metadato. En nuestro caso a través de la clase MyConfiguration.

protected override MyConfiguration GetConfiguration(XmlNodeList configNodeList) {
    return new MyConfiguration() { Param1 = Util.GetValueOrDefault("Param1", () => configNodeList[0].Attributes["Param1"].Value, "Nothing", false) }
}

Por último deberemos definir lo que queremos hacer con el mensaje en-rutado. En nuestro caso mostraremos por consola tanto el canal por donde viene el mensaje como el mensaje enviado. También mostraremos el hilo que ejecuta el proceso para comprobar cómo se alterna entre los diferentes configurados

public override bool Execute(byte[] message) {
    Console.WriteLine("Nombre del canal por donde viene el mensaje: " + this.ConfigurationSection.Param1);
    Console.Write(". Mensaje a procesar por hola mundo:" + Serializer.Unserialize(message));
    Console.Write(". Hilo:" + System.Threading.Thread.CurrentThread.Name);
    System.Threading.Thread.Sleep(1000); // Simula que el proceso dura un segundo en ejecutarse
    return true; // Todo ha sido satisfactorio y quiero seguir procesando mensajes
}

Modulo: Simulador de cliente

Nombre: ClientSimulator
Nombre ensamblado (dll): ClientSimulator.dll
Clase: Program

Este módulo se encarga de enviar 50 mensajes a dos colas diferentes llamadas “Canal1” y “Canal2”. Este proceso es realizado utilizando la clase PublicationService. Deberemos indicar el nombre de la cola destino del mensaje y la cadena de conexión del servidor de colas. Una vez configurado los parámetros de conexión enviaremos el mensaje a través del método Publish.

PublicationService publication = new PublicationService(new QueueInfoEntity() { QueueName = channel }, new QueueProvider() { ConnectionString =  amqp://guest:guest@maquina" });

    for (int i = 0; i < 50; i++) {
        publication.Publish(String.Format("Mensaje para el canal: {0}. Número: {1}", channel, i.ToString()));
    }

Modulo: Host

Nombre: HostService
Nombre ensamblado (exe): HostService.exe
Nombre fichero de configuración: HostService.exe.config

Este módulo se encarga de gestionar los servicios del procesamiento de las colas. En la parte 4 de este blog podrá ver una descripción más detalle del ciclo de vida del servicio. En este punto lo que más nos interesa es ver la configuración personalizada que hemos realizado para el test. Como podemos ver en la figura de más abajo hemos definido una conexión al servicio de colas y dentro de esta conexión hemos definido dos canales para el procesamiento de mensajes. El primer canal llamado “Canal1” escucha una cola llamada también “Canal1” y trabaja con 2 hilos como máximo configurado por él parámetro WorkerThreadMax. Esto significa que el servicio reserva un pool de dos hilos para el procesamiento de los mensajes que vienen derivados a esta cola. El parámetro Process indicará el nombre del proceso a donde el servicio en-rutará el mensaje. Recordemos que debe coincidir con el nombre configurado por el atributo Export que ya vimos en el módulo “Proceso de negocio”. Este parámetro es muy importante porque es la forma que tiene el servicio de descubrir el proceso de negocio asociado al canal y por consiguiente en-rutar el mensaje. Por último se pueden especificar parámetros de configuración a través de un nodo xml, en este caso <MyConfiguration Param1=”Canal1”</MyConfiguration>. Con MyConfiguration enviamos el nombre del canal al proceso de negocio, que en nuestro caso lo imprimirá por consola.

No entraremos en la configuración del segundo canal porque es igual que el primero, la única diferencia es el nombre.
Otro aspecto importante es que el ensamblado del proceso de negocio debe estar ubicado en el directorio de trabajo llamado “BusinessProcess” donde se encuentra el host del servicio. El servicio escucha este directorio y descubre los procesos de negocio asociados a él.

En resumen y lo más importante que podemos apreciar es que el sistema permite múltiples conexiones, con múltiples canales a colas diferentes y la gestión de los procesos permite múltiples hilos de ejecución.

Resultados obtenidos

Ejecutamos el simulador de envío de mensajes y observamos que tenemos 50 mensajes por canal en el servidor de colas RabbitMQ, como podemos observar en la figura de más abajo

 Ilustración 2. Consola web de administración de colas del simulador


Lanzamos el servicio de colas y comprobamos la impresión de los diferentes mensajes por pantalla. Como podemos observar en la figura de abajo, los diferentes mensajes alojados en el servidor de colas fueron en-rutados al servicio y el servicio los envió a los diferentes procesos de negocio utilizando los diferentes hilos de trabajo configurados. En la información que nos proporciona la consola podemos ver tanto el número de mensaje que identifica el mensaje, como el nombre del canal por el que fue enviado y recepcionado, como el identificador de hilo que lo consumió. En ese último podemos comprobar que hay 4 identificador de hilos diferentes.