8.18.2014

Webcast Implementando SOA con el Windows Service Bus–Grabación

Para los que me consultaron, el link con el webcast del primer webcast es el siguiente: https://www149.livemeeting.com/cc/wwe_us/view.asx?scan=scanhff 

Lo pueden ver en línea o descargarlo

Etiquetas de Technorati:

8.13.2014

Windows Service Bus: Mejora del Mensaje

Una de las ventajas de los buses de servicio es que permiten mejorar los mensajes que pasan por el “middleware”. En los buses de integración como BizTalk Server se usan “mappers” los cuales a través de XSLT y otros elementos mejoran o convierten un mensaje. En el Windows Service Bus esto se logra a través de los tópicos y las acciones a partir de cada subscripción al tópico. En este post vamos a ver como mejorar un mensaje que ingresa al service bus usando un tópico.

Creación del Tópico

Lo primero que vamos a hacer es crear un tópico y agregarle 3 subscripciones tal y como se ve en la siguiente figura.

SNAGHTML2ea4d48

El primer tópico recibe todos los mensajes y por lo tanto no tiene ningún filtro especial ni ninguna acción especial sobre el mensaje.

SNAGHTML2f0e584

El segundo tópico si tiene un filtro particular y una acción para ese filtro. En este filtro vamos a recibir los mensajes que tengan en la propiedad país el código ´CRC´de Costa Rica y cuando el filtro se cumpla vamos a establecer la propiedad del mensaje código con el numero 506.

image

Algo similar llevaremos a cabo con el siguiente filtro, en el cual vamos a filtrar los mensajes con código de país PTY de Panamá y vamos a establecer el código con el numero 507.

image

Código de envío y recibo del mensaje

Ahora procedemos a enviar los mensajes a la cola del bus de servicios. Para esto creamos un nuevo mensaje y le agregamos el país y el código que luego se modificara se inicializa con el valor 0.

image

El siguiente paso es programar el recibo de mensajes de la subscripción donde llegan todos los mensajes y no tiene acción.

image

Ahora procedemos a programar el recibo de mensajes desde la subscripción con un filtro de código de país = a ‘CRC’.

image

Por ultimo, programamos el recibo de los mensajes que llegan a la subscripción de PTY.

image

El código del método desplegar mensaje es el siguiente:

image

Si ejecutamos la forma anterior, podemos ver que los mensajes se reciben de acuerdo a su destino y que el código de país se modifica como corresponde en la acción asociada al filtro.

image

Etiquetas de Technorati:

7.17.2014

Nueva serie de Webcast de arquitectura

Gracias al excelente recibimiento de la serie de webcast de arquitectura producida el año pasado se ha decidido hacer una nueva serie con temas relacionados y que están presentes en los temas a diario que enfrentamos arquitectos y desarrolladores. La nueva serie de webcast será en vivo igual que la anterior y los videos también serán hosteados en Channel9. Esta serie inicia el próximo 6 de agosto y a continuación pueden ver la información y le link de registro para el evento.

image

El link de registro para el evento es el siguiente:

Serie - Arquitectura de Software: Implementando SOA con el Windows Service Bus

Para los que desean información de los links del año anterior los pueden ver en channel 9 en esta dirección.

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.

4.05.2014

Que es AMQP?

“Advanced Message Queuing Protocol ” es un estándar abierto para enviar mensajes entre aplicaciones y/o organizaciones. Este estándar nos permite eliminar el “vendor lock” en lo que respecta a la creación de arquitecturas distribuidas ya que podemos utilizar cualquier intermediario y cambiarlo cuando así lo queramos sin tener necesidad de cambiar el código que escribimos para enviar o recibir los mensajes. Como es un estándar abierto, nos permite conectar aplicaciones que están en distintas plataformas sin necesidad de utilizar un intermediario que le ponga mucho overead a la transacción tal como un bus de servicios de integración en donde normalmente se tiene que enviar para ser procesado en XML y en el peor de los casos usando HTTP.

AMQP en la vida real

