5.14.2014

BizTalk Hosts y Host Instances

Uno de los términos que mas confunde dentro del vocabulario utilizado a la hora de utilizar BizTalk Server es el concepto de Host y su relación y diferencia con el concepto del Host Instance. En este post vamos a definir que es cada uno de ellos y cual es su función dentro de BizTalk Server.

BizTalk Host

Un grupo de BizTalk puede tener muchos host. Los Host son contenedores lógicos donde varias tareas de BizTalk Server pueden ser asignadas. Existen dos tipos de Host:

  • Isolated Host
  • In-Process Host

El host de tipo in-process es utilizado por la mayoría de las tareas de BizTalk Server y esto quiere decir que todas las tareas a ejecutar, se van a llevar a cabo dentro del mismo proceso de BizTalk –> es decir, el mismo proceso de Windows asignado para BizTalk Server. Por otra parte, el Isolated Host va a llevar a cabo su trabajo por medio de otro proceso; por ejemplo, IIS. Cuando el IIS recibe un mensaje, el host de IIS utiliza los módulos de BizTalk Server y procesa el mensaje siguiendo los mismos pasos que cuando se utiliza un “Host in-process”; es decir, pasando por el adaptador, el pipeline y llegando al “Message Box”.

Los Isolated Host disponibles por defecto en la instalación del BizTalk Server son los siguientes:

  • HTTP Receive
  • SOAP Receive
  • WCF-BasicHttp Receive
  • WCF-CustomIsolated Receive
  • WCF-WSHttp

Estos adaptadores reciben los mensajes a través del IIS y no a través de un servicio de Windows. Cada host debe tener al menos un “host instance” ejecutándose.  Un host instance del tipo “in process” no es mas que un servicio Windows ejecutándose en uno o mas servidores BizTalk y llevando a cabo las tareas asignadas al host.

Cuando se crea un “host instance” se crea tanto en el servidor de BizTalk y en las bases de datos de datos de BizTalk Server.

Etiquetas de Technorati: ,,

5.01.2014

AMQP 1.0 se convierte en estándar internacional

En los últimos meses he tenido la oportunidad de trabajar en proyectos usando el protocolo AMQP el cual como explique en un post anterior tiene una serie de ventajas a la hora de desarrollar aplicaciones distribuidas. Sin embargo, el día de hoy me encontré con esta noticia la cual creo que es de sumo interés para los desarrolladores que nos dedicamos al tema de arquitectura y capa media – middleware.

Hoy se anuncio por parte de OASIS, ISO y IEC que el protocolo AMQP se ha convertido en un estándar internacional. Este anuncio es un gran paso para lograr estandarizar la forma en que comunicamos aplicaciones dispares usando métodos asíncronos o broadcasting de transacciones, ya que nos da la posibilidad de crear capas medias estandarizas en donde podemos cambiar  de componente intermedio (servidor de colas o tópicos) y nuestras aplicaciones solamente tendrían que cambiar la forma en que se comunican con el componente, dejando el consumo de mensajes intacto.

RabbitMQ, Azure Service Bus, Windows Service Bus y otras marcas de componentes del mercado ya soportan este estándar de manera natural por lo que los insto a utilizarlo para crear capas medias eficientes y estandarizadas, en donde el lenguaje de programación no incide en el comportamiento de la aplicación.

Igualmente, el grupo de Apache Qpid tiene en su roadmap soportar clientes en diversas tecnologías tales como php, Ruby y C, además de las ya soportadas.

Esperamos mucha evolución positiva en estos temas en los próximos meses.