Una vez que terminamos de desarrollar la aplicación, el último paso es hacer un deploy en Windows Azure.
Si nuestra aplicación usa el servicio de Storage de Azure, recomendamos primero correr la aplicación en forma local pero utilizando el Storage de Azure en vez del Storage local, como se indica en los últimos pasos de este post. De esta manera nos podemos asegurar de eliminar posibles errores relacionados con el Storage, de forma más fácil que subiendo toda la aplicación a Azure.
Finalmente, recomendamos este artículo para hacer el deploy completo de la aplicación. En nuestro caso nos fue de mucha utilidad activar IntelliTrace para detectar posibles bugs al momento de inicializar los web y worker roles.
Como última recomendación, si logramos hacer el deploy y todos los web y worker roles están en estado ready pero el sitio no se ve en el explorador o muestra un mensaje de error, agregar en el archivo web.config dentro del tag <system.web> lo siguiente: <customErrors mode="Off"/> . De esta forma podemos ver más detalles del error.
miércoles, 1 de diciembre de 2010
Azure Storage Explorer
Azure Storage Explorer es una herramienta muy útil para ver y alterar el contenido almacenado proyectos que usan Windows Azure storage.
Recomendamos utilizar esta aplicación para debuggear el contenido del storage. Se
configurarn los datos de la cuenta y permite acceder a todo lo que se tiene almacenado.
Con esta aplicación pueden ver y editas los 3 tipos de almacenamientos en la nube: blobs, queues y tables.
Para descargarlo y obtener más información acceder aqui.
Recomendamos utilizar esta aplicación para debuggear el contenido del storage. Se
configurarn los datos de la cuenta y permite acceder a todo lo que se tiene almacenado.
Con esta aplicación pueden ver y editas los 3 tipos de almacenamientos en la nube: blobs, queues y tables.
Para descargarlo y obtener más información acceder aqui.
lunes, 22 de noviembre de 2010
¿Cómo actualizar el estado en Twitter usando C#?
A continuación se mencionan tres librerías que pueden utilizarse para interactuar con la API de Twitter. Desde los sitos que se presentan a continuación se pueden descargar las librerías para ser utilizadas y encontrar algunos códigos de ejemplos.
Aquí un ejemplo paso a paso que utiliza TweetSharp y otras funciones para solucionar el problema de la autenticación. Una vez registrado se puede descargar el código fuente.
Acá un primer acercamiento que ofrece la página oficial de la API, en donde se mencionan lineamientos para utilizar OAuth para aplicaciones Desktop .
En este sitio se menciona lo problemático que es el uso de OAuth y brinda otro ejemplo que se basa en Hammock una de las librería que forman parte de TweetSharp. El código fuente también está disponible para ser descargado.
Otra librería interesante, no encontramos un ejemplo para resolver nuestro problema asi que tampoco ahondamos en su investigación.
Es bastante fácil de usar si se utilizan métodos que no necesitan autenticación, por ejemplo listar los últimos tweets públicos. Sin embargo todavía no hay ejemplos claros de cómo realizar la autenticación.
En este link podés encontrar otro ejemplo interesante para ver, en la que se muestra una aplicación desktop para postear un mensaje en Twitter. Puede descargarse el código fuente.
Problemas encontrados
¿Qué es OAuth? Se trata de un protocolo que permite asegurar la autorización de una API de forma simple y estándar para aplicaciones web y desktop.
Conclusiones
Las APIs disponibles son muy nuevas y están en pleno desarrollo. Hay escasa documentación y la mayoría de los sitios recién están empezando a tomar forma. Los códigos de ejemplos en algunos casos presentan errores o no están completos.
Las funciones de las APIs tampoco están bien documentadas, por lo que también es difícil entender sin un ejemplo cómo deben ser usadas las funciones.
Por otro lado, rápidamente se encuentran varios ejemplos que están obsoletos ya que no tienen en cuenta la autenticación necesaria que está vigente desde Agosto, por lo que ya no funcionan y los autores de dichos códigos no actualizan sus publicaciones.
Aquí un ejemplo paso a paso que utiliza TweetSharp y otras funciones para solucionar el problema de la autenticación. Una vez registrado se puede descargar el código fuente.
Acá un primer acercamiento que ofrece la página oficial de la API, en donde se mencionan lineamientos para utilizar OAuth para aplicaciones Desktop .
En este sitio se menciona lo problemático que es el uso de OAuth y brinda otro ejemplo que se basa en Hammock una de las librería que forman parte de TweetSharp. El código fuente también está disponible para ser descargado.
Otra librería interesante, no encontramos un ejemplo para resolver nuestro problema asi que tampoco ahondamos en su investigación.
Es bastante fácil de usar si se utilizan métodos que no necesitan autenticación, por ejemplo listar los últimos tweets públicos. Sin embargo todavía no hay ejemplos claros de cómo realizar la autenticación.
En este link podés encontrar otro ejemplo interesante para ver, en la que se muestra una aplicación desktop para postear un mensaje en Twitter. Puede descargarse el código fuente.
Problemas encontrados
La API de Twitter a partir del 16 de Agosto de este año, dejó de utilizar la autenticación básica para acceder a la API, y utiliza OAuth. Aquí se puede encontrar más información acerca de la autenticación que actualmente utiliza la API de Twitter.
¿Qué es OAuth? Se trata de un protocolo que permite asegurar la autorización de una API de forma simple y estándar para aplicaciones web y desktop.
Entrando aquí se puede acceder a la página oficial de OAuth.
Conclusiones
Las APIs disponibles son muy nuevas y están en pleno desarrollo. Hay escasa documentación y la mayoría de los sitios recién están empezando a tomar forma. Los códigos de ejemplos en algunos casos presentan errores o no están completos.
Las funciones de las APIs tampoco están bien documentadas, por lo que también es difícil entender sin un ejemplo cómo deben ser usadas las funciones.
Por otro lado, rápidamente se encuentran varios ejemplos que están obsoletos ya que no tienen en cuenta la autenticación necesaria que está vigente desde Agosto, por lo que ya no funcionan y los autores de dichos códigos no actualizan sus publicaciones.
Autenticación y autorización de usuarios
AppFabric Access Control (AC) es un servicio diseñado para brindar seguridad al resto de los web services. Simplifica el control de acceso permitiendo delegar la autenticación en otros servicios. Así el usuario no debe registrarse en nuestra aplicación, sino que utiliza las credenciales que ya tiene en otra aplicación web, como por ejemplo: Facebook, y esta se encarga de la autenticación y autorización correspondiente.
Arquitectura
El usuario solicita un token al ACS. Luego el ACS verifica que sea un usuario válido, y le devuelve un security token. Finalmente el web role verifica que el security token que le llega sea válido.
AppFabric AC se ocupa de la autenticación de usuarios, dándoles un token que prueba que fueron autenticados satisfactoriamente y contiene información acerca de sus permisos de acceso. Desde la aplicación solo es necesario verificar la presencia de ese token y ofrecer la funcionalidad que le corresponda según su perfil de usuario.
La interacción descripta anteriormente es comúnmente conocida como claims-based access, esto se debe a que los atributos del usuario incluidos en el token son claims. Un claim es una sentencia acerca de un usuario, provista por una autoridad competente. Si una aplicación recibe un claim a cerca de un usuario de una autoridad en la que confía, entonces esos claims se consideran confiables y se actúa de acuerdo a ellos. Este es un proceso bastante común, que se experimenta en la vida diaria, por ejemplo cuando se muestra el documento para probar la edad.
Arquitectura
El usuario solicita un token al ACS. Luego el ACS verifica que sea un usuario válido, y le devuelve un security token. Finalmente el web role verifica que el security token que le llega sea válido.
Implementación
Para implementar seguimos el tutorial propuesto en el Hands-on-labs del Windows Azure Training Kit: Introduction to the AppFabric Access Control.
lunes, 15 de noviembre de 2010
Alta, Baja y Modificación de eventos
Para el alta, baja y modificación de eventos vamos a tener un Web Role que se encargue de actualizar una tabla. Se va a mostrar una lista de los eventos, en donde se podrá borrar o actualizar su contenido. Un evento está formado por: nombre, descripción, artista, fecha y un contador (más adelante va a ser utilizado para listar los eventos más consultados). Cuando se agregue un evento nuevo, se va a publicar un mensaje en Twitter informando los datos del evento cargado.
Conceptos de Table Storage
El servicio de Windows Azure Table Storage provee un almacenamiento estructurado que puede ser consultado.
Cada entidad y la tabla tienen tres propiedades: un PartitionKey, un RowKey y un Timestamp, que conjuntamente forman la clave única para cada entidad. Los resultados son retornados ordenados por PartitionKey y luego por RowKey.
Arquitectura
Alta de eventos:
Un Evento está compuesto por:
- Artista
- Lugar
- Fecha
- Descripción
- Contador de visitas (Para listar los eventos más consultados, más adelante hablaremos más en detalle)
El web role almacena el evento en la tabla, y manda un mensaje al worker role mediante una cola de mensajes. El worker role se encarga de publicar el evento en Twitter.
Baja y Modificación de eventos:
Cuando se da de baja o modifica un evento, el web role se comunica con el storage para actualizar la tabla.
Implementación
Para orientarnos en la implementación seguimos este tutorial.
Problemas encontrados
Estuvimos teniendo problemas cuando queríamos actualizar los datos de un evento.
La excepción que obteníamos era: El valor del parámetro 'EventDate' no se puede convertir de 'System.String' a 'System.DateTime'.
- Descripción: Excepción no controlada al ejecutar la solicitud Web actual. Revise el seguimiento de la pila para obtener más información acerca del error y dónde se originó en el código.
- Detalles de la excepción: System.
InvalidOperationException: El valor del parámetro 'EventDate' no se puede convertir de 'System.String' a 'System.DateTime'
domingo, 14 de noviembre de 2010
La Arquitectura
Aquí vamos a detallar la arquitectura que plantemos para resolver los requerimientos de la aplicación.
Breve descripción de la aplicación
- Su funcionalidad principal es proveer un calendario de eventos
- Crear una comunidad en la que se pueda estar actualizado de los eventos y que permita la interacción de los usuarios mediante: comentarios, fotos, videos, entre otros.
- Ofrecer información detallada de los eventos
- Permitir búsquedas
Servicios de Windows Azure
Los servicios de Windows Azure que vamos a utilizar son:
- Compute
- Storage
- AppFabric Access Control
Detallando la arquitectura
Autenticación:
El usuario solicita un token al ACS. Luego el ACS verifica que sea un usuario válido, y le devuelve un security token. Finalmente el web role verifica que el security token que le llega sea válido.
Almacenar eventos:
Un Evento está compuesto por:
- Artista
- Lugar
- Fecha
- Descripción
- Contador de visitas (Para listar los eventos más consultados, más adelante hablaremos más en detalle)
El web role almacena el evento en la tabla, y manda un mensaje al worker role mediante una cola de mensajes. El worker role se encarga de publicar el evento en Twitter.
Baja y Modificación de eventos:
Cuando se da de baja o modifica un evento, el web role se comunica con el storage.
Listar eventos más consultados:
Cada vez que un evento es visto, el web role encola un mensaje indicando se debe incrementar el contador de ese evento. El worker role toma cierta cantidad de mensajes de la tabla y recién actualiza el contador. Cuando se utiliza cloud, se supone que la aplicación va a ser accedida por muchos usuarios, por eso no es recomendable actualizar cada vez la variable.
Publicar comentario:
Un comentario está compuesto por:
- Mensaje
- Usuario
- Url de la foto
- Url del thumbnail
Cuando un usuario publica un nuevo comentario, el web role carga la imagen al blob y crea una entrada en la tabla. También manda un mensaje al worker role a través de la cola. Luego el worker role se encarga de generar thumbnails, actualiza la tabla y guarda el thumbnail en el blob.
Suscribirse a:
Entradas (Atom)