Aun sin existir el estándar para manejo de mensajes vías un servidor de colas, este tipo de servidores nos permiten crear aplicaciones distribuidas que nos ayudan a manejar altos volúmenes transaccionales donde no necesariamente alguna de las partes debe de estar disponible para que el envío del mensaje sea exitoso. Este tipo de modelos de operación se aplican de forma común sobre todo en sistemas que procesan transacciones tales como pagos, solicitudes de autorización, manejo de auditorias, etc.

Esta capa intermedia nos permite conectar aplicaciones entre si, dándonos la oportunidad de crear verdaderas aplicaciones distribuidas –> concepto que difiere mucho de tener librerías en un directorio virtual que aunque se podrían utilizar en otras aplicaciones no se hace, porque en realidad al estar en un directorio virtual, están siendo utilizadas de forma local.

Para conectarnos a un servidor AMQP utilizamos diversas librerías disponibles en el mercado, siendo una de las mas comunes Apache Qpid. Esta librería nos permite enviar y recibir mensajes utilizando el estándar AMQP desde cualquier lenguaje soportado y desde el cual se puedan utilizar las librerías; entre los lenguajes incluidos están Java –> JMS, javascript, C++, .NET –> WCF, phyton, Ruby, Perl y una seria de lenguajes que se van agregando a la misma. Igualmente existen otras librerías que nos permiten interactuar con servidores AMQP con otros lenguajes de programación. Es importante destacar que AMQP nos permite interactuar entre diversas plataformas mientras la plataforma se adapte al estándar.

Existen varios servidores que soportan el estándar AMQP, tales como Windows Service Bus, RabbitMQ, Oracle Open Queue, ZeroMQ, etc. Una ventaja con este estándar es que podemos cambiar el servidor sin necesidad de cambiar el código con el cual interactuamos con el servidor, esto nos permite tener una infraestructura distribuida sin estar “amarrado” a una marca en especifico.

Básicamente la forma en que AMQP funciona se puede visualizar en la siguiente figura. Un cliente A tiene una librería en su lenguaje de preferencia que le permite interactuar con un servidor utilizando AMQP; por lo tanto puede enviar mensajes al servidor AMQP. Desde el otro extremo hay otro cliente B que también soporta el estándar AMQP pero no necesariamente utilizan el mismo lenguaje de programación para consumir los mensajes y que puede interactuar con el cliente A sin importar desde que plataforma fue enviado el mensaje.

image

En próximos post vamos a ver como interactúan clientes en plataformas diferentes utilizando AMQP – .NET y Java.

Etiquetas de Technorati:

3.30.2014

Windows Service Bus + AMQP + Java – Parte 1

El Windows service bus no es soportado por el SDK de Java para Azure, solamente funciona con el bus de servicios en Azure. Sin embargo, para conectarnos usando ambientes de Java, tenemos un par de opciones: el API REST y AMQP. En este post vamos a iniciar el tutorial para lograr enviar y recibir mensajes a un bus de servicios corriendo localmente en Windows utilizando Java como lenguaje de programación y utilizando el estándar AMQP.

Exportar Certificados a las maquinas cliente

Java no utiliza el store de certificados de Windows –> es de esperar porque la solución debe de funcionar en todos los SO – sino que tiene su propio almacenamiento. Por lo tanto lo primero que debemos hacer es exportar el certificado SSL auto generado del Windows Service Bus.
El primer paso es abrir el power shell para el Windows Service Bus y ejecutar el comando Get-SBAutoGenerateCA.
image
Cuando ejecutamos este procedimiento se exportan en dos archivos el certificado de la autoridad certificadora y la lista de revocación. Si no especificamos el nombre del archivo, el cmdlet nos generara los archivos con el nombre AutoGeneratedCA.
image
El siguiente paso es verificar que la herramienta bin\keytool.exe existe, y que lib\security\cacerts existe. Este proceso se debe llevar a cabo desde la consola en modo administrador. Como podemos ver en la siguiente imagen, la herramienta keytool.exe si esta presente.
image
Igualmente cacerts también existe
image
Ahora procedemos a ejecutar el siguiente comando:
image
bin\keytool.exe –list –keystore lib\security\cacerts

Se nos va a pedir la contraseña del almacén de certificados de Java el cual por defecto es changeit. Esto nos muestra el total de certificados que se encuentran almacenados en el almacén de Java.

El siguiente paso es importar los certificados autogenerados por el bus de servicios ejecutando el siguiente comando desde la consola donde probamos el acceso al almacén de certificados de Java.

bin\keytool.exe –importcert –alias AppServerGeneratedSBCA –file %temp%\AutoGeneratedCA.cer –keystore lib\security\cacerts –v

La aplicación nos va a preguntar si confiamos en el certificado, le decimos que si y el certificado queda guardado en el almacén.

image

En el siguiente post vamos a crear el cliente Java para enviar un mensaje a una cola en el bus de servicios de Windows.

Etiquetas de Technorati: ,,

3.29.2014

Request–Response con el Windows Service Bus

El bus en su versión de Windows no tiene “relay service” disponible como si sucede en el bus de servicios de Azure, por lo tanto solo se soportan transacciones asíncronas. En este sentido solo tenemos como opción utilizar colas o tópicos ya que no podemos conectar servicios creados en WCF y hosteados en el IIS al Windows Service Bus para que sean atendidos en un patrón solicitud y respuesta.

Sin embargo, como bien lo definimos en el titulo de este post, si existe una forma de crear solitudes de dos vías en el Windows Service Bus y es utilizando correlación, sesiones y colas.

El Cliente

El primer paso es crear el cliente del servicio es decir, el que envía la solicitud. Para esto primero creamos variables para tener acceso a la cola de envío y a la cola de respuesta.

  1: var _requestQueue = QueueClient.CreateFromConnectionString(ServiceBusEndpoint, "RequestQueue");
  2: var _responseQueue = QueueClient.CreateFromConnectionString(ServiceBusEndpoint, "ResponseQueue", ReceiveMode.ReceiveAndDelete);

Luego creamos un while para presentar la consola hasta que el cliente digite una tecla que sea diferente a “n” o “N”, en cuyo caso el cliente nos estará diciendo que no quiere enviar mas mensajes.


Dentro de este While vamos a crear un Id de sesión único utilizando un Guid de sistema y procedemos a solicitar el numero de cliente que el usuario desea ingresar; por ultimo establecemos la sesión utilizando el id de sesión único que acabamos de generar.

  1: var _replyToSessionId = Guid.NewGuid().ToString();
  2: Console.WriteLine("Digite el numero de cliente: ");
  3: string _numeroDeCliente = Console.ReadLine();
  4: var _messageSession = _responseQueue.AcceptMessageSession(_replyToSessionId);
  5: 

El siguiente paso es crear el mensaje que vamos a enviar. Este contendrá el numero de cliente ingresado por el cliente, pero además tendrá el valor de la sesión y la propiedad ReplyToSessionId establecidos por el Id de sesión único creado anteriormente con el Guid del sistema. Después de esto enviamos el mensaje.

  1: var _mensaje = new BrokeredMessage(_numeroDeCliente)
  2: {
  3:     SessionId = _replyToSessionId,
  4:     ReplyToSessionId = _replyToSessionId,
  5:     MessageId = DateTime.Now.ToBinary().ToString()
  6: };
  7: _requestQueue.Send( _mensaje );
  8: Console.ForegroundColor = ConsoleColor.Cyan;
  9: Console.WriteLine("Mensaje enviado. Id Mensaje = " + _mensaje.MessageId);

Por ultimo esperamos la respuesta del mensaje y lo desplegamos en la consola.

  1: Console.ForegroundColor = ConsoleColor.Cyan;
  2: Console.WriteLine("Mensaje enviado. Id Mensaje = " + _mensaje.MessageId);
  3: 
  4: var _responseMessage = _messageSession.Receive(TimeSpan.FromSeconds(20));
  5: if (_responseMessage != null)
  6: {
  7:     Console.ForegroundColor = ConsoleColor.Green;
  8:     Console.WriteLine("Mensaje recibido: {0}. El nombre del cliente es {1}", _responseMessage.MessageId, _responseMessage.GetBody<string>());
  9: }

El Servidor


Seguidamente creamos el servidor que va a procesar la solicitud enviada por el cliente y va a responder a la instancia del cliente. El primer paso es crear dos colas, una hacia donde se envía la solicitud, y otra hacia donde se envía y se busca la respuesta a la solicitud.

  1:         private QueueClient _requestQueue;
  2:         private QueueClient _responseQueue;

Luego procedemos a crear el método que va a procesar la respuesta. Inicialmente se crea una sesión, luego de esto hacemos un ciclo “while” en donde nos quedamos esperando hasta que llegue un mensaje a la cola de recibo. Como se puede ver en el segundo while, nos quedamos esperando hasta que la variable _messageSession sea diferente de nulo; el estado de esta variable cambiara cuando la operación de solicitud de mensaje devuelva un mensaje recibido en la cola de solicitud _requestQueue.

  1: while (true)
  2: {
  3:   MessageSession _messageSession = null;
  4:   while (_messageSession == null)
  5:   {
  6:       try
  7:       {
  8:           Console.ForegroundColor = ConsoleColor.DarkMagenta;
  9:           Console.WriteLine("Aceptando la sesion del mensaje");
 10:           _messageSession = _requestQueue.AcceptMessageSession();
 11:           Console.WriteLine("Sesion aceptada");
 12:       }
 13:       catch (TimeoutException _e)
 14:       {
 15:           Trace.WriteLine(_e.ToString());
 16:           throw;
 17:       }
 18:   }


Una vez recibido el mensaje procedemos a procesarlo. El primer paso es extraerlo de la cola para que la instancia del mensaje desaparezca de los mensajes a procesar, esto se logra con la operación MessageSession.Receive. Seguidamente obtenemos el contenido del mensaje con la operacion GetBody y procedemos a imprimir lo recibido. Seguidamente procedemos a crear el mensaje de respuesta, para esto creamos un nuevo mensaje – BrokeredMessage –, le agregamos el nuevo contenido el cual es el mismo del anterior pero con el string “el nombre del cliente <mensaje anterior> es XYZ”. Este nuevo mensaje se responde con una particularidad, la variable SessionId es el valor de la variable ReplyToSessionId y el Id del mensaje sera el mismo que el Id del mensaje recibido, para lo cual usamos la propiedad MessageId de ambos mensajes.

  1:  Console.ForegroundColor = ConsoleColor.Yellow;
  2:     Console.WriteLine("Recibiendo mensajes de la session {0} ", _messageSession.SessionId);
  3:     Console.ForegroundColor = ConsoleColor.Green;
  4:     var _message = _messageSession.Receive(TimeSpan.FromSeconds(5));
  5:     if (_message != null)
  6:     {
  7:         var _numeroDeCliente = _message.GetBody<string>();
  8: 
  9:         Console.WriteLine("Cliente numero: {0}", _numeroDeCliente);
 10: 
 11:         var _nombreCliente = string.Format("El nombre del cliente : {0} es XYZ", _numeroDeCliente);
 12: 
 13:         var _responseMessage = new BrokeredMessage(_nombreCliente)
 14:         {
 15:             SessionId = _message.ReplyToSessionId,
 16:             MessageId = _message.MessageId
 17:         };
 18: 
 19:         _responseQueue.Send(_responseMessage);
 20:     } //fin del if
 21: } //fin de while

Para hacer la prueba primero ejecutamos el servidor que se queda esperando por mensajes.
image

Luego iniciamos el cliente que nos solicita la información del cliente a enviar.
image

Luego digitamos los datos del cliente y podemos ver que el servidor recibe la respuesta de forma inmediata. Al mismo tiempo nos despliega los datos digitados del cliente y procede a contestar.
image



En la siguiente pantalla vemos que el cliente envió ABC y que recibió la respuesta por parte del servidor con el mensaje de texto agregado de vuelta.


image


Etiquetas de Technorati:

3.12.2014

Conectar BizTalk Server a una cola en el Azure Service Bus – Parte 2

En el post anterior, conectamos un servidor BizTalk Server con una cola de servicios del Azure Service Bus. En este escenario movimos un mensaje que contiene un documento XML desde un folder hasta una cola llamada reportqueue en el bus de Azure . En este post vamos a completar el ciclo y vamos a obtener el mensaje directamente desde esta cola utilizando otra aplicación del servidor BizTalk.

Demo

En esta ocasión vamos a iniciar creando un receive location en donde configuramos el adaptador para que se conecte al bus de servicios para obtener los mensajes respectivos.

image

La configuración del adaptador es exactamente igual a la configuración del adaptador de envió configurado en el post anterior, tanto a nivel general como a nivel de autenticación.

image

Ahora asociamos la locación de recibo recién creada con el puerto de recibo.

image

El siguiente paso es configurar un send port para que estos mensajes que vienen de la cola del bus de servicios de Azure sean depositados en un folder de recibo en un archivo con un documento XML. Para esto procedemos a crear un puerto de una vía y configuramos la ruta en donde se va a guardar el archivo que contiene el mensaje obtenido.

image

Luego creamos un filtro en el puerto de envío para que recepcione los mensajes que ingresan a través del puerto que tiene configurado la locación de recibo que apunta al bus de servicios de Windows Azure.

image

Ahora cuando iniciamos la aplicación de BizTalk se consumen los mensajes de la cola y se guardan en el folder designado

image

El mensaje retornado contiene los datos tal y como fueron enviados en el post anterior.

image

3.09.2014

Conectar BizTalk Server a una cola en el Azure Service Bus – Parte 1

En una arquitectura Hibrida siempre vamos a tener componentes “on premises” y componentes en la nube. En este post vamos a conectar el bus de integración BizTalk Server con el Azure service bus.

Escenario

Normalmente en una arquitectura hibrida, los componentes que se dejan “on premises” son los que están relacionados con datos sensibles o los sistemas legacy que no se pueden correr o integrar directamente con los servicios o endpoints en la nube. Estos sistemas por lo general no tiene todas las características para integrarse a la nube o es muy complicado integrarlos de manera integrar (con transaccionabilidad, tolerancia, seguridad, etc.) a las buses que exponen los endpoints en la nube. En estos casos debemos usar un bus de integración para poder conectar estas aplicaciones con los endpoints a través de la nube. Cuando hablamos de endpoints hablamos de puntos de acceso para consumir servicios SOAP y REST ya sea directamente o través de aplicaciones utilizando servicios en la nube tales como los “mobile services” de azure.

Para este post vamos a imaginar una aplicación que la única interface al mundo exterior ( dentro de un mismo datacenter) que tiene disponible son archivos de texto. Esta aplicación graba un archivo de texto en un folder y espera la respuesta en otro archivo de texto en otro folder. Este archivo será tomado por BizTalk Server y enviado al bus de azure apenas la aplicaciones lo escriba. Seguidamente otro adaptador de BizTalk lo traerá de vuelta de la nube lo pondrá en el folder definido para la respuesta.

Demo

No vamos a hacer una aplicación que grabe un archivo en un folder, pero si vamos a definir un folder y vamos a poner un archivo en este folder para que BizTalk server lo consuma. Como se ve en la siguiente imagen, el adaptador define un uri de donde recoger los archivos para que BizTalk los procese.

image

Luego procedemos a configurar el puerto de envío. Lo primero que tenemos que hacer es crear el filtro para que el mensaje se pueda rutear desde el puerto de recibo al puerto de envío.

image

El siguiente paso es seleccionar el adaptador para el bus de servicios como se muestra en la siguiente figura.

image

Ahora procedemos a configurar el adaptador para que se pueda conectar al bus. El primero paso es establecer el uri de la cola que vamos a utilizar.

image

Luego procedemos a configurar la autenticación de la conexión a la cola del bus de servicios de azure. En primera instancia el uri del ACS lo tomamos del portal de de seguridad de Azure. Este portal lo podemos acceder del dialogo que nos presenta la clave y el usuario para conectarnos al namespace donde reside la cola. El detalle desde donde se toma la dirección de la autenticación se ve en la siguiente figura.

image

Ahora procedemos a configurar el adaptador en su parte de autenticación. El owner y el issuer key son los mismos que usamos para consumir la cola desde las aplicaciones que normalmente desarrollamos y que se comunican con el el Azure Service Bus.

image

Listo!!! si ponemos un archivo en el folder especificado, veremos que el mensaje llega a la cola en el bus de servicios de Azure – en este caso podemos ver que hay un mensaje en la cola llamada queuereportes.

SNAGHTML1d460a9

En el siguiente post vamos a configurar el adaptador de recibo de mensajes de BizTalk Server para el Azure Service Bus para ir a obtener el mensaje enviado anteriormente.

Etiquetas de Technorati: ,,,