martes, 12 de agosto de 2014

Arquitectura 2014 - Implementando SOA con Azure Service Bus

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

Etiquetas de Technorati:

jueves, 17 de julio de 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.

lunes, 19 de mayo de 2014

Google Charts y Windows Azure 2 - Introducción a los Azure Tables

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.

Azure Tables

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:

  • Los nombres deben de ser únicos dentro de una cuenta
  • Sólo pueden contener caracteres alfanuméricos
  • No pueden iniciar con un número
  • Son “case sensitive”.
  • El tamaño mínimo es de 3 caracteres y el máximo de 63.
  • Algunos nombres están reservados, tales como “tables”.

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:

  • PartitionKey: Las tablas de entidades se organizan por partición. Una partición es un rango de entidades que tienen el mismo valor en esta llave. Esta llave forma la primera parte de la llave primaria de una entidad. Su principal función es soportar “load balancing” entre los nodos de storage.
  • RowKey: Es la segunda parte de la llave primaria. Esta es una llave única para la entidad en una partición dada.
  • Timestamp: Esta propiedad es del tipo DateTime y es mantenida en el servidor para almacenar el momento en que una entidad fue modificada. Se utiliza para permitir concurrencia optimista sobre las tablas.

Node.js y las tablas en Azure

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.

clip_image002

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.

clip_image004

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.

clip_image006

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.

clip_image008

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.

clip_image010

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.

clip_image012

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.

clip_image014

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:

clip_image016

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.

clip_image018

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.

Etiquetas de Technorati: ,,,

lunes, 12 de mayo de 2014

Google Charts y Windows Azure 1 - Introducción a 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.  

Qué es Google Charts?

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.

Demostración

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.

jsHeaderGoogleCharts.png

Ahora, procedemos a crear el código necesario para poder desplegar el gráfico en nuestra página web.

DrawChart GoogleChart post 1.png Como vemos en el código anterior, primero creamos el conjunto de datos que queremos desplegar en el chart. En este caso estamos creando un DataTable estático pero en próximos post lo vamos a integrar a componentes de Windows Azure. El paso dos es mas bien estético, como queremos que se vea el Chart; en este caso vamos a poner un fondo Gris, un título con fuente 18, con tooltip cuando movemos el cursor por el chart, y lo queremos ver en 3D. Por último creamos el gráfico → un pieChart →  y lo pintamos ( en un div llamado ‘chart’).

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.

LoadGoogleChart.png

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.

DivGoogleChartDemo1.png

Ahora solo nos queda ejecutar la página Web. El resultado de dicha ejecución se puede ver en la siguiente figura.

PrimerChartResultadoFinal.png

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.

 

Etiquetas de Technorati: ,,

lunes, 21 de abril de 2014

Azure Service Bus y node.js–parte 2

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.

Envío del mensaje

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.

image

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.

image

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.

image

Recibir el mensaje

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.

image

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.

image

Si vamos al portal de Azure, podemos ver que el mensaje ya fue consumido.

image

Etiquetas de Technorati: ,,

domingo, 20 de abril de 2014

Azure Service Bus y node.js – parte 1

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.

Herramienta de desarrollo

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.

Instalando el SDK de Azure para node

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.

image

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.

 image

Accediendo el Azure Service Bus con node.js

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.

image

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.

image

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.

image

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.

image

Etiquetas de Technorati: ,,

sábado, 5 de abril de 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:

miércoles, 12 de marzo de 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

domingo, 9 de marzo de 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: ,,,

lunes, 20 de enero de 2014

Windows Azure Mobile Services – Aplicaciones Móviles de Valor 2

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.

image

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.

image

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”.

image

Cuando se finaliza la creación del servicio móvil nos aparece este mensaje.

image

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.

image

 

Etiquetas de Technorati: ,

sábado, 4 de enero de 2014

