Los invito al webcast de mañana acerca del Azure Service Bus. En este webcast vamos a presentar como sacarle provecho al service bus en azure, interacción con Java, node.js, relay services y event hub. Además veremos AMQP. Este es el segundo webcast de una serie de 10. El link de registro se los dejo a continuación:
Regístrate en el webcast "Implementando SOA con Azure Service Bus" y aprende a crear middleware. http://bit.ly/1lxLzfd
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.
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.
Continuando con esta serie de posts respecto a la integración de componentes de Azure con el componente Google Charts, vamos a ver de forma rápida que son los objetos Table de Windows Azure. Estos componentes los vamos a utilizar como fuente de datos para pintar nuestros gráficos con Google Charts.
Las tablas en azure son objetos capaces de almacenar grandes cantidades de datos sin necesidad de definir todos los detalles que se definen cuando se trabaja con una base de datos relacional.
Estas tablas almacenan los datos en colecciones de entidades. Las entidades son como filas de una tabla relacional. Esta entidad tiene una llave primaria y una lista de propiedades. Las propiedades al igual que en .NET y al igual que una columna en una base de datos relacional consiste en un nombre y un valor - es decir un value-pair tipificado. Estas tablas no fuerzan ningún esquema de datos, por lo que pueden existir entidades con formatos diferentes dentro de la misma tabla → similar a MongoDB o RavenDB → si se desea forzar un esquema, debe de hacerse desde el lado del cliente.
Existen una serie de requisitos para ponerle nombre a una tabla, los cuales se detallan a continuación:
Las propiedades son también “case sensitive” y pueden tener un máximo de 255 caracteres → siguen las mismas reglas que los identificadores de C#.
Todas las tablas tienen tres propiedades en común con propósitos diferentes:
En este post vamos a trabajar con las tablas de Azure utilizando Node.js y Cloud9 como IDE de desarrollo. Inicialmente vamos a crear una tabla y vamos a interactuar con ella ingresando datos, modificándolos y consultándolos. Para iniciar, procedemos creando una tabla.
Para crear una tabla en Azure, necesito una cuenta en Windows Azure para tal propósito → fuera del alcance del post. Una vez creada esta cuenta procedemos a crear la tabla con la que vamos a trabajar utilizando el nombre de la cuenta y la llave generada para dicha cuenta. Esta información se obtiene desde el sitio de Windows Azure tal y como se puede ver en la siguiente figura.
Con esta información ya podemos iniciar con la programación para el acceso al servicio de las tablas de Azure. Como se ve en la siguiente figura, primero cargamos la librería del SDK de Azure, seguidamente en el paso 2 procedemos a ingresar el nombre de la cuenta del storage que vamos a utilizar y el respectivo key para su acceso → recortado en este caso para que quepa en el documento (y cambiado apenas se publique este post :) ). Por último creamos el servicio para acceder las tablas que existen en nuestra cuenta.
El siguiente paso es crear la tabla que vamos a utilizar, la cual en este caso se llamará “IncidentsTable” y en la cual vamos a guardar todos los incidentes generados a través de diferentes dispositivos y los cuales serán graficados utilizando Google Charts.
Creamos la tabla con el método createTableIfNotExists, si la tabla existe o se produce algún error → de nombre por ejemplo → entonces se despliega el error en la consola, en caso contrario se consultan todas las tablas disponibles dentro de la cuenta y las desplegamos.
En este caso yo tengo varias tablas en la cuenta, por lo que se reflejan en la consulta; sin embargo, en el objeto señalado por la flecha, se puede ver la tabla que creamos.
El siguiente paso es agregarle entidades a la tabla. Para esto vamos a usar el código que se muestra en la siguiente figura.
Vamos a insertar la entidad en la tabla ‘IncidentsTable’ utilizando el método insertEntity. En este método definimos el ‘PartitionKey’ y el ‘RowKey’ específico para la entidad → en este caso no vamos a agregar datos referentes al demo porque el registro lo vamos a borrar para demostrar esta funcionalidad. En el paso dos hemos creado una consulta para utilizarla en el paso tres del código, este query consulta todos los elementos que existen en la tabla definida por la variable ‘tableName’ .En el paso tres de la figura anterior también hacemos una consulta para obtener las entidades que existen dentro de la base de datos.
Si queremos borrar la entidad anterior procedemos con el siguiente código; el resultado de la consulta al borrar la entidad debe de ser []; es decir, un arreglo vacío de entidades.
Ahora procedemos a guardar los registros de incidentes que vamos a graficar desde Google Charts. El código final para ingresar las entidades es el siguiente:
Como se ve en la figura anterior, se agregan dos propiedades más a la entidad: IncidentType y Description, ambos del tipo String. Cuanto ejecutamos el código anterior, se despliegan los registros en la tabla hasta ahora insertados.
En el próximo post vamos a “ligar” los registros en nuestras tablas de Azure con una página que contiene el componente de Google Charts.
En el proceso de desarrollo de aplicaciones, los que nos dedicamos a esto pasamos constantemente por proyectos o escenarios donde debemos seleccionar cual es la tecnología que mejor aplica para el problema que queremos desarrollar. En un proyecto en donde me tocó trabajar recientemente, tuve que integrar Azure con Google Charts y luego de la experiencia - muy positiva por cierto - decidí crear una serie de post para mostrar cómo interactuar con los componentes de creación de gráficos de Google. Para iniciar, primero voy a hacer un post relacionado con el tema de Google Charts, después de lo cual voy a crear otros posts para integrarlos con componentes de Windows Azure.
Google Charts es un conjunto de módulos escritos en Javascript que nos permiten graficar de forma sencilla y rápida → y con un excelente desempeño. La librería soporta más de 20 tipos de gráficos y crece día con día. El link donde se encuentra toda la información de esta librería se puede localizar acá.
La librería es muy sencilla de usar solamente hay que manera los conceptos típicos de cualquier suite para creación de gráficos y entender muy bien como se usan las fuentes de datos. Básicamente existen tres componentes que interactúan para que los gráficos se puedan presentar en una página Web. En primer lugar la fuente de datos, seguidamente procedemos con la carga de los datos a una clase js DataTable, desde la cual pintamos los datos en los diferentes charts que vamos a presentar en nuestra página. La siguiente figura nos resume cómo interactúan estos componentes.
Para iniciar vamos a crear un ejemplo muy simple utilizando solamente una pagina web y la librería de charts de google, todo programado en javascript. Como lo hemos hecho en los ejemplos donde usamos javascript, vamos a usar el IDE llamado cloud9 para programar el demo. El primer paso es incluir la librería donde esta contenido el acceso al GoogleChart, este paso se ve en la siguiente figura.
Ahora, procedemos a crear el código necesario para poder desplegar el gráfico en nuestra página web.
La siguiente función que debemos crear es la que carga los componentes de la librería para que se puedan utilizar en el código anterior. Es importante destacar que aquí es donde se asocia nuestra función drawChart con el chart que vamos a crear.
Por último creamos el div en la página HTML donde se va a pintar el chart. Nótese que el nombre del div es el del elemento que se obtiene a la hora de instanciar el chart que vamos a apuntar.
Ahora solo nos queda ejecutar la página Web. El resultado de dicha ejecución se puede ver en la siguiente figura.
En nuestro próximo post, vamos a usar componentes de Windows Azure para obtener los datos de forma dinámica y para poder graficarlos con Google Charts.
En el post anterior nos conectamos al Windows Service Bus utilizando node.js y obtuvimos la lista de queues que están creadas en el namespace. En este post vamos a enviar un mensaje desde node.js y lo vamos a recibir utilizando también node.js.
Para enviar un mensaje, simplemente invocamos el método sendQueueMessage del ServiceBusService y le indicamos hacia que cola poner el mensaje, el mensaje que queremos enviar y ponemos un callback para manejar el error en caso que se de cuando intentamos poner en el mensaje en la cola. la siguiente figura nos muestra como codificar la invocación a este método.
Si ejecutamos el código anterior desde el IDE Cloud9 vamos a darnos cuenta que en el output del terminal se nos indica que el mensaje fue enviado de forma exitosa.
Si vamos al portal de Azure, podemos darnos cuenta que el mensaje esta recibido en la cola queuereportes tal y como se lo indicamos en el código anterior.
Para recibir el mensaje desde el bus de servicios de Azure, procedemos con la invocación al método receiveQueueMessage de la clase ServiceBusService. Cuando invocamos este método, le enviamos como parámetro la cola desde donde vamos a recibir el mensaje y un callback para recibir y procesar el mensaje – en este caso solo vamos a desplegar el mensaje en la consola de la terminal.
El resultado a la hora de ejecutar el código anterior se ve en la siguiente figura, en donde podemos ver que el mensaje fue recibido – además, se imprimen las propiedades del mensaje que por defecto se imprimen en el toString del objeto.
Si vamos al portal de Azure, podemos ver que el mensaje ya fue consumido.
Como hemos venido escribiendo en post anteriores, el bus de servicios de azure no solamente soporta el acceso a través de librerías .NET, si no también se puede acceder con otros lenguajes tales como Java, python y node.js –> si se utiliza AMQP también se puede acceder utilizando otros lenguajes como iremos viendo en post posteriores. En esta serie de post vamos a trabajar con el Azure Service Bus utilizando node.js.
Para este ejemplo vamos a variar un poco de herramienta de desarrollo y vamos a trabajar con cloud9. Este IDE esta en la nube y es muy popular entre los desarrolladores de node, ya que es un ambiente muy versátil desde donde se pueden hacer prueba, deployment a nubes como Azure, etc.
Para instalar la librería de Azure y tener acceso a los métodos para acceder el Azure Service Bus, vamos a utilizar la consola de Cloud9 y desde ahí vamos a ejecutar el comando npm install azure tal y como se ve en la siguiente figura.
Este comando descargara el SDK para Azure y nos permitirá acceder el Azure Service Bus desde nuestro código. Una vez finalizada esta tarea procedemos a cargar la librería de Azure desde nuestro código javascript.
Seguidamente procedemos a acceder el service bus para verificar que que podemos conectarnos al mismo utilizando las credenciales asignadas en el portal de Azure. Para esto, necesitamos que nuestras credenciales estén incorporadas en las variables de ambiente para que a la hora de ejecutar nuestro código, se pueda conectar al bus de Azure.
Estas variables son parseadas por la librería de Azure y busca en las mismas estos valores para iniciar la conexión al bus de servicios. Ahora procedemos a crear un objeto ServiceBusService, el cual nos permite acceder a bus de servicios de Azure.
Para este ejemplo vamos a listar la lista de queues que tengo creadas a este momento, lo cual se logra con el siguiente código.
Como se puede ver en el listado, utilizamos el método listQueues y procedemos a escribir en la consola el contenido de cada queue, esto porque por defecto el console.dir invoca al toString del objeto. El resultado de ejecutar el código anterior se ve en la terminal del IDE Cloud9, en el cual se pueden ver todos los objetos que existen en la actualidad con sus respectivas propiedades en formato JSON.
“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.
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.
En próximos post vamos a ver como interactúan clientes en plataformas diferentes utilizando AMQP – .NET y Java.
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.
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.
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.
Ahora asociamos la locación de recibo recién creada con el puerto de recibo.
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.
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.
Ahora cuando iniciamos la aplicación de BizTalk se consumen los mensajes de la cola y se guardan en el folder designado
El mensaje retornado contiene los datos tal y como fueron enviados en el post anterior.
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.
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.
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.
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.
El siguiente paso es seleccionar el adaptador para el bus de servicios como se muestra en la siguiente figura.
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.
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.
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.
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.
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.
En este post procedemos a crear nuestro servicio móvil desde el portal de Windows Azure. Para esto, vamos a la opción de Mobile Services y en la esquina inferior izquierda seleccionamos crear, lo que nos lleva a ver la cejilla básica donde seleccionamos la opción de crear un nuevo servicio móvil.
Seguidamente procedemos a completar el “wizard” que se nos va a presentar con la opción de crear, la cual nos permite definir un nombre para el servicio móvil (que debe de ser único) y luego a seleccionar la base de datos en la nube con la cual vamos a trabajar y la subscripción de Azure que vamos a utilizar.
El siguiente paso es configurar la base de datos y el servidor de base de datos contra el cual va a interactuar el servicio móvil. Es importante destacar que el servicio requiere una base de datos, pero no es necesario utilizarla, podríamos usar el service bus – como lo haremos mas adelante – para conectarnos a servicios ”on premises” utilizando “relay services”.
Cuando se finaliza la creación del servicio móvil nos aparece este mensaje.
Con esto ya tenemos creado nuestro servicio móvil. Si examinamos el servicio y vamos a la opción de configuración, podemos ver el servidor y la base de datos contra la cual estamos interactuando.
Definitivamente las aplicaciones móviles tienen toda la atención de las empresas ya que el no tener presencia móvil en estos tiempos es como no tener sitio web hace 10 años. Este disrruptor tecnológico ha hecho que los departamentos de TI de las empresas se enfrenten a escenarios a los cuales no están acostumbrados y por lo tanto quedan expuestos a el “conocimiento” de terceros que se presentan como conocedores del mundo móvil y muchas veces no es así.
En este nuevo mundo móvil y por la ya mencionada falta de experiencia de las empresas se cometen muchos errores que pasan desapercibidos por muchos y por mucho tiempo; entre estos errores podemos mencionar los siguientes:
Dado este escenario tan apocalíptico, cual es la perspectiva mas adecuada para desarrollar las aplicaciones móviles? En realidad existen muchas formas de desarrollar aplicaciones móviles útiles para el usuario final. Entre las cosas que podemos mencionar que hay que tener en cuenta a la hora de hacer estos desarrollos podemos enumerar algunas importantes:
Entre las opciones existentes quizás la mas simple para iniciar con el desarrollo móvil conectado a la capa media de la empresa esta la de Azure Mobile Services. Esta plataforma nos permite enfocarnos en el trabajo de la aplicación en si, y nos permite olvidarnos de todo lo requerido para manejar la conectividad de la aplicación con nuestros centros de datos o procesos de negocio ya existentes. Lo que hace el Azure Mobile service es generar un proxy en la nube que recibe solicitudes de la aplicación móvil y las redirecciona a donde nosotros le indiquemos, en primera instancia a una base de datos en Azure pero lo ideal para integrarlo con nuestro data center es direccionar al Azure Service Bus el cual a través de sus diferentes mecanismos interconecta la aplicación móvil con nuestros procesos de negocio que residen “on premises”.
Azure mobile services nos permite generar proyectos en las plataformas móviles mas populares, las cuales son al día de hoy Android, iOS, Windows Phone, Xamarin, Windows Store y HTML 5 + js para abarcar las demás opciones existentes. en realidad el proxy se genera para todas las plataformas y los desarrolladores eligen sobre cual quieren trabajar.
En nuestro próximo post veremos como iniciar el desarrollo móvil utilizando Azure Mobile Services.
