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: ,,,

2.23.2014

Los protocolos de SQL Server y BizTalk Server

Existen varios escenarios en donde el uso del protocolo de memoria compartida de SQL Server podría causar impacto en el desempeño de BizTalk Server. Un ejemplo típico es el acceso al SQL Server por parte de usuarios o clientes desde la misma maquina en donde reside el SQL Server. Para solucionar este posible problema se recomienda el uso de los protocolos “Named Pipes” y TCP/IP, además de deshabilitar el protocolo de memoria compartida.

Para realizar este cambio primero procedemos abriendo el SQL Server Configuration Manager

image

Seguidamente buscamos la opción SQL Server Network Configuration y en los protocolos para MSSQLSERVER habilitamos los “Named Pipes” y TCP/IP y deshabilitamos el protocolo de memoria compartida “Shared Memory” tal y como se ve en la siguiente figura.

image

Para que los cambios tengan efecto, debemos reiniciar el servicio de SQL Server.

Etiquetas de Technorati: ,,

1.02.2014

Configurando el portal de Azure localmente con el Windows Service Bus–parte 2

Continuando con el post anterior, vamos a configurar el servicio del bus de servicios a través del portal para que los usuarios puedan administrar sus objetos del bus directamente desde el portal.

Configurando el aprovisionamiento del service bus

Una vez configurado el service bus en el portal del Azure Pack, procedemos a crear los planes de forma tal que los usuarios del mismo puedan administrarlo directamente desde el portal. Para iniciar vamos al portal del Azure pack y seleccionamos planes, en esa opción seleccionamos crear plan.

image

Seguidamente procedemos a crear el plan y el primer paso es ponerle un nombre descriptivo al mismo.

image

Seguidamente seleccionamos los servicios que serán parte del plan, como se ve en la siguiente pantalla, seleccionamos service bus y el service bus recién agregado.

image

En la ultima pantalla procedemos con la finalización de la configuración del servicio.

image

Una vez creado el plan, este aparece en la consola del portal.

image

El siguiente paso es asegurarnos que el numero de conexiones en el sitio sea ilimitado.

image

Como podemos ver en la siguiente figura, el plan esta configurado y el sitio de estadísticas listo para recabar información de uso.

image

Una vez creado el plan, ahora se procede a asociar los inquilinos del servicio con el plan. Con esta asociación los inquilinos pueden asociarse al portal y solicitar nuevos planes, o interactuar con el service bus haciendo tareas como crear colas, suscripciones, namespaces, etc.

Para que los inquilinos puedan acceder al service bus configurado en la nube privada, debemos crear una cuenta para el usuario que va a proceder con su uso. Para eso vamos a la opción de cuentas de usuario y seleccionamos crear un nuevo usuario.

image

Agregamos los datos solicitados, asociamos el nuevo usuario al plan del service bus, y procedemos a crearlo.

image

El siguiente paso es verificar si el usuario se creo correctamente y si se asocio al plan que estábamos configurando, para esto procedemos dando clic al usuario en el portal y viendo los detalles del mismo verificamos si el usuario esta activo y si tiene asociado el plan.

image

Ahora procedemos a ingresar al sitio de inquilinos con el nuevo usuario creado. Para esto vamos a la dirección https://drojasmwin8:30081/ y procedemos a digitar las credenciales creadas.

image

Una vez ingresados al sitio web, podemos ver que el usuario inquilino tiene permisos para manipular el bus de servicios del plan (o la instancia que le corresponde). Inicialmente podemos crear un namespace y dentro del namespace podemos crear colas y tópicos.

image

Si ingresamos al namespace vemos que ya tenemos las opciones de creación antes mencionadas.

image

El resultado de dicha acción es la creación de una cola de mensajes en el service bus.

image

Para conectarnos al bus, podemos usar la cadena de conexión que nos brinda directamente el namespace del bus de servicios.

image

Incluso podemos acceder a la cola desde el Service bus Explorer (con la versión compatible con el Windows Service bus)

image

El resultado final de la conexión se ve en la siguiente figura.

image

12.30.2013

Configurando el portal de Azure localmente con el Windows Service Bus

Todos hemos escuchado alguna vez de las ofertas de nubes publicas las cuales van desde Amazon Web Services hasta Windows Azure. Sin embargo, por diversas razones que van desde seguridad, regulaciones legales y hasta poco conocimiento del tema por parte del equipo de TI de la empresa, siempre se ha buscado de alguna forma tener las ventajas de la nube publica pero de forma privada. Aunque hay muchas definiciones de lo que es una nube privada podríamos decir que es una infraestructura dedicada al uso de una organización, la cual puede ser administrada y operada por la organización, por un tercero o por una combinación de ambos; igualmente la organización puede ser dueña de la infraestructura o un tercero puede ser el propietario de la misma.

Para poder tener una nube privada con tecnologías de Windows Azure, Microsoft ha liberado el Windows Azure pack, el cual nos permite tener servicios que son consistentes con la oferta publica de Azure.

En este post vamos a instalar el Windows Azure Pack localmente y vamos a configurarlo con el Windows Service Bus.

Instalación

Para instalar el Windows Azure Pack se procede desde el Web Platform Installer; en este escogemos la opción Windows Azure y ahí seleccionamos el Windows Azure Pack y API Express. Esta es la opción mas simple para llevar a cabo la instalación.

image

Una vez instalado ingresamos al sitio web de configuración del portal, el cual nos dará una alerta de seguridad por un tema de un certificado digital vencido pero que no representa ningún peligro, por lo que procedemos a ingresar al sitio.

image

Ya en el portal de configuración procedemos a configurar el portal indicando el servidor de base de datos donde se hará todo el proceso, el usuario y la frase que se utiliza para agregar mas maquinas a esta instalación.

image

Una vez finalizada la configuración procedemos a ingresar al portal de Azure Management Pack, en donde se ven todas las opciones que tenemos de configuración. Como se ve en la siguiente figura, la dirección es el nombre de la maquina apuntando al puerto 30091 por defecto.

image

Ahora procedemos a agregar nuestro Windows Service Bus local instalado previamente – ver post anteriores – al portal de administración recién instalado. Para esto seleccionamos la opción agregar después de haber seleccionado Service Bus en la barra de la izquierda.

image

Seguidamente se nos solicita la información de la instancia del bus a la que nos queremos conectar. Le ponemos un nombre descriptivo a la conexión, luego ponemos el endpoint del service bus ( stsEndpoint ) y seguidamente el usuario administrador y el usuario inquilino.

image

Una nota aparte acerca de los usuarios a ingresar en esta parte del proceso. Estos usuarios son creados cuando se configura la instancia del service bus y se le indica que este bus será administrado por el portal del management pack. En la siguiente figura se puede ver el momento en donde se crean estos dos usuarios.

image 

Una vez puestos correctamente los datos procedemos a conectarnos al bus configurado. Si el resultado es exitoso procederemos a ver el bus en el portal que acabamos de configurar.

image

Si le damos click a la instancia del bus, podemos ver mas información de la instancia que se esta ejecutando como por ejemplo cuantos nodos están conectados, la información de la base de datos del service bus y como esta configurado el service bus.

image

En este post vimos como configurar el portal de Azure Pack de manera local y agregamos una instancia del service bus de forma local. Hasta aquí el bus todavía no esta 100% administrado desde el portal, por lo que en el próximo post vamos a crear un plan y vamos a establecer las opciones necesarias para administrar completamente el service bus desde el portal del Windows Azure Management Pack.