Windows Azure Mobile Services – Aplicaciones Móviles de Valor 1

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:

  • Diseñamos las aplicaciones móviles como si fueran aplicaciones Web: como estamos tan acostumbrados al mundo web, llevamos los mismos conceptos a los dispositivos móviles, lo cual en la mayoría de los casos es un groso error porque a nivel móvil no se tiene el mismo poder computacional, la misma energía disponible e incluso la misma cantidad de ancho de banda. Igualmente los usuarios no se comportan de la misma manera cuando utiliza un aplicativo móvil y un aplicativo web.
  • Creamos las aplicaciones sin pensar en el impacto que tendrán en el dispositivo donde van a correr: Esto es provocado porque seguimos usando las tecnologías que hemos usado siempre para hacer cosas diferentes. Un ejemplo típico de esta situación es el uso de servicios web SOAP para su consumo desde los aplicativos móviles; esto porque el servicio SOAP utiliza XML para representar todo el mensaje que se envía de ida y vuelta y como ya lo hemos mencionado en este blog, el procesamiento del XML requiere mucho poder computación, por lo tanto mucha energía lo que conlleva a que la batería de los celulares se drene rápidamente lo que conlleva a que el usuario final no use mas la aplicación.
  • Tiempos de espera elevado entre transacciones: Como normalmente hacemos transacciones para aplicaciones web, en donde un usuario puede esperar hasta un minuto en frente de la computadora para que su transacción se lleve a cabo, procedemos a crear la transaccionabilidad de la misma forma en las aplicaciones móviles. Sin embargo a nivel móvil las transacciones deben de ser mas rápidas y con información mas condensada – cada bit que se transporta importa.
  • Agregamos la misma funcionalidad del sitio web a la aplicación móvil: Este es otro error grave, ya que las aplicaciones móviles no deben tener funcionalidades que no aplican bien o que no se resuelven bien en la plataforma, – ejemplo los filtros de lista en línea – ya que en una pantalla tan pequeña normalmente no se logra comprender fácilmente la funcionalidad y los usuarios terminan descartándola. Además, el consumo de recursos intensos – consultas vía web por letra digitada por ejemplo –, terminan dando la impresión de que la aplicación no es de calidad, cuando en realidad son aspectos externos los que terminan dando esa idea.
  • Aplicaciones transaccionales móviles web: Este quizás sea uno de los temas más complicados de tratar en lo que se refiere al desarrollo móvil. Las empresas con tal de tener presencia móvil, terminan haciendo sitios web que permitan hacer transacciones vía el dispositivo móvil. Aunque desde un punto de vista informativo las aplicaciones web móviles funcionan de maravilla, desde un punto de vista transaccional pueden ser muy problemáticas. Esto porque las aplicaciones móviles pueden salirse de una transacción por razones mínimas ( entrada de un msm, una llamada, un mensaje de facebook, etc ) y con eso el manejo de la cancelación de la transacción se vuelve muy truculenta. Igualmente la confianza del usuario no es la misma si usa una aplicación nativa a una aplicación web porque básicamente trae miedos (muchas veces con toda razón) de los peligros de las transacciones vía web.
  • Uso de bases de datos en los dispositivos: Por increíble que parezca esta idea (ahora solo falta alguien pidiendo un servidor web en el móvil) hay aplicaciones que para funcionar necesitan una base de datos local. Las bases de datos no son para usarse en dispositivos móviles ya que consumen recursos necesarios para el dispositivo, agrega necesidad de trabajo en “background” por lo que el consumo de batería es constante, además la seguridad de los datos pasa a otro nivel porque un usuario podría perder su dispositivo y por lo tanto sus datos en donde podrían existir transacciones importantes como movimientos financieros que están en cola esperando por una conexión para llevarse a cabo.
  • Funcionalidad de la aplicación móvil – agregar valor al usuario de la aplicación: Definitivamente el objetivo de tener una aplicación móvil no es solo presencia en alguna plataforma, si no también dar valor agregado al usuario de la misma. Nadie va a consultar las noticias de una empresa mas de una vez y en la empresa seguramente tampoco las van a actualizar de forma seguida. Es importante que el usuario encuentre de valor la aplicación y le permita llevar a cabo acciones que le mejoran la percepción hacia la empresa. Tener una aplicación por tenerla, no tiene sentido ya que requiere tiempo y dinero para desarrollarla y al final en lugar de dar una buena imagen, haremos que nuestros clientes piensen que todos los servicios que oferta la empresa son de esa calidad.

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:

  • La aplicación tiene que ser diseñada con la funcionalidad móvil necesaria para que el cliente aprecie el valor de la misma. Debe de ser fácil de administrar y actualizar por parte de la empresa desarrolladora y debe de causar un impacto positivo en el cliente. Por ejemplo, si la aplicación es para teléfonos, NO DEBEMOS usar GRIDS.
  • Utilizar JSON como esquema para serializar datos que viajan a través de servicios: JSON es mas simple de parsear y requiere menos poder computacional que XML, si utilizamos JSON para representar nuestros datos vamos a tener mejor desempeño a la hora de consumir servicios desde un dispositivo móvil.
  • Las transacciones deben de ser expeditas; es decir los servicios que se consumen deben de llevar a cabo solo una tarea y retornar la información solicitada, con esto nos garantizamos que el tiempo de respuesta sea el optimo. Además la cantidad de datos a retornar debe de estar pre filtrada, por ejemplo nunca deberíamos presentar en un dispositivo móvil todas las transacciones del cliente en la pantalla principal de la aplicación.
  • La aplicación debe de integrarse con el middleware de la empresa para que su funcionalidad aporte valor al usuario. Por ejemplo, en una aplicación móvil podría ver mis transacciones bancarias del ultimo mes, y ver por solicitud los meses anteriores; o también podría ver todas las solicitudes de servicio al cliente que tiene y el estado de cada una – de nuevo en cantidades manejables.
  • Los servicios que consume la aplicación móvil son los mismos servicios que consumen otras aplicaciones tales como el sitio web, lo que garantiza uniformidad en los procesos que se mandan a ejecutar. Esto quiere decir que seguramente vamos a tener que agregar endpoints REST para soportar JSON en el servicio.
  • Minimizar el uso de base de datos: No es que no necesitemos en alguna momento una base de datos en nuestra aplicación móvil, pero sin duda el aplicativo debe de estar en línea siempre que sea posible; sin embargo, cuando se requiere que pueda llevar ciertas tareas estando offline, debemos buscar métodos alternativos para guardar estas transacciones que se deberán sincronizar luego con el repositorio central. Además, no toda la funcionalidad debería estar disponible online solo la realmente es necesaria; por ejemplo, las consultas no deberían estar disponibles offline, pero transacciones que se pueden ejecutar después contra el repositorio centralizado si podrían guardarse en el dispositivo para ejecutarlas cuando haya conexión.
  • Preferiblemente codificar la aplicación en la plataforma de desarrollo nativa, esto principalmente porque las aplicaciones nativas tienen mejor desempeño que las aplicaciones web o las aplicaciones que se convierten en nativas a partir de algún framework de desarrollo móvil como phonegap o Sencha Touch; esto principalmente porque aunque estos frameworks generan código nativo, las instrucciones generadas no siempre son las optimas.

Azure Mobile Services

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”.

Plataformas soportadas

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.

image

En nuestro próximo post veremos como iniciar el desarrollo móvil utilizando Azure Mobile Services.