1- Sistemas de Mensajería
Los patrones a describir dentro de esta sección son los pilares de la infraestructura de integración y el propósito de describir algunos aquí es asociarlos a la implementación en Biztalk Server.
1.a) Message Channel
Existe una integración entre dos aplicaciones que necesitan comunicarse y está implementado por mensajería.
¿Cómo una aplicación se comunica con la otra utilizando mensajería?
Se conectan las aplicaciones utilizando un Message Channel donde una aplicación envía información al canal y otra lee información del canal.
Las aplicaciones no envían simplemente mensajes al sistema de mensajería de manera descoordinada mientras otras aplicaciones reciben todos los mensajes de manera aleatoria, esto sería una forma muy ineficiente de operar. De esta manera, las aplicaciones que envían información saben qué tipo de información es y las aplicaciones que reciben, también saben qué tipo de información van a buscar.
Cuando una aplicación envía un mensaje no lo envía directamente al sistema de mensajería sino que lo hace en un Message Channel particular, de la misma manera, la aplicación que recibe un mensaje lo recibe de un Message Channel particular.
La aplicación que envía no tiene por qué saber qué aplicación recibirá la información pero se asegura por el sistema de mensajería, que la aplicación que lo recibe está interesada en la información.
Implementación en Biztalk Server
Los puntos de conexión de las aplicaciones con Biztalk Server son los puertos. En particular para la definición de un Message Channel como un punto de conexión “lógico” cuya implementación depende de la instalación, es lo más cercano al mismo.
En lo que hace a la definición de lo que son puertos “físicos” de Biztalk (que podemos ver y definir en la interfaz de administración como se ve encima) en el caso de los “Receive Ports” que no definen el Channel Adapter la definición es clara, pues solamente se especifica un punto de entrada que luego puede conectarse de diferentes maneras e incluso con diferentes y varios adaptadores. En el caso de los Send Ports definidos, esta línea es más borrosa pues en el mismo puerto debe definirse el adaptador.
En la interfaz de la orquestación, tenemos acceso a definir “puertos lógicos” sin especificar su implementación física.
Estos puertos luego podrán ser “conectados” (binding) a puertos físicos, y son la implementación estricta de lo que sería un Message Channel. En la ilustración encima tenemos en los Port Surface dos puertos lógicos (Message Channels) de una orquestación que recibirá mensajes de una aplicación y lo enviará a otra/s aplicaciones interesadas en los mismos.
Un acercamiento adicional, los Send Port Groups como Message Channel
Conversando con mi amigo Cristofer luego de publicar este post, me refirió a la inclusión de la orquestación como innecesaria para ilustrar el concepto del Message Channel en Biztalk.
Entendiendo su concern con respecto al tema, no solamente por la realidad de poder explicarlo de otra manera sino por la peligrosidad de asociar un concepto a una implementación en orquestaciones, cuando normalmente favorecemos procesamiento “sin orquestación” en todos los casos en que es posible y no incorporamos lógica de negocios por la mayor velocidad y escalabilidad que logramos en las soluciones.
Así es que, sin quitar lo que hemos visto hasta ahora, puedo explicitar algunos temas que hacen más compleja la visión pero la acercan a la implementación concreta.
En primer lugar, los puertos que hemos visto en el diseñador de orquestaciones, tienen la capacidad de poder ser lógicos y luego ser conectados a puertos físicos, con lo que serían fieles a la descripción que hemos hecho de Message Channel sin embargo, existe la posibilidad de indicar físicamente los puertos en la creación en la propia herramienta, esto hará que en el momento de la publicación se creen, pero igualmente la separación entre el Message Channel y el Channel Adapter se rompe para beneficiar la conveniencia del que está configurando la solución, pero es un escenario que quería evitar y por eso incluí la orquestación y, en rigor, también podría dejarla fuera.
En cuanto a los Send Port Groups, en BizTalk el Send Port Group es una unidad lógica que permite agrupar diferentes Send Port de manera que en la configuración de la solución, el uso de un “Send Port Group” nos acercaría a la definición más ajustada del Message Channel para la salida, dado que no contiene más que la información necesaria para que la aplicación envíe el mensaje en este “Send Port Group” sin necesidad de informar el Channel Adapter que conectará a la aplicación destino.
Si bien esto complementa y permite explicar el patrón sin utilizar orquestaciones, continúo dejando el otro ejemplo pues el uso del Send Port Group es opcional y no mandatorio. El problema principal radica en que la implementación de los puertos de salida con respecto a los puertos de entrada en BizTalk no es simétrica, el uso opcional y la no inclusión de mapas en el Send Port Group y si en el Receive Port son solamente un par. Yo desearía que la implementación hubiera sido simétrica pero me imagino (o quiero imaginar 
) que existe una buena razón para que así sea.
