octubre 2012 – O bruxo mobile

Azure: AAL + Web API, una mezcla ‘casi’ perfecta

En el post anterior empezamos a ver un poco sobre AAL, y como empezar a trabajar con este simple paquete. En esta ocasión, continuaremos hablando de AAL y de como juntarlo con ASP.NET Web API. Cuando uno diseña sus servicios utilizando Web API uno de los elementos que siempre entran en juego es la autorización en los mismos, de hecho, dándonos un pequeño paseo por la propia Web de ASP.NET Web API podemos ver diferente documentación acerca de este tema. A mayores, por supuesto, buceando en la web podemos obtener diferente información acerca de como realizar los procesos de authenticación, desde API Keys hasta OAuth . Todos estos procesos técnicamente se hacen de una forma o en otra, pero, tienen en común que ninguno externaliza el proceso de autenticación teniendo que incorporar nosotros este dentro de nuestras aplicaciones y por lo tanto, cuando necesitamos diferentes proveedores de identidad la cosa se complica. A lo largo de esta entrada intentaremos ver como construir un servicio de Web API que soporte a usuarios autenticados con diferentes proveedores de identidad como por ejemplo Azure AD, Office 365,ADFS 2, Windows Live, Google, nuestro propio STS etc, de una manera sencilla y sin apenas desarrollo.

Diseño

Una vez marcado el objetivo vamos a ver como realizamos esta tarea. En primer lugar necesitaremos que nuestro servicio disponga de un mecanismo para obtener y validar los tokens en las diferentes peticiones que al mismo se le realicen. Al igual que para el resto de ejemplos que hemos puesto en los enlaces anteriores, el mejor mecanismo para esto parece la creación de un DelegatingHandler. Tal y como podemos ver en la documentación mediante estas piezas podremos agregar procesamiento al pipeline de ejecución de ASP.NET Web API. Por lo tanto, nuestro objetivo es crear un manejador capaz de interceptar nuestro token y validarlo. Por supuesto una vez validado crearemos los correspondientes ClaimsPrincipal en el hilo de ejecución y el contexto Http para que puedan ser usados / revisados por el resto de elementos que componen la petición. Para seguir la norma, utilizaremos la cabecera Authorization como contenedor del token a validar. Una vez dicho esto el esqueleto de nuestra pieza podría ser algo como lo siguiente:

    <span class="kwrd">public</span> <span class="kwrd">class</span> AALMessageHandler
        : DelegatingHandler
    {
        <span class="kwrd">protected</span> <span class="kwrd">override</span> Task&lt;HttpResponseMessage&gt; SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            var authorization = request.Headers.Authorization;

            <span class="kwrd">if</span> (authorization != <span class="kwrd">null</span> &amp;&amp; authorization.IsAuthorizationSchema())
            {
                var token = authorization.Parameter;

                <span class="kwrd">if</span> (IsValidToken(token))
                {
                    <span class="rem">//set thread principal and http context user</span>
                }

            }

            <span class="kwrd">return</span> <span class="kwrd">base</span>.SendAsync(request, cancellationToken);
        }

        <span class="kwrd">bool</span> IsValidToken(<span class="kwrd">string</span> token)
        {
            <span class="rem">//validate the token</span>
        }
    }

public class AALMessageHandler

: DelegatingHandler

{

protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)

