Uno de los temas a tener en cuenta cuando empezamos a trabajar con Windows Azure es que una aplicación desplegada no puede ser depurada desde Visual Studio.

Por lo tando, si queremos depurar la aplicación que estamos desarrollando, tendremos que hacer uso del Development Fabric, que en la mayoría de los casos será más que suficiente para poder dejar fina la aplicación.

Pero hay veces que con esto no vale…que todo funciona bien en el entorno de desarrollo, pero si saber por qué no funciona de la misma manera desplegada en Windows Azure…¿Qué pasa?¿Cómo puedo diagnosticar el problema?

Pues aunque no existe la opción de depurar de forma directa desde Visual Studio, existe la posibilidad de utilizar la característica de Visual Studio "Intellitrace" para poder realizar una depuración desde Visual Studio.

Para aquellos que no conozcan la característica, se trata de una funcionalidad de Visual Studio 2010 que ofrece la posibilidad de realizar depuración histórica y es una parte clave para tratar los escenarios típicos dónde es muy difícil reproducir un determinado escenario. Podéis encontrar información sobre esta característica en el blog de Jose Luis Soria o simplemente en la MSDN.

Desde el punto de vista de Windows Azure la integración de IntelliTrace permite depurar problemas que ocurren en la nube pero que no son reproducibles en el entorno de desarrollo.

En el momento de desplegar una aplicación en Windows Azure desde Visual Studio se puede activar la característica, eso sí, sólo para aquellos roles que empleen el framework 4.0.

Llevo ya unos cuántos post hablando sobre Windows Azure y en varios de ellos os he hablado sobre diferentes herramientas que pueden ayudarnos enormemente, ya que como he comentado en más de una ocasión disponer de buenas herramientas en un punto clave para ser productivo en el trabajo diario.

Hoy os hablaré de Windows Azure Management Tool, un herramienta gratuita diseñada y creada para poder administrar los servicios y el sistema de almacenamiento de una cuenta de Windows Azure.

Esta herramienta provee de interesantes características que pueden simplificar enormemente el trabajo con Windows Azure:

• Permite realizar despliegues de servicios, actualizarlos y administrarlos.
• Permite configurar el sistema de diagnóstico de servicios hosteados en Windows Azure.
• Permite administrar los certificados disponibles en los servicios.
• Permite configurar las cuentas de almacenamiento.
• Permite la gestión de Blobs de Windows Azure; crear y eliminar contenedores, subir, eliminar o descargar blobs.
• Permite la gestión de Tablas de Windows Azure; consultar y borrar colas.
• Permite la gestión de las colas de Windows Azure; crear colas, purgarlas y borrar mensajes.

Si habéis intentado o intentáis hacer una aplicación con AppFabric usando el Framework 4.0 os daréis cuenta que no podéis.

Cuando se añaden los bindings propios de Service Bus al fichero de configuración éstos no se reconocen, no se reconocen las nuevas secciones que se necesitan para poder trabajar con Service Bus. Si por ejemplo, se emplean Framework 3.5 sí que se reconocen…

El problema radica en la instalación del SDK de AppFabric, que modifica el fichero machine.config, pero sólo para las versiones 2.0, 3.0 y 3.5….pero NO para 4.0!!!

Lógicamente, la solución pasa por incluir dichas secciones para 4.0.

Crear un fichero llamado RelayConfigurationInstaller.exe.config en “%Program Files%\Windows Azure platform AppFabric SDK\V1.0\Assemblies\”, directorio dónde se encuentran los ensamblados del SDK de AppFabric.

En este fichero hay que incluir lo siguiente:

<?xml version ="1.0"?>
<configuration>
  <startup>
    <requiredRuntime safemode="true"
                    imageVersion="v4.0.30319"
                    version="v4.0.30319"/>
  </startup>
</configuration>

Y una vez hecho esta acción, lanzar el siguiente comando RelayConfigurationInstaller.exe /i como administrador.

Dentro de los SQL Azure Labs se pueden encontrar, a modo de preview, algunas de lasfuncionalidades que llegarán pronto a SQL Azure.

Entre una de esas funcionalidades está la opción de poder exponer por OData el contenido de una base de datos SQL Azure.

Como seguro que ya sabéis muchos, OData es un protocolo basado en REST cuyo objetivo principal es buscar la interoperabilidad entre las aplicaciones para el intercambio de datos, independientemente de la tecnología…bueno, que OData ahora está de moda

Para el ejemplo parto de un servidor de SQL Azure creado desde mi cuenta de Azure, desde el portal de producción de Windows Azure. Después de crear el servidor he dado permisos en el firewall para que puedan conectarse aplicaciones que residan en la nube de Microsoft. Si alguien no sabe cómo hacerlo le recomiendo revisar estos post.

Dentro del servidor también he creado una base de datos con diferentes tablas y datos.

Una vez que tengo la base de datos creada en mi servidor de Azure, ya puedo ir al SQL Azure Labs y exponer la información por OData. Para ello el primer paso que tendré que realizar es conectarme al servidor y seleccionar la base de datos sobre la que deseo realizar la operación, como se muestra a continuación:

A través de la URI que te proporciona tendrías expuesto por OData las tablas de la base de datos. Para hacer la prueba permitir el acceso anónimo poniendo dbo en la selección del combo.

Fijaros que si queremos usar seguridad, sería AppFabric Access Control el que se encargaría del proceso de autenticación.

Y ya está, ya podéis consultar sobre la información expuesta.

Si ponemos un ejemplo de una petición REST en el navegador, veríamos algo como esto…

Lógicamente, también podríamos consultar la información desde una aplicación, esté hecho con .NET o con otra tecnología.

Disponibilidad, escalabilidad, tolerancia a fallos son algunos de los requisitos con los que nos encontramos habitualmente en muchas de las aplicaciones que desarrollamos y como seguro que ya sabéis, Windows Azure puede ser un gran aliado a la hora de conseguirlos.

A continuación incluyo un pequeño “tip” relativo a la disponibilidad de las aplicaciones…

Cuando desplegamos una aplicación en Windows Azure podemos elegir la versión del sistema operativo que deseamos emplear. Generalmente, la alternativa más habitual es desplegar sobre la última versión disponible en ese momento…

Pero…¿Qué tipo de actualización seleccionamos?¿Automática o Manual?¿Tiene alguna implicación para mi aplicación?

Si seleccionamos la opción de actualización automática, cada vez que haya una nueva versión del sistema operativo de Azure, las instancias dónde residen nuestra aplicación se actualizarán de forma automática. Si se actualiza, significa que durante un determinado período de tiempo, en tiempo de actualización, mi aplicación NO estará disponible.

El tiempo de actualización no tiene por qué ser largo pero es un período de inactividad de mi aplicación que no se puede controlar y no se sabe cuándo va a ocurrir.

En las aplicaciones que por carga necesite más de una instancia no tendré el problema porque si se actualiza una instancia la otra atenderás todas las peticiones de manera puntual.

Pero si a mí me vale con una instancia, por el tipo de aplicación que sea, tener que poner dos instancias sólo para protegerme de las actualizaciones del sistema operativo no sería práctico y además, sería el doble de caro

Solución? Pues a la hora de desplegar la aplicación seleccionar el modo manual y elegir la versión del sistema operativo. De esta manera, Windows Azure no realizará el proceso automático y tendremos que ser nosotros los que manualmente lo actualicemos cuando consideremos. Nosotros controlamos el proceso y el momento de inactividad de la aplicación.