MSDN Blogs
  • WarNov Developer Evangelist

    Windows Store: Un análisis

    • 0 Comments

    El Windows Store a un mes de haber sido lanzado, se ha estado convirtiendo en un importante canal de distribución digital de software.

    Este protagonismo entre otras cosas ha causado que empresas independientes como Distimo que se dedican al estudio independiente de la industria de las apps a nivel mundial, lo hayan estudiado, considerándolo un importante actor en el mercado.

    Este artículo está basado en los estudios publicados por Distimo para el fin de Noviembre de 2012, sobre nuestro store. Esto, con el fin de mostrar un punto de vista no sesgado, sino imparcial, toda vez que la firma mencionada es independiente de cualquier proveedor de tiendas de Apps online.

    Los principales hallazgos incluyen:

    1. Hasta hoy, el número diario de descargas de las 300 apps más importantes del Windows Store, es tres veces mayor al que se experimenta con las 300 Apps más populares del Apple Mac App Store. Sin embargo, al mirar las apps pagas, se están comprando más en éste último. No obstante, es de notarse que ya están comenzando a arribar apps como Angry Birds, Fruit Ninja y Microsoft Office que pueden cambiar rápidamente esta proporción:

    image

    2. Microsoft está haciendo un gran trabajo para darle mayor visibilidad al contenido local en el store. En general, 10% de todas las Apps en los ranking locales, son apps locales. Y esta tasa aumenta viendo países pequeños. Por ejemplo en Japón, el 41% de las top apps son locales.

    3. El Windows Store presenta hoy 21.183 apps en total. De estas solo el 65% están disponibles en Estados Unidos. Aquí para efectos comparativos, cabe mencionar que en el resto de stores, la proporción es de 85%. De estas, 21.129 están disponibles para x86, 21.175 para x64 y 19.657 para ARM.

    4. El Windows Store, ha sido el que ha tenidos más apps disponibles tras su primer mes de lanzamiento (20K). El número para la Apple Mac App Store fue de solo 13K.

    5. Comparación con otros mercados:

    image

    Obsérvese por ejemplo que en solo un mes, el Windows Store ha mostrado tener más apps que todo el Apple Mac App Store durante casi dos años.

    6. Paid vs Free:
    Según el estudio, el Windows Store es aquel con una mayor proporción de apps free: 86% En el Google Play, el porcentaje es de 35% y en el Apple Mac App Store es del 16%.

    7. Porcentaje de Apps locales populares

    image

    Aquí resulta bien interesante mostrar por ejemplo que en Colombia ya se está proporcionando mucho impulso a las apps locales.

    8. Top 10 de publishers a nivel Mundial:

    image

    9. Top 10 de Apps en Colombia

    image


    10. Conclusiones

    “Observando estos primeros hallazgos acerca del Windows Store, es claro que existe mucho potencial y esto no es solo debido a que el número de consumidores crecerá inmensamente debido al gran alcance que tiene Windows, sino también debido a que Microsoft se ha apropiado de las mejores prácticas en la industria de apps y las ha implementado bien. Dividir el mercado del desktop y las tablets y además estableciendo un alto foco en el contenido local, también es una estrategia promisoria.¨

  • WarNov Developer Evangelist

    Tarde de Tecnología

    • 0 Comments

    Este jueves 22 de noviembre estaremos en Cali en una edición más de nuestro Microsoft Tech Day.

    Tendremos como es acostumbrado, dos tracks. Uno de Developers y otro de ITPros. La programación es esta:

    image

    En cuanto al tema de desarrollo, estaremos viendo dos temas muy importantes que tienen que ver con el mundo de servicios para nuestras apps. La primera parte, nos mostrará servicios móviles provistos por Window Azure pensando precisamente en las apps, otorgándonos facilidades para la autenticación, notificaciones y almacenamiento. Luego veremos el nuevo framework de WebAPI que nos permite hacer servicios Web basados en REST de una manera bastante sencilla, y como ejemplo veremos cómo almacenar archivos de manera segura, desde nuestras apps a la nube de Windows Azure.

    No se lo pierdan, en el Hotel Sheraton.

    Regístrense gratis aquí.

  • WarNov Developer Evangelist

    Usando WebAPI para generar Azure SAS para tus apps

    • 0 Comments

    He venido escribiendo una serie de posts acerca de los diversos mecanismos que existen para poder subir archivos desde nuestras apps de Windows 8 o de Windows Phone a Windows Azure.

    En este artículo explico por qué es importante un mecanismo que nos permita autorizar solo por un tiempo determinado manejar un archive determinado en el Storage de Azure, de manera que no expongamos nuestra información de cuenta de storage a que un hacker la pueda descubrir hacienda ingeniería inversa de nuestras apps. Este mecanismo es lo que se conoce como Shared Access Signature de Windows Azure y no es más que una URL que tiene validez temporal, con la cual podemos consultar un archive, eliminarlo, modificarlo o crearlo.

    En este otro artículo, muestro cómo podemos usar los Mobile Services de Windows Azure para poder obtener dichas SAS. Es un mecanismo que nos permite ahorrarnos tener web servers y que escala muy bien, porque maneja muy poca transferencia. Además nos economiza la administración. Todo esto, versus tener un servicio web que reciba las fotografías y las envíe al storage de Windows Azure, ya que toda la responsabilidad de ese servicio recae sobre nosotros.

     

    image*Azure + Web + Apps

    Estas ventajas son muy válidas. Pero sucede que para poder ejecutar los Mobile Services, se requiere por el momento, tener una base de datos de SQL Azure, y esto puede generar costos adicionales. Además, Mobile Services se encuentra en etapa de preview, por lo que salir a producción usándolos, puede ser riesgoso.

    Por estos motivos, he creado este post, en el que explico una manera alternativa para que nuestras apps puedan acceder a las codiciadas SAS, para poder subir archivos a Azure.

    Dado que las SAS son fácilmente generables a través del API de Storage de Azure: Microsoft.WindowsAzure.StorageClient,  es muy fácil pensar en un servicio Web que use esta API para retornar la SAS, dado un nombre de blob determinado. Y es esto precísamente lo que vamos a hacer. Pero será un servicio web muy liviano y además que permita un fácil acceso desde diversas plataformas. Todo esto se logra gracias a WebAPI. Un framework basado en ASP.NET para poder exponer construir de manera sencilla Servicios HTTP disponibles para una gran variedad de clientes que manejan REST.

    Como el framework es muy liviano y el proceso a ejecutar también lo es (solo se recibe una palabra y se retorna una URL), entonces es totalmente plausible que éste servicio se despliegue en un par instancias pequeñas de Windows Azure y soporte muy buena carga. De hecho, cuando los Windows Azure WebSites ya salgan de preview y comiencen a estar en producción, tendremos una alternativa aún más económica ya que está basada en servidores compartidos que luego pueden escalar y convertirse en servidores dedicados si las exigencias de nuestras apps así lo demandan. De hecho, algo que hoy en día existe que es la posibilidad de tener hasta 10 WebSites gratuitos, se mantendrá cuando el servicio pase a producción. En ambos casos (tanto con Cloud Services como con WebSites), nos ahorramos el despliegue de una Base de Datos y tenemos un poco más de control que con los Mobile Services.

    Aprovecho en este punto entonces para hacer notar que he mostrado varias opciones y ninguna de ellas es la absolutamente recomendable para todos los casos. Las condiciones de cada problema son particulares y por ende lo son sus soluciones. Mi misión es mostrarles las posibilidades. La de ustedes, elegir inteligentemente.

    Entonces continuando con nuestra solución basada en WebAPI tenemos nuestro controlador:

    SERVER:

    public class SASController : ApiController
    {
    
        //Esto es solo un ejemplo y pongo aquí directamente
        //los datos de la cuenta de acceso. 
        //Estos deberían estar en el config encriptados.
        static CloudStorageAccount _account;
        static bool _accountSet=false;
    
        //En bien se construye la clase, se trata de ajustar
        //la cuenta de almacenamiento de Azure
        static SASController()
        {
            string accountName = "tunombredecuenta";
            string pak = "fP4fXF9Vg...";
            _accountSet = CloudStorageAccount.TryParse(
                String.Format("DefaultEndpointsProtocol=https;"+
                "AccountName={0};AccountKey={1}",
                accountName,
                pak), out _account);
        }
    
    
        // GET api/sas/nombredeblob
        public string GetSAS(string id)
        {
            //Si la cuenta ha sido ajustada correctamente
            if (_accountSet)
            {
                //Creamos un container por defecto. 
                //Se puede trabajar tambien como parámetro
                var container = _account
                    .CreateCloudBlobClient()
                    .GetContainerReference("testcontainer");
                container.CreateIfNotExist();
    
                //Obtenemos una referencia al blob que se subirá
                var blob = container.GetBlobReference(id);
    
                //Creamos la sas que da permiso únicamente 
                //para ese blob, y solo por dos minutos
                //qué seguro no?
                var sas = blob.GetSharedAccessSignature
    (new SharedAccessPolicy() { Permissions = SharedAccessPermissions.Read | SharedAccessPermissions.Write, SharedAccessExpiryTime = DateTime.UtcNow +
    TimeSpan.FromMinutes(2) }); //Armamos la url en la cual podremos
    //poner el blob desde el cliente
    return blob.Uri.AbsoluteUri + sas; } else return "The API has not been configurated yet, "+ "pray to the heavens for them to configure it"; } }

    Vemos como solo bastó importar la librería del API de Storage, inicializar la cuenta de almacenamiento a través de un constructor estático y luego en la acción Get del controlador SAS usar la cuenta inicializada para producir la SAS basados en el nombre del blob que nos llega como parámetro “id”. Le dejé ese nombre para hacer prevalecer el paradigma de “Convention over Configuration”que al igual que en MVC, está muy presente en WebAPI.

    Vemos cómo es posible configurar el tipo y tiempo de acceso que otorgará la SAS. Todo eso queda incluido en la URL que se retorna al cliente. Algo del tipo: https://cuenta.blob.core.windows.net/img/archivo.jpg?sv=201324kjn,mnetc

    Con esta URL luego el cliente lo único que tiene que hacer es instanciar un HTTPClient y a través de este, poner el contenido del archivo con los headers específicos en dicha URL. Veámos el código de una app de Win8 para este fin:

    CLIENT

     

    //Escogemos el archivo
    var filePicker = new FileOpenPicker();
    filePicker.FileTypeFilter.Add(".jpg");
    var file = await filePicker.PickSingleFileAsync();
    
    if(file!=null)
    {
        //Con un cliente http nos comunicamos
        //al web api para bajar la SAS
        //luego con ese mismo cliente subimos el archivo
        using (var client = new HttpClient())
        {
            //Bajando la SAS
            var sas = await client.GetStringAsync
                ("http://localhost:47805/api/sas/" + file.Name);
            sas = sas.Substring(1, sas.Length - 2);
    
            //Cargamos la imagen con el HttpClient al blob 
            //service usando la SAS obtenida desde WebAPI
    
            //Obtenemos el stream de un storage file definido anteriormente
            using (var fileStream = await file.OpenStreamForReadAsync())
            {
                var content = new StreamContent(fileStream);
                content.Headers.Add("Content-Type", file.ContentType);
                content.Headers.Add("x-ms-blob-type", "BlockBlob");
    ”
    //Con el PutAsync, enviamos el archivo a Azure //a través de la URL autorizadora que está en SAS using (var uploadResponse = await client.PutAsync(new Uri(sas), content)) { //Agregar cualquier post proceso adicional } } } }

    Con el HTTPClient hemos descargado la SAS luego de tener el archivo escogido con su nombre identificado y luego aprovechamos ese mismo HTTPClient para poner el contenido del archivo al cual le hemos añadido unos headers para que pueda ser manejado correctamente por los Servicios REST del storage de Azure. Es importante notar aquí que la transferencia del archivo se realiza directamente desde el cliente a los Servicios de storage de Azure. El servicio web solo da la SAS. Esto es económico, veloz y escalable.

    Quise usar el anterior ejemplo para mostrar un escenario de uso de WebAPI. Pero a decir verdad, hay otra manera aún más liviana de lograrlo y es a través del uso de un manejador genérico de ASP.NET o ASHX. Un ASHX solo requiere de la Plataforma más elemental de ASP.NET (no requiere un motor de ruteo por ejemplo) para funcionar y lo hace también a través de la versatilidad de HTTP. Además el código es idéntico, except que el nombre del blob ya no va embebido en la ruta del request sino como un parámetro del querystring y el método como tal ya no va como una acción dentro del controller, sino como el ProcessRequest del handler.

    Summary:

    En conclusión, hemos visto cómo producir SAS desde Servicios web basados en HTTP, como lo proveen la WebAPI y los Generic Handlers. Luego vimos cómo usar esas SAS para poder subir archivos desde nuestras apps a Azure.

     

  • WarNov Developer Evangelist

    Adicionando archivos de Apps al Storage de Azure con Mobile Services

    • 0 Comments
     
    Los Windows Azure Mobile Services, proveen un mecanismo para permitir que clientes móviles (por ahora Windows 8, Windows Phone y iOS) se conecten a Windows Azure para almacenar y leer información tabular. Además ofrecen funcionalidad de push notifications, logging y autenticación.

    Pero cómo benefician estos servicios a la necesidad de poder almacenar archivos en el storage?

    En este post están los detalles que permiten justificar que para acceder a una cuenta de Storage desde un dispositivo es muy riesgoso dejar allí los datos de la cuenta de Azure, pues pueden ser extraídos con Ingeniería Inversa. Además de que el acceso se dificulta por falta de un API que abstraiga el acceso a REST directo. Windows Azure entonces dispone de un mecanismo llamado “Shared Access Signature” o SAS, que proporciona unas credenciales temporales para que se pueda acceder al storage.
        
    Tener un servicio Web que reciba las imágenes y desde su memoria las suba al storage de Azure de manera segura, es una opción, pero muy poco escalable, porque puede que miles de usuarios quieran subir sus fotos. Disminuir la carga del web server haciendo solo que exponga las credenciales SAS a los dispositivos para que estos luego puedan acceder directa y fácilmente al storage es mejor opción, pero sigue siendo algo cara, pues requiere un web server y un desarrollo asociado, así como todo el overhead de mantenimiento.
        
    Entonces la idea es aprovechar los Mobile Services para obtener esta SAS.
        
    No obstante, en las funcionalidades que mencioné, en ninguna está la del suministro de la SAS. Pero aquí es donde la imaginación y el ingenio juegan parte importante. Lo que sí mencioné es que se puede acceder a unas tablas a leerlas o modificarlas. Para ello se han dispuesto unas APIs especialmente diseñadas para WP y WinRT; hasta para iOS hay versión. Y en las tres plataformas pueden ser incluidas y usadas sin ningún problema de funcionamiento ni certificación cuando la app se sube al store. Pues bien, las operaciones CRUD que hacemos sobre estas tablas (que se pueden diseñar desde el portal de administración de Azure sin código alguno), están sujetas a que se ejecuten triggers que se dispararán cuando nosotros lo especifiquemos. Por ejemplo, cuando haya una inserción. En últimas esto se puede tomar como un servicio web asíncrono, en el cual insertamos un request en la tabla y luego la volvemos a consultar para ver la respuesta obtenida, que obviamente se encontrará en otra columna.
        
    El primer paso entonces, es crear el Mobile Service en el portal de Windows Azure. Esto es totalmente gratuito. Solo es requerido crear una cuenta, cosa que también es gratis. Un paso a paso muy bien elaborado lo pueden encontrar aquí.
        
    Básicamente lo que hicimos en ese paso a paso, fue crear el servicio y luego desde el portal, usar unas funcionalidades muy útiles que tenemos allí, como la de crear automáticamente nuestra primera tabla de datos. Y luego bajarnos una solución preconstruida que va a consumir esa tabla. Esa solución puede ser para phone, Windows 8 o iOS.
        
    clip_image002
    Obviamente, también podemos conectarnos a apps existentes. No solo a nuevas. Con este fin el portal nos suministra un código con una clave que debe tener la app para poderse conectar. Este código en el caso de Windows 8 por ejemplo, se pone en el App.xaml.cs:
    //This MobileServiceClient has been configured to communicate
    //with your Mobile Service's url and application key.
    //You're all set to start working with your Mobile Service!
    public static MobileServiceClient MobileService =
    new MobileServiceClient( "https://warserv.azure-mobile.net/", "ElSmsvstPUsdXWsHJqFteqhkLxDVcdr15" );

    Obviamente para que el código nos funcione, debemos de haber referenciado la dll que contiene el tipo MobileServiceClient. Esta dll ya viene agregada si nos bajamos la solución de ejemplo del portal. Si estamos habilitando una solución preexistente, la incluimos manualmente. Se llama Windows.Azure.Mobile.Services.Managed.Client y queda disponible luego de que instalemos el Mobile Services SDK.

    Después de esto, nuestra app ya queda lista para conectarse directamente con el servicio y empezar por ejemplo a hacer inserciones en la tabla que construimos en el paso a paso (o cualquier otra tabla que creemos dentro del servicio usando el portal).
        
    Ahora lo que haremos es generar el trigger para nuestro servicio, de manera que cada vez que exista un insert, se dispare una rutina que nos retorne dentro de ese registro insertado, la SAS que necesitamos. Esta rutina la debemos escribir con Javascript, que se ejecutará en el server, a través de un editor online que tenemos en el portal. Para acceder a ese editor, ubicamos nuestro servicio y luego allí escogemos la tabla en cuestión (1). Después vamos a SCRIPT (2) y finalmente escogemos la operación (Insert) de esta manera, ejecutaremos la acción especificada en el script con cada insert que hagamos en la tabla.
        
    clip_image003
        
    El código del script lo pueden descargar de aquí. Y la parte más importante del mismo es ésta:
       
    function insert(item, user, request) {
        var accountName = '<SU NOMBRE DE CUENTA>';
        var accountKey = '<SU PAK>';
    
        //Note: this code assumes the container already 
    //exists in blob storage. //If you wish to dynamically create the container then implement
    //guidance here -
    //http://msdn.microsoft.com/en-us/library/windowsazure/dd179468.aspx
    var container = 'test'; var imageName = item.ImageName; item.SAS = getBlobSharedAccessSignature(accountName,
    accountKey, container, imageName); request.execute(); }
    Como ven, tienen que poner los datos de la cuenta en los placeholders. También se aprecia que el ítem insertado viene como parámetro. Y que luego a ese ítem se le ajusta la propiedad SAS con una función que recibe el nombre de la cuenta, la clave, el contenedor y la imagen. Esto nos va a retornar una SAS que no es más que una URL que contiene unos permisos temporales implícitos, para que luego a esa URL podamos subir un archivo de nombre item.ImageName. Al final, vemos como se ejecuta el request y es en este momento cuando se inserta el registro como tal en la tabla del servicio. Además el ítem actualizado baja al cliente automáticamente y desde allí podremos consultar el valor de la SAS.
        
    Entonces, para el manejo desde nuestra app, necesitamos una clase que nos represente al ítem:
        //la estructura de la tabla que tenemos
        //en el Mobile Service. 
        //Es una clase generada por nosotros 
        //de acuerdo a nuestras necesidades.
        public class TodoItem
        {
            public int Id { get; set; }
    
            [DataMember(Name = "text")]
            public string Text { get; set; }
    
            [DataMember(Name = "ImageName")]
            public string ImageName { get; set; }
    
            //Es en este campo, donde quedará almacenada la SAS
            [DataMember(Name = "SAS")]
            public string SAS { get; set; }
    
            [DataMember(Name = "complete")]
            public bool Complete { get; set; }
        }
    
    Esta clase la creamos con los campos por defecto que se crean las tablas en Mobile Services, y le agregamos los campos requeridos.
        
    Luego de esto, cuando ya tenemos el archivo que queremos subir a la nube, lo que hacemos, es crear una inserción en la tabla:
    StorageFile file = await openPicker.PickSingleFileAsync();
    if (file != null)
    {
        //agrega un item a la tabla de Mobile Service, disparando un trigger
        //que retorna el item.SAS, como un valor en otra columna de la tabla,
    //que se transfiere automáticamente al ítem.
    var todoItem = new TodoItem() { Text = "test image",
    ImageName = file.Name }; await todoTable.InsertAsync(todoItem); items.Add(todoItem); //Cargamos la imagen con el HttpClient al blob //service usando la SAS generada en item.SAS using (var client = new HttpClient()) { //Obtenemos el stream de un storage file definido anteriormente using (var fileStream = await file.OpenStreamForReadAsync()) { var content = new StreamContent(fileStream); content.Headers.Add("Content-Type", file.ContentType); content.Headers.Add("x-ms-blob-type", "BlockBlob"); //Con el PutAsync, enviamos el archivo a Azure //a través de la URL autorizadora que está en SAS de la forma: //"https://--------------.blob.core.windows.net/test/
    //androidsmartglass.jpg?etc //donde etc es la cadena de validación
    using (var uploadResponse = await client.PutAsync(new Uri(todoItem.SAS), content)) { //Agregar cualquier post proceso adicional } } } }

    De esta manera, ya habremos podido subir nuestro archivo al storage de Azure, desde un cliente móvil, sin arriesgar nuestra cuenta de storage, sin sobrecostos por Servidores Web y de una manera absolutamente escalable, porque este request en total pesa menos de 1Kb. Mucho menos de lo que sería subir la imagen a un servidor, para que desde allí de manera segura se pudiese enviar al storage. Ahora, el envío es directo, de manera que es más rápido!

    En síntesis, hemos visto como entre las bondades de los Windows Azure Mobile Services, podemos contar con la capacidad de generar servicios sencillos basados en código de servidor escrito con Javascript que como input puede recibir un registro en las tablas de datos y como output una respuesta que queda almacenada en ellas en otra columna distinta. Si adicionamos a esto un trigger para cada inserción, obtendremos una respuesta asíncrona que hace que el Javascript que hemos escrito actuando sobre las APIs de Azure, permita entre otras cosas generar claves SAS, útiles para que dispositivos puedan acceder de manera segura y directa al storage.
  • WarNov Developer Evangelist

    Azure como backend de storage para Windows Apps y el poder de los Mobile Services

    • 2 Comments

    Con Windows Apps, me refiero a apps para el Windows Store y para el Windows Phone Store.

    El conocimiento promedio que tenemos hoy en día de Azure y de Cloud Computing, nos indica que una gran alternativa para las necesidades de storage que tienen las apps, efectivamente es el storage de Azure. Y uno va y mira y sí… efectivamente así es. Pero hay que tener en cuenta ciertos detallitos en los que podemos pecar por ir muy a la ligera.

    Si queremos ofrecer almacenamiento en nuestra app a través de una cuenta de Azure, lo primero que se nos vendría a la mente es: fácil, uso el API de Storage y la accedo desde mi app. Pero esto tiene dos implicaciones:

    http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-28-02-metablogapi/2816.image_5F00_32AEF2F2.png

    1. El soporte que se le da a la API desde las plataformas de desarrollo de WP y de WinRT: En este caso, lamento informar que el Microsoft.WindowsAzure.StorageClient.dll aún no está disponible para estas plataformas, pese a que en Web, WinForms, WPF, WCF y demás sí es completamente accesible. Esto nos deja con una sola alternativa y es la de usar REST puro y duro para acceder al storage de Azure. Es decir, crear clientes HTTP dentro de del código de la app y configurarlos para hacer un request REST sobre la API del storage (recordemos que esta API es nativa REST y por ende se puede acceder de esta manera). Tanto en WP como en WinRT es completamente viable esto, ya que tenemos las clases adecuadas. Sin embargo, configurar estos clientes no es fácil ni amigable. Algunos acercamientos como la librería Windows Azure Storage Client para Windows Phone disponible a través de NuGet, pueden ayudar a alivianar la tarea, encapsulando todos estos llamados. Desafortunadamente hoy no tenemos una equivalencia para WinRT. Tal vez mediante agunos hacks, uno pudiera usar esta de phone con Windows 8. Pero entonces viene el 2do. Punto a tener en cuenta:

    2. Independientemente de que hagamos los llamados a través de REST puro o usando una librería como la citada en phone, siempre debemos incluir la información de la cuenta para poder tener acceso a Azure. Tradicionalmente esto no es un gran problema, y digo tradicionalmente refiriéndome al hecho de que si estamos acostumbrados a crear aplicaciones de servidor que acceden a Azure, sabemos que los datos de la cuenta (nombre y clave) están “seguros” en nuestros servidores que están detrás de unos balanceadores de carga y unos proxies que lo protegen. Pero en el caso de las apps…. Te sentirías seguro sabiendo que el nombre y clave de tu cuenta de Azure está “quemado” en una app que probablemente hayan bajado cientos o miles de usuarios? Cualquier usuario malicioso, podría hacer ingeniería inversa de la app para extraer los datos de la cuenta (y aunque es complicado, no es imposible).

    Entonces, no hay una API oficial y tampoco es seguro embeber los datos de la cuenta en los clientes. Así que entonces la solución que se viene a la cabeza es: Hagamos servicios web!

    De esa manera, dado que WinRT y WP, tienen completo soporte a servicios web se podrán subir los archivos al servidor web y éste, que sí tiene el poder de usar la API de Storage de Azure, tendrá muy cómodo pasar estos archivos a la nube. Además, los datos de cuenta estarán seguros dentro del server, pues los clientes solo necesitan saber la dirección del servicio web.

    Pero realmente es esto lo que queremos? Tener un servidor Web, tiene costos asociados. Además tendríamos una sobrecarga sobre esos servidores recibiendo imágenes de Raimundo y todo el mundo. Por lo tanto requeriríamos varios servidores y los costos se elevarían enormemente. Sumémosle además el hecho de que el storage de Azure se puede acceder directamente y nos ahorraríamos todos esos costos.

    Entonces… cuál sería la solución apropiada?

    Se imaginan un mecanismo en el cual cada app pudiera tener un permisito que dure solo el tiempo requerido para ejecutar la acción necesaria sobre el storage y que luego ya no sea válida? En ese caso, por más que el hacker obtenga la clave, cuando lo haga, ya no le servirá de mucho.

    Pues para sus cuentas, les informo que Azure soporta el acceso al storage a través de este mecanismo, que particularmente se llama “Shared Access Signature” o SAS.

    Obviamente, para poder generar una SAS, se requiere tener los datos de la cuenta. Y volvemos al mismo sitio: no queremos exponer esos datos. Pero hay algo bueno! Si creamos un servicio web que nos retorne esa SAS (menos de 1K de tamaño), tendremos mucha menos sobrecarga que cuando usamos web services para transferir imágenes. En este caso, solo requeriremos una pequeña respuesta del server con la SAS y ésta la usaremos para que a través de un llamado HTTP (ésta vez mucho más sencillo que cuando se desea usar los datos de la cuenta nativa, ya que este requiere ser asegurado) en el que referenciamos dicha SAS podamos ejecutar la acción requerida sobre el storage (por ejemplo subir o bajar un archivo de los blobs, o consultar un registro de las tablas) sin necesidad de suministrar al cliente los datos de la cuenta.

    Entonces se podría decir que hallamos la solución! Ponemos un servicio Web a repartir SAS a las apps. Tal vez el servicio web haga alguna validación para decidir si responde positivamente al llamado. Y listo. La logramos!

    Esta situación la podríamos optimizar aún más. Dado que ahora la carga no será tan fuerte, podríamos entrar a analizar la posibilidad de usar web servers compartidos, disminuyendo enormemente los costos. Pero aquí tendremos que entrar a balancear costo contra disponibilidad.

    No sería mejor entonces tener un servicio pre-construido en la nube que ya nos proveyera la capacidad de emitir las SAS a las apps? Que nos quitara la necesidad de crear todo un web server para este fin?

    Sí, existe! Son los Windows Azure Mobile Services. Sevidores configurados para que clientes con una clave definida puedan entrar a escribir en unas tablas que quedan disponibles para este fin. Adicionalmente, también ofrecen servicios de Push Notifications y sobre ambos se pueden establecer estrategias para que solo usuarios autenticados puedan acceder a estos servicios.

    Subyacentemente, los Mobile Services tienen servidores web compartidos o dedicados que cuestan menos que los Web Sites de Azure. De hecho, hoy en día, se pueden tener hasta 10 Mobile Services gratuitamente. Estos servidores subyacentes, se pueden escalar a discreción. Aunque entonces parece que es lo mismo que tener los Web Servers tradicionales, la ventaja es que no tenemos que desplegar ningún código para que funcionen. La funcionalidad ya está en producción.

    No obstante, en las funcionalidades que mencioné, en ninguna está la del suministro de la SAS. Pero aquí es donde la imaginación u el ingenio juegan parte importante. Lo que sí mencioné es que se puede acceder a unas tablas a leerlas o modificarlas. Para ello se han dispuesto unas APIs especialmente diseñadas para WP y WinRT; hasta para iOS hay versión. Y en las tres plataformas pueden ser incluidas y usadas sin ningún problema de funcionamiento ni certificación cuando la app se sube al store. Pues bien, las operaciones CRUD que hacemos sobre estas tablas (que se pueden diseñar desde el portal de administración de Azure sin código alguno), están sujetas a que se ejecuten triggers que se disparán cuando nosotros lo especifiquemos. Por ejemplo, cuando haya una inserción. En últimas esto se puede tomar como un servicio web asíncrono, en el cual insertamos un request en la tabla y luego la volvemos a consultar para ver la respuesta obtenida, que obviamente se encontrará en otra columna.

    De esta manera, imaginen entonces que queremos subir una imagen al blob storage de Azure. Así que a modo de request, insertamos el nombre de esa imagen en una tabla de un Mobile Service previamente configurado, a través de las apis mencionadas.

    El servicio tiene un trigger sobre las inserciones. Y ese trigger detecta que hubo una inserción. Entonces ejecuta un código de servidor basado en Node.js (Javascript en el Server). Este código es suministrado por nosotros. Lo escribimos en el portal de administración de Azure; en la sección de configuración del servicio. Es así como podemos escribir un código que nos inserte en el mismo registro de la tabla la SAS que requerimos para acceder al container en el que queremos poner el archivo. Entonces cuando ordenamos la inserción asíncrona, pasamos el ítem a insertar y cuando termina esa inserción, podemos obervar que el ítem ya traerá la SAS que hemos generado.

    Luego usando esa SAS subimos el blob con tres líneas de código y ya está!

    En síntesis:

    Para poder acceder al storage de Azure desde apps sobre las cuales no tenemos control una vez han sido descargadas de las distintas tiendas de aplicaciones, la mejor alternativas es usar las SAS de Azure. La alternativa más cómoda y económica para obtener esas SAS, viene siendo los Mobile Services de Azure a través de las tablas de datos, ya que se proveen APIs de acceso a esas tablas que funcionan muy bien en WP7, Win8 y iOS. Con la SAS accedemos de manera segura para todos al storage.

    Una vez comprendido esto, continuemos con un paso a paso de cómo desplegar una solución de este tipo, en este post:

    Cómo adicionar archivos al Blob Storage de Windows Azure desde Windows Apps, a través de Mobile Services.

  • WarNov Developer Evangelist

    SQL Azure BACPAC - DB BACKUP en la nube (Nuevo Portal)

    • 0 Comments

    El formato de archivo BACPAC, se refiere a un nuevo tipo de archivo que contiene tanto el esquema, como los datos de una base de datos.

    En el Nuevo portal de Administración Windows Azure, en la sección de Bases de Datos, existe una opción para exportar una db existente, lo que nos produce un archive BACPAC que es almacenado en una de nuestras cuentas de almacenamiento de Azure. Además cuando se va a crear una nueva DB, se da la opción de importarla desde un BACPAC existente.

     

    Por ejemplo para exporter, nos ubicamos sobre la db a exporter y le damos click o tap a Export, lo que nos muestra el siguiente cuadro de diálogo:


    newbacpac


    Esta operación requiere una cuenta de almacenamiento de Windows Azure para guardar esa copia BACPAC en el blob storage. En este caso, debemos especificar los datos de la cuenta y el container dentro de esa cuenta donde va a quedar la copia BACPAC.

    Luego de especificar la cuenta, comienza a generarse la copia. Este es un proceso asíncrono, cuyo estado se puede consultar entrando a la sección de mensajes del portal:

    image

        

    Una vez creada la copia, podemos importer a través del botón que tiene ese nombre en la sección de Databases del portal, o a través de las opciones de crear una nueva DB:

    newimport1

    Luego de esto específicamos la ruta dentro del almacenamiento de Azure  donde dejamos el bacpac.

    newimport2


    newimport3

    Luego de esto, comienza la importación de la DB

    Lo mejor: Estas operaciones son susceptibles a ser automatizadas gracias al API de REST para acceder a los servicios de BACPAC; de esta forma, podemos programar los backups de nuestras DBs, y estos quedarán almacenados en el blob storage de Azure, que vale un centavo de dólar la giga al mes.

  • WarNov Developer Evangelist

    Cómo agregar y consultar info personalizada a Bing Maps

    • 0 Comments

    Bing Maps tiene abiertos sus servicios de mapeo, para que los desarrolladores puedan hacer uso de ellos. Como vemos en esa breve reseña del servicio, se tiene un tipo de cuenta gratuita (developer) para trabajar con estos servicios y otra paga (Enterprise).

    Cuando trabajamos con una cuenta de developer, solo podemos usar datos que ya tiene Bing Maps en sus bases de datos. Pero puede que nuestra necesidad de negocio requiera mapear puntos propios del negocio que no están en Bing Maps. Por ejemplo para tenerlos en un caché y que se dibujen siempre sin necesidad de requests adicionales a los servidores. Puede que además necesitemos obtener información personalizada y extendida de esos puntos personalizados y queramos hacver consultas sobre esa información. En ese caso, deberemos subir nuestra información a Bing Maps. Esta funcionalidad es brindada por Bing Spatial Data Services que solo es accesible en la versión Enterprise.

    Estos servicios proveen la funcionalidad de tener puntos de interés preestablecidos a través de fuentes de datos propias y generar diversas consultas tradicionales o geoespaciales sobre ellos. Aquí podemos encontrar algunos ejemplos de las implementaciones posibles.

     

    Las fuentes de datos personalizadas son accesibles muy fácilmente a través de directorios online que contienen ubicaciones (lat/long, campos de dirección y otros campos personalizados). Estos son creados cuando subimos y publicamos un archivo que contiene estos datos en un esquema estándar. Esto se hace a través del portal de Bing Maps o con el uso del API de administración de fuentes de datos.

    En conclusión, para poder manejar nuestros propios puntos como si fueran originarios de Bing Maps, hemos de subirlos a la nube de Bing Maps, a través de Bing Maps Data Services; una solución solo disponible para usuarios de tipo Enterprise.

  • WarNov Developer Evangelist

    Obteniendo lo mejor de Bing Maps en la Web

    • 1 Comments

    Los servicios de Mapas de Bing para desarrolladores nos ofrecen un conjunto enriquecido de herramientas para crear grandes experiencias basadas en mapas. Estos servicios están disponibles a través del veloz control de AJAX, una API de servicios basada en REST, un SDK para crear mash-ups y además SDKs móviles para Windows Phone, Android, iOS y  Windows 8.

    Enfocándonos ya en la alternativa para la web, a través del control de AJAX, existe un gran conjunto de operaciones disponibles que pueden apreciarse en vivo aquí. Podemos ver cómo se pueden crear mapas con sus opciones, añadir pushpins, figuras, capas, infoboxes, hacer consultas, ejecutar geolocalización, visualizar tráfico y direcciones para llegar, administrar datos espaciales y muchos más.

    Para usar estos servicios gratuitamente, se puede crear una cuenta de developer for free que permite el acceso a todas estas características siempre y cuando sea para sitios web públicos no protegidos con password con 125,000 sesiones o 500,000 transacciones por año. Esta es una excelente alternativa para probar los servicios, o usarlos en sitios públicos de un uso no tan alto.

    Sin embargo, ya en ambientes empresariales o de servicios a consumidores masivos, estos límites son sobrepasados y se requiere una alternativa más amplia. Esta se obtiene a través de una cuenta de tipo Enterprise, que es paga.

    Además de los límites de uso, otras ventajas que tienen las cuentas Enterprise las podemos encontrar aquí.

  • WarNov Developer Evangelist

    Cómo cambiar el nombre de una suscripción de Azure

    • 0 Comments

    Si ustedes como yo han tenido que manejar muchas cuentas y suscripciones de Azure al tiempo, habrán observado que muchas veces las suscripciones quedan con el mismo nombre y luego se hace muy difícil identificar cuál es cuál. Por ejemplo manejando las tools para consola bien sea desde Windows, Linux o MAC.

    Bien, esto se puede corregir sencillamente cambiando el nombre de la suscripción desde el portal de administración: https://account.windowsazure.com/subscriptions

    Allí se debe ingresar con la cuenta a través de la cual se adquirió el servicio (no es posible usar una cuenta de administrador asociada). Damos click sobre la suscripción que deseamos modificar y esto nos lleva al sumario de dicha suscripción. Al final de la página encontramos un conjunto de acciones disponibles:

    image

    De esas acciones escogemos Edit Subscription Details

    Y allí podremos cambiar el nombre de la suscripción y el administrador de la misma:

    image 

Page 1 of 1 (9 items)