{

var authorization = request.Headers.Authorization;

if (authorization != null && authorization.IsAuthorizationSchema())

{

var token = authorization.Parameter;

if (IsValidToken(token))

{

//set thread principal and http context user

}

return base.SendAsync(request, cancellationToken);

}

bool IsValidToken(string token)

{

//validate the token

}

Con respecto a la parte de cliente no tenemos que hacer mucho más que en la anterior entrada, si acaso, lo único es ver como convertir nuestro Assertion Credential en un bearer token, pero esto con AAL es tan sencillo como podemos ver a continuación, gracias al método CreateAuthorizationHeader.

            <span class="kwrd">string</span> tenant = ConfigurationManager.AppSettings[<span class="str">&quot;tenant&quot;</span>];
            <span class="kwrd">string</span> realm = ConfigurationManager.AppSettings[<span class="str">&quot;realm&quot;</span>];

1 2	<span class="kwrd">string</span> tenant = ConfigurationManager.AppSettings[<span class="str">"tenant"</span>]; <span class="kwrd">string</span> realm = ConfigurationManager.AppSettings[<span class="str">"realm"</span>];

            <span class="kwrd">using</span>(AuthenticationContext context = <span class="kwrd">new</span> AuthenticationContext(tenant))
            {
                var credential = context.AcquireUserCredentialUsingUI(realm);
                
                <span class="kwrd">return</span> credential != <span class="kwrd">null</span> ? credential.CreateAuthorizationHeader() : <span class="kwrd">null</span>;
            }

using(AuthenticationContext context = new AuthenticationContext(tenant))

{

var credential = context.AcquireUserCredentialUsingUI(realm);

return credential != null ? credential.CreateAuthorizationHeader() : null;

}

El resultado de las líneas anteriores es que una vez un usuario es autenticado usado cualquiera de los proveedores de identidad configurados en nuestro Azure Access Control obtenemos un bearer token, representado en una cadena de texto. Un bearer token no es más que un token con la propiedad de que cualquier portador puede usar el token en los otros lugares, es decir, se elimina la necesidad de disponer de material criptográfico ( proof-of-possesion).

La implementacion

Bien, ahora que ya tenemos más o menos claro como haremos nuestro trabajo llega la hora de la implementación. Empezaremos por la parte más sencilla que es la parte de cliente, en la que además de las líneas anteriores pare obtener un token con AAL simplemente haremos una petición a un servicio de Web API cualquier, por ejemplo GET /API/Some.

            <span class="rem">//get the bearer token using AAL</span>
            var token = CreateToken();

            <span class="kwrd">if</span> (token != <span class="kwrd">null</span>)
            {
                <span class="rem">//create http client</span>
                var httpClient = HttpClientFactory.Create();
                httpClient.BaseAddress = <span class="kwrd">new</span> Uri(<span class="str">&quot;the base address of your web api project&quot;</span>);

                <span class="rem">//add default media type </span>
                httpClient.DefaultRequestHeaders.Accept.Add(
                    <span class="kwrd">new</span> MediaTypeWithQualityHeaderValue(<span class="str">&quot;application/json&quot;</span>));

                <span class="rem">//add the token</span>
                httpClient.DefaultRequestHeaders.Authorization = <span class="kwrd">new</span> AuthenticationHeaderValue(<span class="str">&quot;Authorization&quot;</span>, token);

                <span class="rem">//perform the request</span>
                var request = <span class="kwrd">new</span> HttpRequestMessage(HttpMethod.Get, <span class="str">&quot;api/some&quot;</span>);

                httpClient.SendAsync(request)
                        .ContinueWith((t) =&gt;
                        {
                            <span class="kwrd">if</span> (t.Result.IsSuccessStatusCode)
                            {
                                var content = t.Result.Content.ReadAsAsync&lt;IEnumerable&lt;<span class="kwrd">string</span>&gt;&gt;().Result;

                                <span class="rem">//display the secret content...</span>
                            }
                        }, TaskContinuationOptions.OnlyOnRanToCompletion);
            }

//get the bearer token using AAL

var token = CreateToken();

if (token != null)

{

//create http client

var httpClient = HttpClientFactory.Create();

httpClient.BaseAddress = new Uri("the base address of your web api project");

//add default media type

httpClient.DefaultRequestHeaders.Accept.Add(

new MediaTypeWithQualityHeaderValue("application/json"));

//add the token

httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Authorization", token);

//perform the request

var request = new HttpRequestMessage(HttpMethod.Get, "api/some");

httpClient.SendAsync(request)

.ContinueWith((t) =>

{

if (t.Result.IsSuccessStatusCode)

{

var content = t.Result.Content.ReadAsAsync<IEnumerable<string>>().Result;

//display the secret content...

}

}, TaskContinuationOptions.OnlyOnRanToCompletion);

}

Del código anterior, la nota a destacar es el uso de la cabecera con el token recuperado de la autenticación del usuario. Cabecera que viajará en todas las peticiones realizadas con nuestro HttpClient. En el caso del servidor, del esqueleto anterior tenemos que hacer dos trabajos fundamentales. La validación del token y el establecimiento de las credenciales recuperadas. Empezemos por la primera de las tareas. Gracias a AAL, la validación de un token es casi tan sencilla como la obtención del mismo, puesto que solamente tendremos que realizar lo siguiente:

         //if token is bearer remove text ‘Bearer ‘

          if ( token.StartsWith("Bearer ") )

                token =token.Substring(7);

var tenant = ConfigurationManager.AppSettings["tenant"];

1

var tenant = ConfigurationManager.AppSettings["tenant"];

            var authenticationContext = <span class="kwrd">new</span> AuthenticationContext(tenant);
            authenticationContext.Options = options;

            principal = authenticationContext.AcceptToken(token);

var authenticationContext = new AuthenticationContext(tenant);

authenticationContext.Options = options;

principal = authenticationContext.AcceptToken(token);

Antes de nada, disculpad por el pequeño toque con el texto Bearer del token, pero creí que era más entendible ponerlo así que tratarlo como sería en un código normal por medio de algún método de sanitización. Por supuesto, al método anterior tendremos que indicarle cuales son las opciones de autenticación, mediante nuestro objeto options, el cual podría ser algo similar a lo siguiente:

            var certString = ConfigurationManager.AppSettings[<span class="str">&quot;CertificateForAAL&quot;</span>];
            var certificate = <span class="kwrd">new</span> X509Certificate2(Convert.FromBase64String(certString));
            var options = <span class="kwrd">new</span> AuthenticationOptions();
            options.Audiences.Add(audience);
            options.Issuer = tenant;
            options.SigningCredential = <span class="kwrd">new</span> X509CertificateCredential(audience, certificate);

var certString = ConfigurationManager.AppSettings["CertificateForAAL"];

var certificate = new X509Certificate2(Convert.FromBase64String(certString));

var options = new AuthenticationOptions();

options.Audiences.Add(audience);

options.Issuer = tenant;

options.SigningCredential = new X509CertificateCredential(audience, certificate);

Por supuesto, el certificado seleccionado, está dado de alta en el portal de ACS en la sección Certificates and Keys, como se ven en la siguiente imagen.

El casi

Umm. el casi. Bueno, el primer motivo por el que esto no está perfecto es porque AAL solamente está compilada para WIF 3.5 y por lo tanto tendremos esta dependencia. Esto es una pena si trabajamos en VS 2012 y .NET 4.5 puesto que los elementos de Microsoft.IdentityModel ya los tendremos incluídos como hemos dicho ya muchas veces. A mayores, me queda por jugar un poco con el api de cliente para otras plataformas para ver como está y de verdad darle una nota sobresaliente… amén de que estamos en beta aún :-(.

Bueno, como siempre, espero que os sea de utilidad…

saludos

Unai

Home Realm Discovery en MVC 4 y Identity and Access Tool

En una anterior entrada, no muy lejana la verdad, vimos como configurar nuestro sitio construído en MVC 4 contra un ACS de Windows Azure para lograr la externalización de la autenticación y tener un modelo basado en claims de una forma terriblemente sencilla. Leyendo el blog de V Bertocci veo que la liberación de la RTM de la herramienta Identity and Access Tool incluye la posibilidad de que el proceso de Home Realm Discovey se pueda realizar nuestro propio sitio web en vez de tener la página por defecto para ese namespace en Windows Azure, y así, lograr una experiencia más agradable al usuario y un mismo diseño para nuestra web y esta vista. El proceso para realizar esto es realmente sencillo, no voy a volver a realizar los paso comunes a la anterior entrada, la dejor para su lectura. Lo único que haremos es fijarnos como ahora, en esta nueva versión de la herramienta disponemos de una opción para crear un controlador y una vista para tener el HRD en nuestro sitio, como acabamos de comentar.

Esta opción, que podemos ver en la imagen de la derecha nos permitirá seleccionar tanto el nombre del controlador como de la acción que queremos que hagan el trabajo. Una vez seleccionada, al aceptar el paso veremos como una serie de elementos son agregados a nuestro sitio MVC 4, concrétamente los siguientes:

Un nuevo controlador, por defecto llamado HrdAuthenticationController
Una nueva accion al controlador anterior llamado Login
Una vista para la acción Login
Un script de javascript llamado HrdAuthentication.js

A continuación, haremos un breve repaso de que contiene cada uno de estos elementos. En primer lugar el controlador como veremos es realmente sencillo, puesto que su código únicamente contiene lo siguiente.

    <span class="kwrd">public</span> <span class="kwrd">class</span> HrdAuthenticationController : Controller
    {
        [AllowAnonymous]
        <span class="kwrd">public</span> ActionResult Login()
        {
            ViewBag.MetaDataScript = <span class="str">"https://geeksms.accesscontrol.windows.net/v2/metadata/identityProviders.js?protocol=wsfederation&amp;realm=http://localhost:13021/&amp;version=1.0&amp;callback=ShowSigninPage"</span>;
            <span class="kwrd">return</span> View(<span class="str">"~/Views/HrdAuthentication/Login.cshtml"</span>);
        }
    }

public class HrdAuthenticationController : Controller

{

[AllowAnonymous]

public ActionResult Login()

{

ViewBag.MetaDataScript = "https://geeksms.accesscontrol.windows.net/v2/metadata/identityProviders.js?protocol=wsfederation&realm=http://localhost:13021/&version=1.0&callback=ShowSigninPage";

return View("~/Views/HrdAuthentication/Login.cshtml");

}

&nbsp;

Como puede observar, no hay nada en especial, solamente la entrada de nuestro ViewBag MetaDataScript el cual contiene la Url de un script js alojado en nuestro ACS en la que hay una callback ( jsonp ) a un función llamada ShowSigninPage. Si buscamos en el javascript HrdAuthentication.js veremos que el contenido del mismo trae precisamente esta función.

// // Code generated by Identity and Access VS Package // function ShowSigninPage(IPs) { $.each(IPs, function (i, ip) { $("#IPDiv").append('<a href="' + ip.LoginUrl + '">' + ip.Name + '</a> '); }); };

1
2
3
4
5
6
7
8
9

// 
// Code generated by Identity and Access VS Package
// 

function ShowSigninPage(IPs) {
 $.each(IPs, function (i, ip) {
 $("#IPDiv").append('<a href="' + ip.LoginUrl + '">' + ip.Name + '</a> ');
 });
};

Fíjese como es en esta función dónde se definen como se construyen los enlaces a los diferentes Identity Providers y por lo tanto, podría ser un punto de toque al querer estilizar nuestra visa. Para terminar, el código de la vista también es terriblemente sencillo, puesto que solamente incorporar los dos js mencionados anteriormente, amén del div IPDiv usado.

@* Code generated by Identity and Access VS Package *@ <hgroup class="title"> <h1>Log in</h1> <h2> using one of the identity providers below</h2> </hgroup> <div id="IPDiv"/> @section Scripts { @Scripts.Render("~/scripts/HrdAuthentication.js"); <script src="@ViewBag.MetaDataScript" type="text/javascript"></script> }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@*
Code generated by Identity and Access VS Package
*@

<hgroup class="title">
 <h1>Log in</h1>
 <h2> using one of the identity providers below</h2>
</hgroup>

<div id="IPDiv"/>

@section Scripts {
 @Scripts.Render("~/scripts/HrdAuthentication.js");

 <script src="@ViewBag.MetaDataScript" type="text/javascript"></script>
}

Sencillo verdad? y todo sigue funcionando perfectamente.

Ha sido una entrada pequeña, pero creo que muy interesante este pequeño descubrimiento…

Saludos

Unai

Azure: Windows Azure Authentication Library

Como seguro que todos los que leéis mi blog sabréis, el manejo de la identidad es un tema que me apasiona y sobre el que ya he escrito mucho. De hecho, ahora mismo me encuentro en fase de preparación sobre un libro acerca del manejo de la identidad, que espero en poco tiempo esté a vuestra disposición de forma gratuita. Pues bien, desde hace un tiempo para aquí sobre este tema se ha avanzado mucho en plataforma Microsoft, tanto que a veces no damos ni seguido ciertos elementos, como por ejemplo era mi caso con AAL ( Azure Authentication Library), por eso, para intentar remediar este inconveniente, empezaré una serie de post acerca de este temática que nos permitan ver todo el trabajo que el equipo de Windows Azure está haciendo sobre esto, centrándonos especialmente en los siguientes puntos

Azure Authentication Library

AAL, es básicamente un paquete de NuGet que nos habilita un serie de ensamblados para realizar alguna de las siguientes tareas:

Gestión de tokens, generalmente server to server

Autenticación con Azure AD, Azure ACS y ADFS 2.0 y otros proveedores

Validación de tokens

Como en casi todo lo que tenga que ver con la identidad y su gestión, una de las principales fuentes ( a mayores de lo que yo mismo pueda ir masticando y contando en este blog ) es el blog de Vittorio Bertoci, el cual recomiendo encarecidamente puesto que, tal y como acabo de decir, es siempre una de mis fuentes principales de información y aprendizaje.

Windows Azure Active Directory

El segundo de los temas que trataremos es Azure Active Directory junto con dos elementos fundamtales como Graph API y Web Single Sign-ON.

Con el fin de que esta entrada no se quede en una mera entrada informativa, no me parece muy adecuado, empezaremos por sentar las bases de AAL y desgranar algunos conceptos.

AAL

¿Que es AAL y para que sirve? Aunque, ya lo explicamos un poco en las líneas anterior hay una frase de Vittorio que creo que da una buena explicación de que es y para que no sirve esta nueva librería.”AAL viene a dar solución a algunas de las tareas que los desarrolladores necesitan para manejar la autenticación;asumiendo para ello que no tenemos un profundo conocimiento del protocolo en juego”. Para utilizar AAL solamente tenemos que instalar el paquete Windows Azure Authentication Library BETA gracias al cual incorporaremos a nuestro proyecto la librería Microsoft.WindowsAzure.ActiveDirectory.Authentication.dll cuyo contenido puede verse de forma resumida en la siguiente imagen.

Con el fin de empezar con un pequeño detalle que nos muestre alguna de sus características haremos un pequeño ejemplo en una aplicación de Windows Forms terriblemente sencilla, tanto que lo único que tendremos es un boton con el siguiente manejador.

           <span class="kwrd">using</span> (var context = <span class="kwrd">new</span> AuthenticationContext(<span class="str">&quot;https://identity45.accesscontrol.windows.net&quot;</span>))
           {
                var credentials = context.AcquireUserCredentialUsingUI(<span class="str">&quot;urn:geeksmsaalsample&quot;</span>);
           }

using (var context = new AuthenticationContext("https://identity45.accesscontrol.windows.net"))

{

var credentials = context.AcquireUserCredentialUsingUI("urn:geeksmsaalsample");

}

Dónde “https://identity45.accesscontrol.windows.net” representa el namespace de nuestro servicio de Azure Access Control Service y “urn:geeksmsaalsample” es el realm de nuestra aplicación. Si simplemente con eso ejecutamos nuestra aplicación veremos como se nos mostrará una pequeña ventana que contendrá el siguiente mensaje de error:

Este mensaje de error se debe a la inexistencia en la configuración de nuestro namespace de access control service de un RP con este REALM. Para arreglarlo nos vamos a nuestra configuración de Azure y creamos un nuevo Relay Party, en nuestro ejemplo tan simple como se ve a continuación.

Una vez creado, ahora si se nos presentarán los diferentes proveedores de identidad configurados en Azure ACS para esta nueva RP y nos podremos autenticar de esta forma tan sencilla utilizando distintos proveedores tal y como se ven en las siguientes imagenes. Aunque no lo hemos comentado, en el paso anterior hay que especificar las reglas de este RP, en nuestro ejemplo hemos puesto un passthrough de los proveedores de identidad configurados.

Tal y como observá, el proceso que hemos hecho es idéntico al proceso de dar de alta Access Control Service para un proyecto web ahora en un cliente rico de una manera insultantemente sencilla. Es más, si observa en el tipo de resultado AssertionCredential este nos permite generar un token para ser utilizado en servicios OAuth o para enviar este token a nuestros servicios, por ejemplo web api,que después, podrán validar también utilizando este mismo paquete.

            <span class="kwrd">using</span> (var context = <span class="kwrd">new</span> AuthenticationContext(<span class="str">&quot;https://identity45.accesscontrol.windows.net&quot;</span>))
            {
                <span class="rem">//authenticate and return credentials</span>
                var credentials = context.AcquireUserCredentialUsingUI(<span class="str">&quot;urn:geeksmsaalsample&quot;</span>);

                <span class="kwrd">if</span> (credentials != <span class="kwrd">null</span>) <span class="rem">//the user is logged!</span>
                {
                    <span class="rem">//get token to use in com to server</span>
                    var token = credentials.CreateAuthorizationHeader();
                }
            }

using (var context = new AuthenticationContext("https://identity45.accesscontrol.windows.net"))

{

//authenticate and return credentials

var credentials = context.AcquireUserCredentialUsingUI("urn:geeksmsaalsample");

if (credentials != null) //the user is logged!

{

//get token to use in com to server

var token = credentials.CreateAuthorizationHeader();

}

Bueno, aquí lo dejamos, si le ha gustado, no se preocupe porque pronto volveremos al ataque con más y esperemos que mejor…

Saludos

unai

Windows Azure Storage Account Monitoring and Logging

Aunque era algo que ya teníamos en el antiguo portal de Windows Azure, sin duda, una de las cosas más interesantes que nos ofrece la nueva versión es la facilidad para manejar la monitorización de los distintos elementos disponibles, entre ellos las cuantas de Storage. Como puede observar en la siguiente imagen, la interfaz nos permite de una forma sencilla habilitar la monitorización para los diferentes elementos de un storage ( blob, queues y tables ). En ocasiones, disponer de el portal de azure como herramienta de trabajo principal no es posible, imagine que usted esta usando la infraestructura de azure para terceros y que desea en sus propias herramientas habilitar y ver toda esta información de monitorización. En estos casos, necesitamos de un mecanismo para poder habilitar de forma programática la configuración de monitorización, y, por supuesto, también necesitaremos un mecanismos para ver los diferentes valores de las métricas de esta configuración.

Por suerte, todo lo que tenemos disponible en el portal lo tenemos disponible nosotros, puesto que en teoría este portal está construido con el mismo API que nosotros tenemos a nuestra disposición. Por lo tanto vamos a intentar realizar dos pasos, configuración de la monitorización y revisión de las métricas sin necesidad de utilizar el portal de azure. por supuesto el código es meramente demostrativo, como casi siempre en los posts, y tendrá muchas posibilidades de mejora, pero ya le queda a usted estimado lector para ganarse su trabajo;

Configuración de la monitorización

Para realizar la configuración de la monitorización utilizaremos uno de esos N API Rest que Azure nos pone a nuestra disposición, en concreto el API rest referido a los servicios de Blob, Queues y/o Tables, dependiendo de que monitorización querramos habilitar. En el siguiente enlace puede ver el caso concreto del servicio de blob Set Blob Service Properties gracias al cual podremos hacer este trabajo. En realidad el API para los diferentes elementos solamente presenta cambios en la url ( los segmentos blob,queues o tables dependiendo del servicio ) y el modo de autenticación.

Según el método mencionado anteriormente, para habilitar la configuración solamente tendremos que realizar una petición PUT a laa url .blob.core.windows.net/?restype=service&comp=properties">.blob.core.windows.net/?restype=service&comp=properties">.blob.core.windows.net/?restype=service&comp=properties">.blob.core.windows.net/?restype=service&comp=properties">http://<account-name>.blob.core.windows.net/?restype=service&comp=properties

utilizando un cuerpo de mensaje similar al siguiente fragmento (extraído del enlace anterior )

&lt;?xml version=<span class="str">"1.0"</span> encoding=<span class="str">"utf-8"</span>?&gt;
&lt;StorageServiceProperties&gt;
    &lt;Logging&gt;
        &lt;Version&gt;version-number&lt;/Version&gt;
        &lt;Delete&gt;<span class="kwrd">true</span>|<span class="kwrd">false</span>&lt;/Delete&gt;
        &lt;Read&gt;<span class="kwrd">true</span>|<span class="kwrd">false</span>&lt;/Read&gt;
        &lt;Write&gt;<span class="kwrd">true</span>|<span class="kwrd">false</span>&lt;/Write&gt;
        &lt;RetentionPolicy&gt;
            &lt;Enabled&gt;<span class="kwrd">true</span>|<span class="kwrd">false</span>&lt;/Enabled&gt;
            &lt;Days&gt;number-of-days&lt;/Days&gt;
        &lt;/RetentionPolicy&gt;
    &lt;/Logging&gt;
    &lt;Metrics&gt;
        &lt;Version&gt;version-number&lt;/Version&gt;
        &lt;Enabled&gt;<span class="kwrd">true</span>|<span class="kwrd">false</span>&lt;/Enabled&gt;
        &lt;IncludeAPIs&gt;<span class="kwrd">true</span>|<span class="kwrd">false</span>&lt;/IncludeAPIs&gt;
        &lt;RetentionPolicy&gt;
            &lt;Enabled&gt;<span class="kwrd">true</span>|<span class="kwrd">false</span>&lt;/Enabled&gt;
            &lt;Days&gt;number-of-days&lt;/Days&gt;
        &lt;/RetentionPolicy&gt;
    &lt;/Metrics&gt;
    &lt;!-- The DefaultServiceVersion element can only be set <span class="kwrd">for</span> the Blob service and the request must be made <span class="kwrd">using</span> the 2011-08-18 version --&gt;
    &lt;DefaultServiceVersion&gt;<span class="kwrd">default</span>-service-version-<span class="kwrd">string</span>&lt;/DefaultServiceVersion&gt;
&lt;/StorageServiceProperties&gt;

<?xml version="1.0" encoding="utf-8"?>

<Version>version-number</Version>

<Delete>true|false</Delete>

<Read>true|false</Read>

<Write>true|false</Write>

<Enabled>true|false</Enabled>

<Days>number-of-days</Days>

</RetentionPolicy>

</Logging>

<Version>version-number</Version>

<Enabled>true|false</Enabled>

<IncludeAPIs>true|false</IncludeAPIs>

<Enabled>true|false</Enabled>

<Days>number-of-days</Days>

</RetentionPolicy>

</Metrics>

<DefaultServiceVersion>default-service-version-string</DefaultServiceVersion>

</StorageServiceProperties>

Pues bien, vamos a intentarlo:

Para generar el XML anterior utilizaremos una serialización XML de las clases siguientes, las cuales, representan como verá este sencillo fragmento. Por supuesto, usted puede crear cualquier otro mecanismo, para conseguir tener este fragmento de XML. [Si utiliza XmlSerializer no se olvide de utilizar XmlSerializerNamespace para eliminar los namespaces que este serializador incluye por defecto]

    <span class="kwrd">public</span> <span class="kwrd">class</span> StorageServiceProperties
    {
        <span class="kwrd">public</span> Logging Logging { get; set; }
        <span class="kwrd">public</span> Metrics Metrics { get; set; }
    }
    <span class="kwrd">public</span> <span class="kwrd">class</span> Metrics
    {
        <span class="kwrd">public</span> <span class="kwrd">string</span> Version { get; set; }
        <span class="kwrd">public</span> <span class="kwrd">bool</span> Enabled { get; set; }
        <span class="kwrd">public</span> <span class="kwrd">bool</span> IncludeAPIs { get; set; }
        <span class="kwrd">public</span> RetentionPolicy RetentionPolicy { get; set; }
    }
    <span class="kwrd">public</span> <span class="kwrd">class</span> Logging
    {
        <span class="kwrd">public</span> <span class="kwrd">string</span> Version { get; set; }
        <span class="kwrd">public</span> <span class="kwrd">bool</span> Delete { get; set; }
        <span class="kwrd">public</span> <span class="kwrd">bool</span> Read { get; set; }
        <span class="kwrd">public</span> <span class="kwrd">bool</span> Write { get; set; }
        <span class="kwrd">public</span> RetentionPolicy RetentionPolicy { get; set; }
    }
    <span class="kwrd">public</span> <span class="kwrd">class</span> RetentionPolicy
    {
        <span class="kwrd">public</span> <span class="kwrd">bool</span> Enabled { get; set; }
        <span class="kwrd">public</span> <span class="kwrd">int</span> Days { get; set; }
    }

public class StorageServiceProperties

{

public Logging Logging { get; set; }

public Metrics Metrics { get; set; }

}

public class Metrics

{

public string Version { get; set; }

public bool Enabled { get; set; }

public bool IncludeAPIs { get; set; }

public RetentionPolicy RetentionPolicy { get; set; }

}

public class Logging

{

public string Version { get; set; }

public bool Delete { get; set; }

public bool Read { get; set; }

public bool Write { get; set; }

public RetentionPolicy RetentionPolicy { get; set; }

}

public class RetentionPolicy

{

public bool Enabled { get; set; }

public int Days { get; set; }

}

Para la petición utilizaremos HttpWebRequest o cualquier API de cliente como HttpClient o RestSharp. En nuestro caso, para no molestar al lector con otras API diferente a las habituales optaremos por el uso de la primera opción, aunque habitualmente haga uso de RestSharp para este tipo de tareas. A lo largo de las siguientes lineas, veremos como realizar la petición solicitada por el API mencionado anteriormente.

            <span class="rem">//create the http request and set default headers</span>
            <span class="kwrd">string</span> baseUri = <span class="kwrd">string</span>.Format(<span class="str">"http://{0}.blob.core.windows.net/?restype=service&amp;comp=properties"</span>, accountName);

            var request = (HttpWebRequest)HttpWebRequest.Create(baseUri);
            request.Headers.Add(<span class="str">"x-ms-version"</span>, <span class="str">"2009-09-19"</span>);
            request.Method = <span class="str">"PUT"</span>;

            <span class="rem">//set the content length from settings</span>
            var bytes = UTF8Encoding.UTF8.GetBytes(settings);
            request.ContentLength = bytes.Length;

//create the http request and set default headers

string baseUri = string.Format("http://{0}.blob.core.windows.net/?restype=service&comp=properties", accountName);

var request = (HttpWebRequest)HttpWebRequest.Create(baseUri);

request.Headers.Add("x-ms-version", "2009-09-19");

request.Method = "PUT";

//set the content length from settings

var bytes = UTF8Encoding.UTF8.GetBytes(settings);

request.ContentLength = bytes.Length;

En estas lineas, él único trabajo que hemos realizado es la creación de un request a la dirección dada y seteados los valores de cabeceras como “x-ms-version” obligatorias según la información que el API nos ofrece. El siguiente paso, es establecer la cabecera de authorización, proceso que no es simple como podemos ver en los esquemas de autenticación de Windows Azure pero que resolveremos de una forma terriblemente simple gracias a la clase StorageCredentialsAccountAndKey y a su método SignRequest.

            var storageCredentials = <span class="kwrd">new</span> StorageCredentialsAccountAndKey(accountName,mystorageaccountprimarykey);
            storageCredentials.SignRequest(request);

1 2	var storageCredentials = <span class="kwrd">new</span> StorageCredentialsAccountAndKey(accountName,mystorageaccountprimarykey); storageCredentials.SignRequest(request);

Bien, ya solamente tenemos que escribir el cuerpo de la petición y obtener la respuesta, y esto, es idéntico a cualquier petición que ya hubiéramos hecho con HttpWebRequest. anteiormente.

            request.GetRequestStream().Write(bytes, 0, bytes.Length);
            

            var response = request.GetResponse();

request.GetRequestStream().Write(bytes, 0, bytes.Length);

var response = request.GetResponse();

Consulta de las métricas

A lo largo de las líneas anteriores hemos visto como habilitar la monitorización de una cuenta de storage de una forma simple. Pero, aún nos queda el elemento importante, que no es otro que la recuperación de los valores de las diferentes métricas que hemos habilitado. Como se ha podido imaginar de las líneas anteriores, la activación/configuración se realiza a nivel de servicio ( para blob, queue, tables ) no para la cuenta de storage. Las métricas de estos diferentes servicios las posemos categorizar en los siguientes puntos:

Métricas de transacciones – Expuesta, tal y como se puede ver aquí, en tres tablas fundamentales:

- $MetricsTransactionBlob
- $MetricsTransactionsTable
- $MetricsTransactionsQueue

Métricas de capacidad – Expuestas, tal y como se puede ver aqui, en la siguiente tabla:

- $MetricsCapacityBlob

Para consultar los esquemas de las diferentes tablas de métricas podemos acudir a la MSDN dónde obtendremos la información necesaria. En realidad, no tiene demasiada historia, por lo menos no mucho más que trabajar con cualquier Table Service de Azure. En nuestro caso, por ver un ejemplo, haremos lo siguiente, el mapeo de una entidad para trabajar con $MetricsTransactionsBlob, tal cual nos dice la documentación, y una consulta de todos los contadores usando un TableServiceContext.

            var entitySetName = <span class="str">"$MetricsTransactionsBlob"</span>;

            var client = storageAccount.CreateCloudTableClient();

            <span class="kwrd">if</span> (client.DoesTableExist(entitySetName))
            {
                var context = client.GetDataServiceContext();
                var data = context.CreateQuery&lt;StorageMetrics&gt;(entitySetName)
                                .ToList();
            }

var entitySetName = "$MetricsTransactionsBlob";

var client = storageAccount.CreateCloudTableClient();

if (client.DoesTableExist(entitySetName))

{

var context = client.GetDataServiceContext();

var data = context.CreateQuery<StorageMetrics>(entitySetName)

.ToList();

}

public class StorageMetrics : TableServiceEntity { public string TotalRequests { get; set; } public StorageMetrics() { } }

1
2
3
4
5

 public class StorageMetrics : TableServiceEntity
 {
 public string TotalRequests { get; set; }
 public StorageMetrics() { }
 }

Espero que os haya resultado de interés..

Saludos

unai

Azure Service Bus : Topic Brokered Message

En las entradas anteriores ( I,II y III ) vimos una pequeña introducción a las colas de Service Bus y ya empezamos a hablar, ligeramente de los Topics. A lo largo de esta entrada ( en esta ocasión el tema no da para una serie) veremos más detenido el concepto de Topic.

Multiples lectores/subscriptores

Este título es el concepto que define un Topic de la mejor forma. En muchas ocasiones, necesitamos que un mismo mensaje de una cola pudiera ser procesado por múltiples clientes, por ejemplo para que cada uno de ellos le pudiera dar un tratamiento diferente. Por poner un ejemplo, imagínese que está construyendo un sistema de procesado de datos en tiempo real y que cada dato tiene que ser procesado para diferentes tareas, compresión y almacenado, agregación e historización. Si tenemos una cola para realizar todas las tareas será dificil separar las responsabilidades del receptor, en aquellas que hemos definido en nuestra premisa. Sin embargo, si pudiéramos tener diferentes lectores para cada uno de los mensajes podríamos tener un Subscriptor para leer mensajes e historiarlos, otro Subscriptor para leer mensajes y agregarlos y otro Subscriptor más para comprimirlos y almacenarlos así conseguiríamos dividir las responsabilidades en partes simples y por lo tanto más mantenibles. Los topics en poco se diferencian de las colas, de hecho, su API es prácticamente idéntico y disponen casi de las mismas características, tamaños de cola, formateadores, detección de duplicados. A continuación veremos el código necesario para la creación y envió de un mensaje a un Topic.

            <span class="rem">// The connection string for namespace manager is stored</span>
            <span class="rem">// in Microsoft.ServiceBus.ConnectionString app settings key</span>
            var namespaceManager = NamespaceManager.Create();

            <span class="rem">//create topic</span>
            var topicDescription = namespaceManager.CreateTopic(<span class="str">"topic"</span>);

            <span class="rem">//add subscriptions</span>
            var historizationSubscription = namespaceManager.CreateSubscription(<span class="str">"topic"</span>, <span class="str">"Historization"</span>);
            var storeSubscription = namespaceManager.CreateSubscription(<span class="str">"topic"</span>, <span class="str">"Store"</span>);
            var aggregateSubscription = namespaceManager.CreateSubscription(<span class="str">"topic"</span>, <span class="str">"Aggregate"</span>);

// The connection string for namespace manager is stored

// in Microsoft.ServiceBus.ConnectionString app settings key

var namespaceManager = NamespaceManager.Create();

//create topic

var topicDescription = namespaceManager.CreateTopic("topic");

//add subscriptions

var historizationSubscription = namespaceManager.CreateSubscription("topic", "Historization");

var storeSubscription = namespaceManager.CreateSubscription("topic", "Store");

var aggregateSubscription = namespaceManager.CreateSubscription("topic", "Aggregate");

Si se para y recuerda el trabajo con las colas observará como es prácticamente idéntico a lo que ya conocíamos de entradas anteriores, con la salvedad de que además de la creación del topic también se ha procedido a la creación de las diferentes subscripciones de las que hablábamos anteriormente. Con respecto al envío de mensajes en este caso no hay nada particular ni diferente respecto al uso de colas.

            var messagingFactory = MessagingFactory.Create();
            var topic = messagingFactory.CreateTopicClient(<span class="str">"topic"</span>);

            topic.Send(<span class="kwrd">new</span> BrokeredMessage(<span class="str">"the content"</span>));

var messagingFactory = MessagingFactory.Create();

var topic = messagingFactory.CreateTopicClient("topic");

topic.Send(new BrokeredMessage("the content"));

El código para la recepción de mensajes en cada subscripción podría ser algo como lo siguiente:

            var messagingFactory = MessagingFactory.Create();
            var subcriptor = messagingFactory.CreateSubscriptionClient(<span class="str">"topic"</span>, <span class="str">"Historization"</span>);

            var content = subcriptor.Receive().GetBody&lt;<span class="kwrd">string</span>&gt;();

var messagingFactory = MessagingFactory.Create();

var subcriptor = messagingFactory.CreateSubscriptionClient("topic", "Historization");

var content = subcriptor.Receive().GetBody<string>();

Filtros

En los pasos anteriores hemos visto los elementos fundamentales del trabajo con los topics. Sin embargo no hemos hablado de una característica fundamental para los subscriptores que es la capacidad de filtrar los mensajes que quieren recibir. Por ejemplo, podríamos decidir que el subscriptor de agregación solamente recibiera aquellos mensajes con valores de señales que pudieran agregarse ( SUM,AVG, MAX … ) . Estos filtros, representados por la clase Filter, y más concretamente por SqlFilter, nos permiten “filtrar” en función de las propiedades de los mensajes y usuario. El nombre de SqlFilter viene dado por la posibilidad de utilizar SQL92 como norma para los filtros.

&lt;predicate ::=
{ NOT &lt;predicate&gt; }
| &lt;predicate&gt; AND &lt;predicate&gt;
| &lt;predicate&gt; OR &lt;predicate&gt;
| &lt;expression&gt; { = | &lt;&gt; | != | &gt; | &gt;= | &lt; | &lt;= } &lt;expression&gt;
| &lt;property&gt; IS [NOT] NULL
| &lt;expression&gt; [NOT] IN ( &lt;expression&gt; [, ...n] )
| &lt;expression&gt; [NOT] LIKE &lt;pattern&gt; [ESCAPE &lt;escape_char&gt;]
| EXISTS ( &lt;property&gt; )
| ( &lt;predicate&gt; )
 
&lt;expression&gt; ::=
&lt;constant&gt; 
| &lt;property&gt;
| &lt;expression&gt; { + | - | * | / } &lt;expression&gt;
| { + | - } &lt;expression&gt;
| ( &lt;expression&gt; )

<predicate ::=

{ NOT <predicate> }

| <predicate> AND <predicate>

| <predicate> OR <predicate>

| <expression> { = | <> | != | > | >= | < | <= } <expression>

| <property> IS [NOT] NULL

| <expression> [NOT] IN ( <expression> [, ...n] )

| <expression> [NOT] LIKE <pattern> [ESCAPE <escape_char>]

| EXISTS ( <property> )

| ( <predicate> )

<expression> ::=

| <property>

| <expression> { + | - | * | / } <expression>

| { + | - } <expression>

| ( <expression> )

Con el fin de poner un ejemplo podremos ver el siguiente tip, donde se muestra la creación de un filtro para la subscripción y el envío de un mensaje con esta propiedad:

var aggregateSubscription = namespaceManager.CreateSubscription("topic", "Aggregate", new SqlFilter("RequireAggregate=true"));<style type="text/css"></style>

1

var aggregateSubscription = namespaceManager.CreateSubscription("topic", "Aggregate", new SqlFilter("RequireAggregate=true"));<style type="text/css"></style>

            var message = <span class="kwrd">new</span> BrokeredMessage(<span class="str">"the content"</span>);
            message.Properties[<span class="str">"RequireAggregate"</span>] = <span class="kwrd">true</span>;

            topic.Send(<span class="kwrd">new</span> BrokeredMessage(<span class="str">"the content"</span>));

var message = new BrokeredMessage("the content");

message.Properties["RequireAggregate"] = true;

topic.Send(new BrokeredMessage("the content"));

&nbsp;

Bueno, hasta aquí hemos llegado, creo que no me dejo nada, si es así, hacérmelo saber…

Saludos

Unai

Azure Service Bus : Queues Brokered Messages III

Bueno, con esta cerraremos la pequeña serie sobre colas en Service Bus, después de las dos entradas anterior ( I y II ). En esta ocasión tocaremos otros dos temas que pueden ser interesantes, la correlación de mensajes y el formato de los mismos, intentando poner algún ejemplo al igual que lo hemos ido haciendo anteriormente.

Session Id

La detección de duplicados no es la única de las características interesantes que tenemos dentro de las colas de Service Bus, puesto que como verá ahora, la posibilidad de otorgar un valor de correlación a cada mensaje es también una de esas cosas que solemos necesitar cuando nos enfrentamos a problemas reales. En ciertas situaciones, en las que tenemos diversos receptores para los mensajes de una cola ,es necesario que uno solo de estos clientes traten una serie de mensajes correlacionados, por ejemplo chunks de un mensaje más grande como se describe en el patrón Splitter. Para ayudarnos en esta situación el API nos proporciona una propiedad para todos los BrokeredMessage que se llama SessionId, gracias a la cual podremos establecer la correlación de una serie de mensajes. Por supuesto, como siempre, la cola tiene que soportar esta característica, pero esto es tan sencillo como se puede ver en las siguientes lineas de setup de una cola de Windows Azure Service Bus, fíjese en la propiedad RequiresSession.

           <span class="rem">//set up queue</span>
            var queueDescription = <span class="kwrd">new</span> QueueDescription(<span class="str">&quot;samples&quot;</span>);
            queueDescription.RequiresSession = <span class="kwrd">true</span>;


            <span class="rem">//create the queue using the namespace manager</span>
            <span class="rem">//the connection string to service bus is </span>
            <span class="rem">//recovered from appsetttings &quot;Microsoft.ServiceBusConnectionString&quot; key</span>
            var namespaceManager = NamespaceManager.Create();
            namespaceManager.CreateQueue(queueDescription);

//set up queue

var queueDescription = new QueueDescription("samples");

queueDescription.RequiresSession = true;

//create the queue using the namespace manager

//the connection string to service bus is

//recovered from appsetttings "Microsoft.ServiceBusConnectionString" key

var namespaceManager = NamespaceManager.Create();

namespaceManager.CreateQueue(queueDescription);

Con el fin de ver un ejemplo de esto crearemos una sencilla aplicación con el siguiente método de procesamiento de mensajes, por supuesto, simplemente con fines explicativos:

            var messagingFactory = MessagingFactory.Create();
            var queueClient = messagingFactory.CreateQueueClient(<span class="str">&quot;samples&quot;</span>);
            var messageSession = queueClient.AcceptMessageSession();
            <span class="kwrd">while</span> (<span class="kwrd">true</span>)
            {
                var msg = messageSession.Receive();

                Console.WriteLine(<span class="str">&quot;A message {0} is received in thread {1}&quot;</span>,msg.GetBody&lt;<span class="kwrd">string</span>&gt;(),Thread.CurrentThread.ManagedThreadId);
            }

var messagingFactory = MessagingFactory.Create();

var queueClient = messagingFactory.CreateQueueClient("samples");

var messageSession = queueClient.AcceptMessageSession();

while (true)

{

var msg = messageSession.Receive();

Console.WriteLine("A message {0} is received in thread {1}",msg.GetBody<string>(),Thread.CurrentThread.ManagedThreadId);

}

Ahora, en nuestra pequeña app levantaremos dos hilos utilizando este método de lectura tal que así:

            Setup();

            <span class="rem">//Create two receivers</span>
            <span class="kwrd">new</span> TaskFactory().StartNew(() =&gt; Receive());
            <span class="kwrd">new</span> TaskFactory().StartNew(() =&gt; Receive());

Setup();

//Create two receivers

new TaskFactory().StartNew(() => Receive());

Una vez creados los lectores solamente tenemos que poner una serie de mensajes en la cola, para ver nuestro propósito, pondremos a todos los mensajes el mismo identificador de sesión.

            var messagingFactory = MessagingFactory.Create();
            var queue = messagingFactory.CreateQueueClient(<span class="str">&quot;samples&quot;</span>);

            <span class="rem">//create the session identifier</span>
            var sessionId = Guid.NewGuid();

            <span class="kwrd">for</span> (<span class="kwrd">int</span> i = 0; i &lt; 10; i++)
            {
                var relatedMsg = <span class="kwrd">new</span> BrokeredMessage(<span class="kwrd">string</span>.Format(<span class="str">&quot;the message # {0} in session {1}&quot;</span>,i,sessionId));
                relatedMsg.SessionId = sessionId.ToString();

                queue.Send(relatedMsg);
            }

var messagingFactory = MessagingFactory.Create();

var queue = messagingFactory.CreateQueueClient("samples");

//create the session identifier

var sessionId = Guid.NewGuid();

for (int i = 0; i < 10; i++)

{

var relatedMsg = new BrokeredMessage(string.Format("the message # {0} in session {1}",i,sessionId));

relatedMsg.SessionId = sessionId.ToString();

queue.Send(relatedMsg);

}

Al tener en todos los mensajes el mismo identificador de sesión observaremos que solamente uno de los clientes recibe todos los mensajes ( observar el ManagedThreadId ). El tip para esto está en la llamada a AcceptMessageSession de nuestro QueueClient, revise el código de recepción de mensaje, gracias al cual podemos agrupar todos los mensajes con un mismo identificador y procesarlos con una transacción simple.

Formateadores

Al igual que con MSMQ, aunque de forma diferentes, las colas de Service Bus también nos permiten establecer cuales son los formateadores que queremos poner a los mensajes, de tal forma que le contenido de los mismos pueda ser seriado de forma diferente. Con el fin de poner un ejemplo sencillo utilizaremos protobuff para serializar nuestros mensajes tratando de reducir el tamaño de los mismos, en .NET este serializador lo podemos utilizar por ejemplo, por medio del paquete de NuGet –http://nuget.org/packages/protobuf-net.

Cambiar el mecanismo de serialización es tan sencillo como indicar el mismo dentro de una de las sobrecargas que BrokeredMessage pone a nuestra disposición, en las siguientes lineas se ve como usar el nuevo serializador comentado anteriormente:

            var messagingFactory = MessagingFactory.Create();
            var queue = messagingFactory.CreateQueueClient(<span class="str">&quot;samples&quot;</span>);

            var message = <span class="kwrd">new</span> Message(Guid.NewGuid(), <span class="str">&quot;the content&quot;</span>);
            var serializer = XmlProtoSerializer.TryCreate(TypeModel.Create(), <span class="kwrd">typeof</span>(Message));
            var brokeredMessage = <span class="kwrd">new</span> BrokeredMessage(message, serializer);

            queue.Send(brokeredMessage);

var messagingFactory = MessagingFactory.Create();

var queue = messagingFactory.CreateQueueClient("samples");

var message = new Message(Guid.NewGuid(), "the content");

var serializer = XmlProtoSerializer.TryCreate(TypeModel.Create(), typeof(Message));

var brokeredMessage = new BrokeredMessage(message, serializer);

queue.Send(brokeredMessage);

Despues de unos pocos mensajes ya podemos ver como el mismo ha surtido efecto y el cambio de tamaño

es apreciable desde el nuevo portal de Windows Azure, como muestra la imagen de la derecha, pasando de 8.26 KB a 4.85 KB el tamaño de cada uno de los mensajes..

Por supuesto, en la recepción y posterior tratamiento del cuerpo de un mensaje en la cola también tendremos que indicar el serializador a usar como se ven el las siguientes lineas:

var body = msg.GetBody&lt;Message&gt;(serializer);

1	var body = msg.GetBody<Message>(serializer);

Bueno, hasta aquí esta mini-serie acerca de Queues, lo siguiente Topics… espero que no sea dentro de mucho, ahora que hemos pillado un poco de ritmo….

Saludos

Unai

Azure Service Bus : Queues Brokered Messages – II

Siguiendo con la entrada anterior en la que empezábamos haciendo un pequeño repaso al API de service bus en .NET y el de las novedades sobre Queues y brokered messages, hablaremos sobre una de esas características que nos pueden ser de una extrema utilidad en ciertas ocasiones. Me refiero a la capacidad de detectar duplicados de mensajes.

Para intentar explicar mejor el porque de esta excelente característica pensemos en el siguiente ejemplo. Tenemos un sistema que nos permite monitorizar los contadores de rendimiento de un determinado equipo, de tal forma que, cuando un contador de rendimiento, por ejemplo uso de CPU, supera un valor dado, este sistema incluye en una cola de Service Bus un mensaje de alerta. Lógicamente, dispondremos de una pieza leyendo estos mensajes de alertar para, por ejemplo, enviar un correo notificando el problema. Dado este ejemplo, seguro que se dará cuenta de que podemos tener un problema y es que, si por ejemplo un equipo hace un uso intensivo de CPU lo hará por un tiempo determinado no en un solo instante. Por eso, si nuestro sistema de monitorización lee el valor de contador cada poco tiempo podríamos “inundar” el sistema de alarmas. Para evitar este problema, técnicamente conocido como flooding, podríamos tratar de utilizar la técnica anterior, haciendo que todas los mensajes iguales en la cola durante un determinado periodo se consideraran duplicados y por lo tanto se eliminaran automáticamente.

Configuración de la cola

Para poder utilizar la característica de duplicaciones lo primero que tenemos que hacer es disponer de una cola que soporte esta característica, a continuación, en las siguientes lineas de código podemos ver un ejemplo de creación y setup de una cola, fíjese en las propiedades RequiresDuplicateDetection y DuplicateDetectionHistoryTimeWindow.

            <span class="rem">//set up queue</span>
            var queueDescription = <span class="kwrd">new</span> QueueDescription(<span class="str">"samples"</span>);
                <span class="rem">//enable duplicate detection</span>
            queueDescription.RequiresDuplicateDetection = <span class="kwrd">true</span>;
                <span class="rem">//set the time-window for duplicate messages detection</span>
            queueDescription.DuplicateDetectionHistoryTimeWindow = <span class="kwrd">new</span> TimeSpan(0, 5, 0);

            <span class="rem">//create the queue using the namespace manager</span>
            <span class="rem">//the connection string to service bus is </span>
            <span class="rem">//recovered from appsetttings "Microsoft.ServiceBusConnectionString" key</span>
            var namespaceManager = NamespaceManager.Create();
            namespaceManager.CreateQueue(queueDescription);

//set up queue

var queueDescription = new QueueDescription("samples");

//enable duplicate detection

queueDescription.RequiresDuplicateDetection = true;

//set the time-window for duplicate messages detection

queueDescription.DuplicateDetectionHistoryTimeWindow = new TimeSpan(0, 5, 0);

//create the queue using the namespace manager

//the connection string to service bus is

//recovered from appsetttings "Microsoft.ServiceBusConnectionString" key

var namespaceManager = NamespaceManager.Create();

namespaceManager.CreateQueue(queueDescription);

El trabajo

Bien, ahora que tenemos creada una cola con soporte para la detección de duplicados, la pregunta es : ¿ cómo interpreta Service Bus que dos mensajes son iguales ? Pues bien, la respuesta es mediante la propiedad MessageId de nuestra clase BrokeredMessage. Si, probablemente a todos nos gustaría poder utilizar algún sistema más sotisficado, o cuanto menos, algún sistema personalizable para realizar esta tarea pero desgraciadamente no parece existir. Si nos fueramos al ejemplo comentado anteriormente, no nos quedaría mas remedio que todas las alertas de un contador ( hablamos de CPU en el ejemplo ) tuvieran un mismo identificador. En el siguiente ejemplo vemos unas pequeñas lineas, a modo demostrativo, el envío de un nuevo mensage con su identificador establecido, de acuerdo a nuestro ejemplo:

            var cpuAlertMessage = <span class="kwrd">new</span> BrokeredMessage(<span class="str">"the cpu use is greater than 85 %"</span>);
            cpuAlertMessage.MessageId = <span class="str">"CPU/counter"</span>;

            queue.Send(cpuAlertMessage);

var cpuAlertMessage = new BrokeredMessage("the cpu use is greater than 85 %");

cpuAlertMessage.MessageId = "CPU/counter";

queue.Send(cpuAlertMessage);

&nbsp;

Bueno, hasta aquí ha llegado esta pequeña entrada. Espero que os resulte de interés.

Saludos

unai

Azure Service Bus : Queues Brokered Messages – I

Últimamente vivimos unos tiempos muy agradables para todos aquellos a los que nos gusta la tecnología dado el gran volumen de novedades que tenemos a disposición de los desarrolladores cada cierto tiempo. Muchas veces, a los que nos gusta compartir cosas en nuestros blogs, sites etc.., no nos da la vida para nuestro propio trabajo, autoformación y publicación de nuestras experiencias y nos dejamos en el tintero algunas cosas sobre las que nos gustaría escribir. En mi caso, las novedades de ServiceBus introducidas con la versión 1.7 del API es un buen ejemplo de ello, más concretamente todo lo relacionado con el API .NET directo, no Windows Comunication Foundation, para el trabajo con Service Bus. Para intentar solventar este defecto intentaré escribir alguna serie de artículos sobre el tema, hablando de aquellos aspectos que a mi me parecen muy interesantes, empezando por los ‘brokered messages’ con colas.

El servicio de Relay seguro que es uno de los más conocidos de Service Bus, de hecho lo es por méritos propios, ya que desde sus comienzos a muchos nos abría puertas para poder realizar elementos que hasta entonces eran de dificil construcción como por ejemplo la posibilidad de tener un sistema duplex con dispositivos dentro de una NAT. Sin embargo, los servicios ‘brokered’ o màs llanamente el uso de servicios dónde el productor y el consumidor no necesitan/están conectados son también una pieza importante dentro del desarrollo de determinados sistemas empresariales. Quien más o quien menos nos hemos enfrentado al trabajo con colas de mensajerías en sus diferentes tecnologías ( MSMQ,Rabbit,MQSeriese etc… ) y hemos visto su amplio potencial. Por suerte, dentro de Service Bus tenemos la posiblidad de realizar este tipo de comunicaciones con colas, topics y subscripciones, aunque en esta entrada solamente tocaremos el uso de colas, más adelante nos adentraremos en los diferentes elementos.

Tiempos de vida y dead letters

Aunque a priori el API parece distinto de por ejemplo el api de MSMQ en .NET, pronto nos damos cuenta de que con cuatro cosas podemos estar trabajando con colas de service bus de una forma similar a como lo hacíamos con colas de MSMQ y que ciertos conceptos apréndidos de MSMQ son también válidos aquí como por ejemplo los tiempos de vida y las colas de dead letters.

Cuando enviamos un mensaje a una cola para ser consumido, estos mensajes pueden tener un tiempo de expiración, de tal forma que nos garanticemos que el mismo solamente tenga sentido ser procesado en un tiempo dado, un ejemplo de esto podría ser los mensajes de alertar, los cuales solamente podrían tener sentido notificarlos si las alertas han ocurrido cerca en el tiempo. La configuración del tiempo de vida de una ‘brokered message’ se realiza mediante la propiedad TimeToLive tal y como podemos ver en el siguiente fragmento de código:

            <span class="rem">//this use the appsettings Microsoft.ServiceBus.ConnectionString</span>
            <span class="rem">//to recover the connection string information, if you not stored</span>
            <span class="rem">//this data in app config please use TokenProvider and ServiceBusEnvironment</span>
            <span class="rem">//to build a connection string</span>
            var messagingFactory = MessagingFactory.Create();

            <span class="rem">//create the queue client</span>
            var brokeredQueueClient = messagingFactory.CreateQueueClient(<span class="str">"samples"</span>);

            <span class="rem">//create the message and configure time to live property</span>
            var brokeredMessage = <span class="kwrd">new</span> BrokeredMessage(<span class="kwrd">new</span> Message(Guid.NewGuid(), <span class="str">"The message content"</span>));
            brokeredMessage.TimeToLive = <span class="kwrd">new</span> TimeSpan(0, 0, 3);

            <span class="rem">//send the message in async mode</span>
            brokeredQueueClient.BeginSend(brokeredMessage, (iar) =&gt;
            {
                var client = (QueueClient)iar.AsyncState;
                client.EndSend(iar);

            }, brokeredQueueClient);

//this use the appsettings Microsoft.ServiceBus.ConnectionString

//to recover the connection string information, if you not stored

//this data in app config please use TokenProvider and ServiceBusEnvironment

//to build a connection string

var messagingFactory = MessagingFactory.Create();

//create the queue client

var brokeredQueueClient = messagingFactory.CreateQueueClient("samples");

//create the message and configure time to live property

var brokeredMessage = new BrokeredMessage(new Message(Guid.NewGuid(), "The message content"));

brokeredMessage.TimeToLive = new TimeSpan(0, 0, 3);

//send the message in async mode

brokeredQueueClient.BeginSend(brokeredMessage, (iar) =>

{

var client = (QueueClient)iar.AsyncState;

client.EndSend(iar);

}, brokeredQueueClient);

Como se puede observar en el código anterior, marcar el tiempo de vida de un mensaje es realmente sencillo. En nuestro caso, si este mensaje llegara a la cola y durante 3 segundos el mismo no fuera completado, este expiraría y desaparecería de la cola. Para explorar este comportamiento se puede utilizar la herramienta Service Bus Explorer, gracias a la cual, de una forma sencilla podremos ir haciendo peek y comprobar como solamente tenemos resultados durante el TTL marcado al mensaje anterior.

Otro de los elementos que también suelen ser útiles es el relativo a los poisson messages y dead letter queues, algo para lo que también teníamos soporte en la integración de WCF y MSMQ hace ya mucho tiempo. La idea, es realmente sencilla, ¿como podemos prevenir que dentro de la cola no tengamos un mensaje que pueda estar provocando errores de procesamiento y no nos bloque la salida de los siguientes en la lista? Pues bien, para resolver esto tenemos las colas de Dead Letter, dónde depositaremos nuestros mensajes envenenados para un posterior tratamiento o investigación en los mismos. Cuando creamos una conexión con una cola especificamos el modo de recepción que queremos usar de las dos disponibles PeekLock y ReceiveAndDelete. ReceiveAndDelete como su propio nombre indica implica que cuando un mensaje es leído este se elimina del store lo que implica que ante una excepción en el procesamiento perderíamos el mensaje, por el contrario PeekLock nos permite permite poner un bloqueo al mensaje de tal forma que nadie más pueda recuperarlo pero si el mismo no es completado volverá otra vez a la cola para otro consumidor. En nuestro caso, lo que queríamos observar es la capacidad de marcar un mensaje como envenenado y llevarlo a una cola de DeadLetter, para este fin, solamente tenemos que llamar al método DeadLetter como se observa a continuación.

            <span class="rem">//this use the appsettings Microsoft.ServiceBus.ConnectionString</span>
            <span class="rem">//to recover the connection string information, if you not stored</span>
            <span class="rem">//this data in app config please use TokenProvider and ServiceBusEnvironment</span>
            <span class="rem">//to build a connection string</span>
            var messagingFactory = MessagingFactory.Create();

            <span class="rem">//create the queue client</span>
            var brokeredQueueClient = messagingFactory.CreateQueueClient(<span class="str">"samples"</span>,ReceiveMode.ReceiveAndDelete);


            brokeredQueueClient.BeginReceive((iar) =&gt;
            {
                var client = (QueueClient)iar.AsyncState;
                var message = client.EndReceive(iar);

                <span class="kwrd">try</span>
                {
                    <span class="kwrd">if</span> (SuccessProcessMessage(message))
                        message.Complete();
                    <span class="kwrd">else</span>
                        message.Abandon();
                }
                <span class="kwrd">catch</span> (Exception)
                {
                    
                    message.DeadLetter();
                }


            }, brokeredQueueClient);

//this use the appsettings Microsoft.ServiceBus.ConnectionString

//to recover the connection string information, if you not stored

//this data in app config please use TokenProvider and ServiceBusEnvironment

//to build a connection string

var messagingFactory = MessagingFactory.Create();

//create the queue client

var brokeredQueueClient = messagingFactory.CreateQueueClient("samples",ReceiveMode.ReceiveAndDelete);

brokeredQueueClient.BeginReceive((iar) =>

{

var client = (QueueClient)iar.AsyncState;

var message = client.EndReceive(iar);

try

{

if (SuccessProcessMessage(message))

message.Complete();

else

message.Abandon();

}

catch (Exception)

{

message.DeadLetter();

}

}, brokeredQueueClient);

Fíjese como en caso de excepción, normalmente esto se hace con reintentos, pero por simplicidad lo dejaremos así, podemos enviar el mensaje a una cola de dead letter para su posterior procesamiento. Por supuesto, una cola de DeadLetter, al igual que en MSMQ, no es más que otra cola cualquiera con un path específico, en ServiceBus, el path es de una cola de dead letter para una cola dada es tan sencillo conseguirlo como llamar al método FormatDeadLetterPath de la clase QueueClient. Aunque es idéntico al proceso de lectura de cualquier cola a continuación está un pequeño fragmento de código para realizar la lectura de una cola de deadletter.

            <span class="rem">//this use the appsettings Microsoft.ServiceBus.ConnectionString</span>
            <span class="rem">//to recover the connection string information, if you not stored</span>
            <span class="rem">//this data in app config please use TokenProvider and ServiceBusEnvironment</span>
            <span class="rem">//to build a connection string</span>
            var messagingFactory = MessagingFactory.Create();

            <span class="rem">//create the queue client</span>
           
            var deadletterPath = QueueClient.FormatDeadLetterPath(<span class="str">"samples"</span>);
            var brokeredQueueClient = messagingFactory.CreateQueueClient(deadletterPath);

            brokeredQueueClient.BeginReceive((iar) =&gt;
            {
                var client = (QueueClient)iar.AsyncState;
                
            }, brokeredQueueClient);

//this use the appsettings Microsoft.ServiceBus.ConnectionString

//to recover the connection string information, if you not stored

//this data in app config please use TokenProvider and ServiceBusEnvironment

//to build a connection string

var messagingFactory = MessagingFactory.Create();

//create the queue client

var deadletterPath = QueueClient.FormatDeadLetterPath("samples");

var brokeredQueueClient = messagingFactory.CreateQueueClient(deadletterPath);

brokeredQueueClient.BeginReceive((iar) =>

{

var client = (QueueClient)iar.AsyncState;

}, brokeredQueueClient);

Esto es todo por ahora, aun nos quedan muchas cosas por ver o sea que si te interesa estate atento…

saludos

Unai

IdentityModel.Extensions

Estos últimos posts los he dedicado a un tema que muchos sabéis que me gusta, la seguridad de nuestras aplicaciones empresariales. Después de hablar sobre la nueva herramienta Identity & Access Tool me di cuenta de que el proceso de trabajo con la simulación de un STS Local no era tan sencillo como nos podría parecer, puesto que, en un escenario normal, los desarrolladores necesitaríamos de distintos perfiles para nuestras pruebas, no todo lo vamos a poder probar con el mismo conjunto de claims, o por lo menos no es lo habitual. Por supuesto, muchos me diréis que la herramienta mostrada nos permite modificar cuales son las claims que el STS simulado nos tiene que devolver pero, esto es un trabajo muy manual. Además, trabajando en equipo no hay una forma de compartir los distintos perfiles que podamos tener entre todos. Por todo ello, me decidí a ir sacando minutillos de mi trabajo para intentar dar una posible solución, la más simple que podamos, pero que sea efectiva. A continuación os contaré los resultados, resultados que todos los que estéis interesados podréis aprovechar.

Escarbando en la herramienta

Lógicamente lo primero es mirar como funciona la herramienta y el trabajo de nuestro LocalSTS, para ver que podemos hacer en la tarea que nos ocupa. Tras unos sencillos pasos nos damos cuenta de que el proceso LocalSTS.exe que se levanta al depurar una aplicación que haga uso de esta herramienta lo hace partiendo de una configuración que se incluye en nuestro proyecto de visual studio 2012 mediante el fichero LocalSTS.exe.config, archivo que no se incluye como archivo del proyecto pero que podemos mostrar fácilmente desde nuestro explorador de soluciones, tal y como podemos ver en la siguiente imagen.

En este archivo, encontramos toda la configuración seleccionada en la herramienta de gestión de identidad, desde el certificado a usar hasta lo que nos preocupa a nosotros que es las claims que el STS local nos tiene que proporcionar y que podemos ver en el siguiente fragmento XML.

    &lt;claims&gt;
      &lt;add type=<span class="str">"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"</span> displayName=<span class="str">"Name"</span> <span class="kwrd">value</span>=<span class="str">"Terry"</span> /&gt;
      &lt;add type=<span class="str">"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"</span> displayName=<span class="str">"Surname"</span> <span class="kwrd">value</span>=<span class="str">"Adams"</span> /&gt;
      &lt;add type=<span class="str">"http://schemas.microsoft.com/ws/2008/06/identity/claims/role"</span> displayName=<span class="str">"Role"</span> <span class="kwrd">value</span>=<span class="str">"developer"</span> /&gt;
    &lt;/claims&gt;

</claims>

Bueno, ya está, la solución parece bien fácil. Lo único que tenemos que hacer es tener distintos archivos con claims y cambiar en este XML el elemento claims por el que nos interese en cada prueba y ya tendremos nuestro objetivo. Ahora, la pregunta es ver como lo vamos a hacer, intentando que para el desarrollador sea una tarea sencilla y en la que no tenga que cambiar el contexto de su herramienta de trabajo, Visual Studio.

La implementación

Después de distintas vueltas parece que la solución más sencilla y más cómoda para el desarrollador es la de proporcionar algún comando para nuestra consola de NuGet, de tal forma, que al igual que con otros paquetes, podamos ejecutar algún comando de Power Shell que nos facilite la tarea. Por ello, nos ponemos manos a la obra y escribimos el siguiente paquete de NuGet, el cual solamente contiene un módulo de funciones de Power Shell a utilizar en la ventana de comandos.

git clone git@github.com:unaizorrilla/IdentityModel.Extensions.git

    Cmdlet                        Description
    -----------------             ---------------------------------------------------
    Save-CurrentLocalSTSProfile   Save the current local sts profile with a name for reuse
    Get-LocalSTSProfiles          Show all local sts profiles stored in project
    Set-LocalSTSProfile           Set stored profile as current profile for local sts

Cmdlet Description

----------------- ---------------------------------------------------

Save-CurrentLocalSTSProfile Save the current local sts profile with a name for reuse

Get-LocalSTSProfiles Show all local sts profiles stored in project

Set-LocalSTSProfile Set stored profile as current profile for local sts

El ejemplo

Bueno, como las cosas siempre se ven mejor con un ejemplo lo que haremos es ver el uso de este paquete en una aplicación web MVC 4. Puesto que a estas alturas el paquete aún no está disponible en NuGet.org lo que haremos es instalarlo mediante un repositorio local.

Una vez instalado, podemos ejecutar get-help identitymodelextensions para ver los distintos comandos, nombrados anteriormente. Las tareas básicas son las siguientes:

Creación de un nuevo perfil: Una vez que tengamos creado mediante nuestra herramienta Identity & Access la configuración de claims para un caso dado, lo que haremos es guardar esta configuración con un nuevo perfil, para ello, ejecutarmos el siguiente comando. save-currentlocalstsprofile –profilename nombreperfil. Con este sencillo paso ya habremos guardado nuestra configuración y podremos seguir trabajando con la herramienta en la generación de nuevos perfiles.

Visualización de perfiles: Para ver los distintos perfiles almacenados en el proyecto solamente tenemos que ejecutar el comando get-localstsprofiles, el cual, como vemos a continuación nos enseña los distintos perfiles almacenados.

Estableciendo el perfile actual: Ahora que ya sabemos como crear y enseñar perfiles solamente nos queda establecer el perfil ( colección de claims ) a utilizar. Para ello, tenemos el último de los comandos de nuestro paquete que es set-localstsprofile –profilename nombreperfil

Bueno, hasta aquí hemos llegado, espero que realmente os resulte interesante y, si no es así, por lo menos que os pueda servir para aprender algo nuevo…

Un saludo

Unai

Diseño

La implementacion

El casi

Azure Authentication Library

Windows Azure Active Directory

AAL

Multiples lectores/subscriptores

Filtros

Session Id

Formateadores

Configuración de la cola

El trabajo

Tiempos de vida y dead letters

Escarbando en la herramienta

La implementación

El ejemplo