Angel "Java" Lopez

Ayer comencé a codificar SharpBus, un simple procesador de mensajes inspirado en algunas ideas de Mule. Ver:

http://en.wikipedia.org/wiki/Mule_(software)

http://www.mulesoft.org/what-mule-esb

Como es usual, estoy usando TDD (Test-Driven Development), tratando de ir implementando pequeños casos de uso, de la manera más simple posible. De hecho, el proyecto es un ejercicio personal de TDD. Espero que alguna vez sea útil más allá de eso. Por ahora, es un ejemplo que quiero compartir de mi flujo de trabajo.

Pueden ver el avance en:

https://github.com/ajlopez/SharpBus

Las ideas principales a implementar son:

– Hay mensajes (Message) con un contenido (Payload) y propiedades (diccionario de nombre/valor)

– Hay flujos (Flow) que procesan mensajes

– Un flujo se compone de varios elementos

Los elementos pueden encadenarse en el flujo, y pueden ser:

– Un transformador (Transformer) que toma un contenido o mensaje completo y lo devuelve transformado

– Un procesador (Processor) que toma un contenido o mensaje completo y opera sobre él, por ejemplo, tomando acciones sobre algún dominio de negocio, pero sin transformarlo

– Un productor de mensajes/contenido (Input)

– Un consumidor de mensajes/contenido (Output)

– Un ruteador (Router) de mensaje/contenido, quien decide a qué próxima rama (Branch) en el flujo se deriva el mensaje/contenido

Y un flujo puede tener ramas con nombre. También habrá elementos que puedan emitir nuevos mensajes aparte del actual, y que puedan emitirlos a distintos flujos del sistema. Los productores de mensajes deberán poder correr en hilos de ejecución (Threads), en principio. Y habrá un conjunto de hilos (Pool de Threads) para atender los mensajes que se produzcan y derivarlos a los respectivos flujos.

Un flujo puede tomar un mensaje, y devolver una respuesta (un Request/Response), o puede tomar un mensaje, procesarlo, sin devolver una respuesta a quien lo envió.

A veces, un elemento necesitará el mensaje completo (Message) y otras veces le bastará operar sobre el contenido (Payload).

Los elementos, en el mundo de Mule/Java, son objetos. Notablemente, en C#, la forma más simple de implementar, es usando lambdas. Así, que siguiendo TDD, las primeras pruebas e implementación ha salido por ese lado. Pueden ver algunos tests simples en:

https://github.com/ajlopez/SharpBus/blob/master/Src/SharpBus.Core.Tests/FlowTests.cs

Por ejemplo, para enviar un contenido y recibir respuesta, en un flujo que está vacío, basta:

var flow = Flow.Create();

Assert.AreEqual(1, flow.Send(1));

Para enviar un contenido y transformarlo, es simple:

var flow = Flow.Create()
    .Transform(x => ((int)x) + 1);

Assert.AreEqual(2, flow.Send(1));

El .Transform espera una Func<object, object> que puede proveerse en el momento con una lambda. En un Mule clásico de Java 7, tendríamos que proveer un objeto que implemente una interface donde hay un método que transformar el Payload. Tengo que pensar si vale la pena tener un .Transform tipado tipo .Transform<T> (que recibe T y devuelve T), o .Transform<T, S> (que recibe T y devuelve S).

Vean que me decidí por configurar el flujo por código. En el ambiente Mule se acostumbra más configurarlo por Spring, escribiendo un XML. Me parece que es hora de explorar esta otra forma, y ponerla como “forma primera”, es decir, como la forma sobre la que todo lo demás se podría montar. Si alguien necesitara alguna vez un DSL (Domain-Specific Language) de creación de flujos, podría implementarse teniendo esta forma por código bien diseñada.

Siguiendo TDD, todavía no tengo un caso de uso de un Message (un mensaje completo, con contenido (Payload) y propiedades (Properties, un diccionario nombre/valor). Todo lo de arriba es procesar el Payload directamente.

Próximos temas: agregar Message con Payload, la salida de mensajes, el ruteo, el armado de ramas, etc..

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez