Hace un tiempo que no escribo sobre Biztalk, la verdad que a propósito, dado que las señales sobre la continuidad eran, por decirlo de alguna manera: “confusas”.
Pero bueno, sin una opción diferente para un gran conjunto de escenarios para cubrir con la plataforma y la versión 2010 ya en Beta, estoy armando una presentación para el próximo 26 de Agosto Ver aquí
Y para que no quede simplemente en la presentación, y luego de buscar material, pensé que era importante y valía la pena volver al blog con el tema de la presentación, de manera de forzarme a ser ordenado y metódico en la preparación.
Motivación
El libro referente sobre patrones de integración es Enterprise Integration Patterns pero el mismo hace referencia a los patrones genéricamente y sin experiencia suficiente, a veces se hace difícil distinguir los mismos en un producto como Biztalk Server.
De esta manera, vale la pena repasar algunos de los patrones más relevantes y cómo ellos ya se encuentran implementados en Biztalk Server o cómo pueden implementarse fácilmente.
Aviso importante
Éste y los siguientes blogs acerca del tema no pretenden presentar nuevos conceptos, de hecho gran parte de los mismos estarán referenciados aquí en español simplemente como manera de asegurar que el vocabulario a utilizar sea homogéneo y signifique lo mismo para todos los que interactuemos.
El valor que pretendo agregar es que sobre un vocabulario “conocido y aceptado”(tanto en lo básico como en los patrones de integración) construyamos ejemplos en Biztalk Server que nos ayuden en futuras implementaciones de integración.
Otra aclaración super pertinente es que la presente serie de publicaciones, solamente considera la funcionalidad de BizTalk server sin considerar la funcionalidad que agrega el Biztalk ESB Toolkit. Existen patrones que podrían asociarse más claramente utilizando esa funcionalidad e, inclusive, algunos patrones que solamente es interesante explicarlos utilizando su funcionalidad, por lo que quizá quede para otra serie de patrones a analizar y la revisión de los que en esta serie haga.
Estilo de Integración
Existen varias formas de acercarse a los problemas de integración que, considerando ciertas características se resumen en estilos. En particular, el estilo de integración que nos interesa cuando hablamos de Biztalk Server es el estilo de Mensajería.
El estilo de integración basado en Mensajería, nos permite integrar múltiples aplicaciones intercambiando paquetes de datos de manera frecuente, inmediata, de manera confiable y asincrónicamente usando formatos personalizables.
El asincronismo de la mensajería es un resultado lógico de integrar sistemas distribuidos, dado que enviar un mensaje no requiere que los dos sistemas conectados estén disponibles en el mismo momento. Además, ver la comunicación de manera asincrónica, fuerza a reconocer que la interacción con un sistema remoto es más lenta y que es mejor diseñar componentes con una alta cohesión y bajo acoplamiento.
Conceptos básicos de mensajería
Para poder avanzar en los patrones, debemos concordar en la semántica de los conceptos básicos que estaremos utilizando.
Channels (Canales)– Las aplicaciones de mensajería transmiten datos sobre un Message Channel una tubería virtual que conecta al que envía con el que recibe.
Messages (Mensajes) – Un Mensaje es un paquete de datos que puede ser transmitido en un canal. La aplicación que envía debe empaquetar cada paquete de datos en un mensaje y enviar el mensaje en un canal. La aplicación que receptora recibe un mensaje y debe extraer los datos del mensaje para procesarlos. El sistema de mensajería se encarga de entregar el mensaje que recibe del que envía al que recibe.
Multi-step delivery (Envío de múltiples pasos) – En el caso más simple, el sistema de mensajería entrega el mensaje directamente del que envía al que recibe. Sin embargo, muchas veces es necesario realizar acciones luego que el mensaje ha sido enviado por el origen pero antes que sea recibido por el destino final. Por ejemplo, el mensaje puede tener que ser validado o transformado. La arquitectura de Pipes and Filters describe como un procesamiento en pasos puede ser encadenado usando channels (canales).
Routing (Ruteo) – En muchas organizaciones, un mensaje debe pasar por varios canales antes de llegar a su destino final. La ruta que un mensaje debe seguir puede ser tan compleja que el que envía originalmente el mensaje puede no conocer el canal por el cual el mensaje llegará al receptor final. En su lugar, el origen inicial envía el mensaje a un Message Router que es un componente de aplicación y filtro en la arquitecturaq de Pipes and Filters que determina como enviar el mensaje al receptor final..
Transformation (Transformación) Varias aplicaciones pueden necesitar diferentes representaciones para los mismos datos. El que envía da un formato al mensaje, aunque el destino puede esperar el mensaje en otro formato. Para ajustar estas diferencias, el mensaje debe ir por un Message Translator que convierta el mensaje de un formato a otro.
