Últimamente he estado involucrado en un proyecto, que por qué no decirlo, de los que más orgulloso me siento arquitecturalmente hablando. El sistema funcionalmente no era demasiado complejo, básicamente consistía en captar una colección de noticias, tratarlas, clasificarlas y publicarlas en diferentes portales de difusión pública.

El kit de la cuestión y de ahí mi satisfacción por el resultado, se debe a la modularidad, extensibilidad y flexibilidad a cualquier tipo de cosa involucrada en el proceso, del que se tenía que dotar al sistema. Si alguno de vosotros ha tenido la oportunidad de trabajar en algo relacionado con “Telco y media” sabrá de qué estoy hablando, porque ….. Si hay algo que está totalmente des-normalizado, y espero no herir a nadie un poco caótico, es el mundo de las noticias. (Aunque entiendo que es normal, ser el primero en proporcionar una noticia para ganar a tus competidores no es cosa fácil).

El principal problema aparece con la diversidad de formatos de entrada con los que te encuentras, no solo en cuanto a tipo de mensajes a tratar sino en contenido de los mismos. De manera que cada tipo de noticia (Feed para los entendidos) desemboca en un procesamiento diferente con un mayor o menor número de tareas.

Por resumir, la cadena de tareas más común a realizar podría reflejarse este diagrama:

Al tratarse de tareas encadenadas no cabe duda, en terminología BizTalk, que es necesario hacer uso de Pipelines, pero sería una locura tener que crear un pipeline por cada tipo de noticia y gestionar por tanto cientos de Receive Locations para poder asignar estos pipelines.

¿Cómo lo evitamos?

Creando una colección de “Custom Component Pipelies” base encargados, de en función del resultado de la ejecución de una serie de reglas de negocio, ejecutar los componentes que realmente realizan el proceso de la tarea en cuestión de forma dinámica.

 Los componentes base por tanto tienen como misión el funcionamiento del proceso de ejecución de mensajes de BizTalk, la ejecución de las políticas de reglas asociadas a la tarea involucrada en el proceso, y la instanciación y ejecución de los componentes de segundo nivel que como decíamos son los verdaderamente encargados del tratamiento de las noticias.

Los componentes de segundo nivel no tienen por qué tener ningún conocimiento de la infraestructura BizTalk, ni del resto de componentes de la arquitectura, solo se encargan de tareas simples como:

• - Transformación al formato estándar NewsML
• - Gestión de recursos (Fotos, videos, gráficos, etc.) de las noticias
• - Tratamiento de dichos recursos (Calidad e imagen)
• - Edición de los textos de las noticias
• - Clasificación de las noticias para su posterior publicación en los portales de difusión
• - Y un largo etc.

Como resultado de la arquitectura tenemos un BizTalk Pipeline capaz de ejecutar diferentes procesos para tratamiento de noticias en el que simplemente instalando nuevos assemblies a la GAC y modificando la política de reglas somos capaces de gestionar un mayor tipo de noticias o incluso realizar diferentes acciones para un tipo de noticia dado.