Storage Queues vs Service Bus queues

Interesante la tabla comparativa que leo en http://preps2.wordpress.com/2011/09/17/comparison-of-windows-azure-storage-queues-and-service-bus-queues/ sobre las diferencias entre las colas de storage y las de service bus.

Aunque como se verá a continuación el sistema de colas de service bus es mucho más completo que el existente en el storage, no se debe caer en la tentación de emplear siempre el más completo, sino en aquel que sea mejor para la aplicación que se esté desarrollando.

Feature

Windows Azure Storage Queues

Service Bus Queues

Comments

Programming Models
Raw REST/HTTP Yes Yes
.NET API Yes(Windows Azure Managed Library) Yes(AppFabric SDK)
Windows Communication Foundation (WCF) binding No Yes
Windows Workflow Foundation (WF) integration No Yes
Protocols
Runtime REST over HTTP REST over HTTPBi-directional TCP The Service Bus managed API leverages the bi-directional TCP protocol for improved performance over REST/HTTP.
Management REST over HTTP REST over HTTP
Messaging Fundamentals
Ordering Guarantees No First-In-First-Out (FIFO) Note: guaranteed FIFO requires the use of sessions.
Message processing guarantees At-Least-Once (ALO) At Least-Once (ALO)Exactly-Once (EO) The Service Bus generally supports the ALO guarantee; however EO can be supported by using SessionState to store application state and using transactions to atomically receive messages and update the SessionState. The AppFabric workflow uses this technique to provide EO processing guarantees.
Peek Lock YesVisibility timeout: default=30s; max=2h YesLock timeout: default=30s; max=5m Windows Azure queues offer a visibility timeout to be set on each receive operation, while Service Bus lock timeouts are set per entity.
Duplicate Detection No Yes, send-side duplicate detection The Service Bus will remove duplicate messages sent to a queue/topic (based on MessageId).
Transactions No Partial The Service Bus supports local transactions involving a single entity (and its children). Transactions can also include updates to SessionState.
Receive Behavior Non-blocking, i.e., return immediately if no messages REST/HTTP: long poll based on user-provided timeout.NET API: 3 options: blocking, blocking with timeout, non-blocking.
Batch Receive Yes(explicit) Yes. Either (a) Implicitly using prefetch, or (b) explicitly using transactions.
Batch Send No Yes (using transactions)
Receive and Delete No Yes Ability to reduce operation count (and associated cost) in exchange for lowered delivery assurance.
Advanced Features
Dead lettering No Yes Windows Azure queues offer a ‘dequeue count’ on each message, so applications can choose to delete troublesome messages themselves.
Session Support No Yes Ability to have logical subgroups within a queue or topic.
Session State No Yes Ability to store arbitrary metadata with sessions. Required for integration with Workflow.
Message Deferral No Yes Ability for a receiver to defer a message until they are prepared to process it. Required for integration with Workflow.
Scheduled Delivery No Yes Allows a message to be scheduled for delivery at some future time.
Security
Authentication Windows Azure credentials ACS roles ACS allows for three distinct roles: admin, sender and receiver. Windows Azure has a single role with total access, and no ability for delegation.
Management Features
Get Message Count Approximate No Service Bus queues offer no operational insight at this point, but plan to in the future.
Clear Queue Yes No Convenience functions to clear queue efficiently.
Peek / Browse Yes No Windows Azure queues offer the ability to peek a message without locking it, which can be used to implement browse functionality.
Arbitrary Metadata Yes No Windows Azure queues allow an arbitrary set of <key, value> pairs on queue metadata.
Quotas/Limits
Maximum message size 8KB 256KB
Maximum queue size Unlimited 5GB Specified at queue creation, with specific values of 1,2,3,4 or 5 GB.
Maximum number of entities per service namespace n/a

10,000

Relayed Messaging y Brokered Messaging

Cuando se habla de ApFabric Service Bus es importante distinguir entre dos tipos de comunicaciones o sistema de mensajería; Relayed Messagins y Brokered Messaging.

WCF

Relayed Messaging

Este tipo de mensajes existen desde la aparición de la primera versión de Service Bus, cuya primera versión reléase es de enero de 2010.

En este escenario un servicio hosteado en Windows Azure hace de relay entre los dos puntos de la conectividad cliente-servidor, haciendo posible la comunicación entre ambos aunque haya elementos por medio que pudieran complicar dicha comunicación.

RelayedMessaging

Este tipo de comunicación ofrece ventajas claras en situaciones dónde la conectividad es un “problema”, pero también, desde el punto de vista de arquitectura, hay que tener en cuenta otras características del sistema si se opta por este tipo de mensajes.

En este tipo de escenario tanto cliente como servidor tiene que estar conectado al servicio de AppFabric para que la comunicación sea posible.

Otra aspecto a tener en cuenta es que en situaciones de carga, dónde muchos clientes quisieran conectarse con el servidor, el rendimiento del sistema podría verse afectado y tener situaciones de “timeout”s en las comunicaciones. Es una solución que desde el punto de vista de balanceo de carga o escalabilidad no ofrece ninguna solución clara que cubra estos escenarios.

Brokered Messaging

El segundo tipo de mensajes es una de las nuevas características del SDK 1.5, versión de septiembre de 2011.

Es este escenario el servicio de service bus hosteado en la nube hace de bróker de mensajes entre los clientes y servidores, ofreciendo un servicio de almacenamiento persistente de los mensajes “en tránsito”.

BrokeredMessages

Con este tipo de mensajes se introducen las tecnologías de colas, topics y subscripciones, las cuáles se utilizan para diferentes tipos comunicación entre cliente y servidor. Este tipo de mensajes cubre perfectamente el típico patrón publicador-subscriptor de muchas aplicaciones.

En este tipo de escenarios la comunicación no ocurre de forma síncrona, no siendo un requisito necesario que ambas partes de la comunicación se encuentren siempre disponibles.

Desde el punto de vista de cliente el servidor siempre es capaz de atender las peticiones, ya que éstas se almacenan en el servicio que hace de relay. Cuando el servidor se encuentre online ya se encargará de recibir las peticiones y procesarlas.

Este modelo, a diferencia del anterior, es completamente válido para escenarios de alta disponibilidad, dando a su vez opción para implementar soluciones de balanceo de carga.

Aunque las colas de Service Bus son una versión mucho más potente que la que ofrece Windows Azure Storage, puede tomarse como referencia el comportamiento de éstas últimas para entender la característica. Comparar este sistema con MSMQ podría ser una opción más acertada.

topics11

Los topics y subscripciones son una funcionalidad que extiende el concepto de cola, ya que permite que las aplicaciones sólo envíen o reciban mensajes basándose basado en ciertas condiciones, no teniendo que tratar todos los mensajes que pasen por las colas.

Una subscripción se crea a partir de un topic y un topic puede tener cero o más subscripciones asociadas.

La aplicación envía los mensajes a un determinado topic, siendo estos mensajes en rutados a las subscripciones existentes en base a las reglas que se hayan configurado.

topics12

 

Modelo de programación

Como se puede ver a continuación el modelo de programación de los mensajes brokered ofrece varios modelos de programación.

servicebus

Interfaz REST

A través de REST es posible acceder a toda la funcionalidad que ofrece la runtime de Service Bus, opción que suele ser empleada cuando se quiere acceder desde tecnologías no .NET.

Modelo directo

El modelo de trabajo directo ofrece una serie de librerías y clases de .NET que permite ser referenciadas desde proyectos .NET y que dan acceso de una forma clara y sencilla a toda la funcionalidad de Service Bus.

Por similitud, estas clases son similares a las que existen para trabajar con Windows Azure Storage.

En este caso la librería es Microsoft.ServiceBus.dll.

public bool SendMessageToQueue(string message, string queueName, MessageSettings settings) { MessagingFactory factory = MessagingFactory.Create(serviceUri, credentials); QueueClient queueClient = factory.CreateQueueClient(queueName); BrokeredMessage payLoad = GetPayload(message, settings); queueClient.Send(payLoad); return true; }

Modelo de programación WCF

Del mismo modo que se puede hacer con los mensajes de tipo relayed, existe la posibilidad de trabajar con WCF. La clase NetMessagingBinding nos ofrece la posibilidad de desarrollar aplicaciones WCF que hagan uso de las nuevas capacidades de Service Bus, pudiendo manejar las colas, topics y subscripciones.

Libro gratuito sobre Windows Azure – Parte II

En un post anterior os presentaba un pdf de descarga gratuita que hemos creado con información sobre la plataforma Windows Azure.

Acabamos de publicar la segunda parte sobre los sistemas de almacenamiento en Windows Azure, dónde se habla de SQL Azure y WIndows Azure Storage.

Parte I – Introducción a Windows Azure

Parte II – Sistemas de almacenamiento, SQL Azure y Windows Azure Storage

Recordad que con este contenido lo que hemos intentado es hacer una labor de recopilación de toda la información que hemos ido realizando desde la primera versión de la plataforma, para una vez actualizada, poder presentarla de forma ordenada al lector y así simplificar el proceso de aprendizaje.

Espero que os sea de utilidad!

estoyenlanubeBannerLong

[Artalde.NET] ASP.NET MVC 3 y jQuery

El 23 de noviembre, miércoles, tendrá lugar la siguiente sesión presencial organizada por el grupo de usuarios Artalde, dónde Alfredo Fernández (Plain Concepts) nos introducirá en el maravilloso mundo de ASP.NET MVC y JQuery.

El evento empezará a las 19:00h y el lugar el de siempre, la universidad de Deusto.

PlainLogo_white

Descripción:

Durante esta sesión se hará una introducción a dos tecnologías básicas a día de doy para todo desarrollador que trabaje con tecnologías Microsoft, como son ASP.NET MVC 3 y JQuery. El objetivo de la misma es ofrecer una visión al asistente lo más completa posible de dichas tecnologías que le permita conocer las características principales de las mismas.

Agenda:

  • Introducción a ASP.NET MVC 3
    • ¿Por qué MVC?
    • Arquitectura.
    • Razor.
    • Puntos de extensibilidad.
    • Inyección de dependencias.
    • Testing.
  • Introducción a JQuery

Por cierto, recordad que el grupo tiene su propio blog y cuenta de twitter.

Toda la información completa y el registro aquí, os esperamos!

Libro gratuito sobre Windows Azure – Parte I

Hoy os presento un pdf de descarga gratuita que hemos creado con información sobre la plataforma Windows Azure que espero que sea de gran utilidad para todas las personas que quieran ponerse al día en la plataforma.

Hemos publicado la primera parte, la cuál hace una introducción a la plataforma y profundiza en Windows Azure.

Con este contenido lo que hemos intentado es hacer una labor de recopilación de toda la información que hemos ido realizando desde la primera versión de la plataforma, para una vez actualizada, poder presentarla de forma ordenada al lector y así simplificar el proceso de aprendizaje.

Os lo podéis descargar desde aquí

 

logo_plain  Logo-krasis-press

 

La segunda parte tratará del sistema de almacenamiento, parte que tratará los temas del SQL Azure y Windows Azure Storage.

La tercera parte abordará AppFabric y Windoows Identity Foudantion, mientras que la última parte serán una serie de apéndices que hablarán de herramientas para trabajar con la plataforma y algunas otras consideraciones que creemos que utilidad.

Espero que en pocos días podamos ir publicando el resto.

estoyenlanubeBannerLong

Windows Azure WordPress Accelerator

Windows Azure WordPress Accelerator are two sample solutions that allow deploy WordPress in Windows Azure.

You can find source code in CodePlex http://wordpressaccelerator.codeplex.com/ 

Gerard Lopez and Mario Cortes work was great!

The first one uses WordPress plugin that allows you to use Windows Azure Storage Service to host your media for your WordPress powered blog.

This solution is simpler than the other one, but It is important to note that if you want to install or update plugins, you must redeploy to solutions. New plugins must be added in Visual Studio solution and update Windows Azure deployment.

The second one uses Windows Azure Drive technology to store WordPress files.

All wordpress files, includes media elements, are stored in VHD file that in Windows Azure Storage Page Blob.

To allow multiple WordPress instances that can be modified VHD content, the solution includes worker role that mounts VHD and share it. All WordPress instances use network share that exposes worker role.

 

wordpressaccelerator

VoD Smooth Streaming en Windows Azure

Para todo aquellos que trabajan con video la capacidad de poder servir videos desde Windows Azure empleando Smooth Streaming es una de las características más esperadas de la plataforma. Se lleva mucho hablando de esta característica, de la posibilidad de poder servir VoDs (Video On Demand) desde el storage directamente usando smooth streaming, pero al menos de momento no lo tenemos, así que hay que buscar alternativas.

En este post intentaré mostrar una forma de poder servidor videos desde Windows Azure empleando Smooth Streaming. Hablaré únicamente de servir videos bajo demanda, si alguien está interesado es poder hacer “Lives” le recomiendo que revise este proyecto de CodePlex; http://azlivestreaming.codeplex.com/

En el ejemplo que muestro a continuación todos los videos codificados para Smooth Streaming los incluyo dentro de un fichero VHD, fichero que posteriormente subo a un Page Blob de Windows Azure Storage.

Luego, lo que hago es desplegar un WebRole que emplea la característica de Drive para mapear este VHD como una unidad de disco y así poder crear un site de IIS que apunte a la unidad. De esta manera es el propio IIS el que sirve los ficheros como si éstos estuvieran en local.

Los ficheros los pongo en un VHD por si quiero que éstos se compartan por diferentes instancias del Role o por si en un momento dado me interesa que la aplicación sea capaz de ir actualizando los VoDs que se sirven, por ejemplo, porque el usuario puede subir videos.

El fichero VHD se puede crear desde el administrador de discos.

VoD

En el proceso de creación del VHD hay que tener en cuenta los siguientes aspectos:

  • El tamaño del disco tiene que estar entre 16Mb y 1 TB.
  • Tiene que tener formato NTFS.
  • El disco tiene que ser de formato fijo.
  • El fichero VHD generado tiene que subirse como un Page Blob.
  • Si hay varias instancias, hay que tener en cuenta que sólo 1 de ellas puede tener la unidad montada en modo escritura. En lectura pueda haber todos los que se quieran.

Una vez creado, se verá éste como una unidad más del equipo local. Dentro de esta unidad hay que los videos que se quieran. Además de los videos también se deben configurar las políticas para que éstos videos puedan ser consumidos desde dominios diferentes al actual. En el ejemplo que estoy realizando tengo dos sites; uno contendrá el player y otro servirá los videos, de ahí que se necesite permitir las llamadas desde un dominio a otro.

VoD1

Una vez copiados los ficheros, también desde el administrador de discos hay que realizar la acción “detach VHD” para quitar la unidad del VHD y así liberarlo para copiarlo a Storage. Recuerda que tiene que ser un Page Block.

Una vez tengo el VHD, el siguiente paso es crear un nuevo proyecto de Windows Azure, al que añado un WebRole. Del proyecto asociado al WebRole se pueden eliminar todos los ficheros, salvo el web.config.

Lo que sí hay que añadir es el player que se quiere emplear para ver los videos. Se puede emplear cualquier player que sea capaz de ver videos en smooth streaming. Yo por ejemplo que cogido uno hecho en Silverlight que viene con Expression Encoder.

En el player hay que indicar la URL del video que se quiere visualizar: http://servicename.cloudapp.net:8080/VideoSample/VideoSample.ism/manifest

Pongo 8080, porque éste será el puerto que empleará el site que servirá los videos y que apunte al contenido del VHD. VideoSample es un directorio que existe dentro del VHD y que contiene el video.

El siguiente paso será mapear el VHD como una unidad, acción que la incluiré dentro del evento OnStart del WebRole.

private string CreateDrive() { CloudStorageAccount storageAccount = CloudStorageAccount.FromConfigurationSetting("StorageAccount"); LocalResource localCache = RoleEnvironment.GetLocalResource("InstanceDriveCache"); CloudDrive.InitializeCache(localCache.RootPath, localCache.MaximumSizeInMegabytes); // blogUri => http://storagename.blob.core.windows.net/vod/myvhd.vhd string blogUri = RoleEnvironment.GetConfigurationSettingValue("VHDUri"); CloudDrive drive = new CloudDrive(new Uri(blogUri), storageAccount.Credentials); try { drive.Create(20); } catch (CloudDriveException ex) { // handle exception here // exception is also thrown if all is well but the drive already exists } return drive.Mount(localCache.MaximumSizeInMegabytes, DriveMountOptions.None); }

El código anterior lo que hace es montar una unidad de disco a partir de un fichero VHD de 20Mb, un fichero que está en el storage dentro un contenedor llamado vhd. También emplea una caché local, para lo cuál es necesario configurar en el rol un storage local que almacene dicha caché.

VoD2

Una vez se tiene la unidad mapeada, el siguiente paso crear un nuevo site, también en el método OnStart, que apunte a la unidad de disco recién mapeada. Este site se crea en el puerto 8080, en el mismo binding que el site por defecto que está en el puerto 80.

private void CreateNewSiteForVod(string siteRoot) { if (String.IsNullOrEmpty(siteRoot)) return; if (!siteRoot.EndsWith("\")) siteRoot += "\"; var webApplicationProjectName = "Web"; using (ServerManager serverManager = new ServerManager()) { if (!serverManager.Sites.Where(s => s.Name.Equals("VoDSite", StringComparison.OrdinalIgnoreCase)).Any()) { ApplicationPool applicationPool = serverManager.ApplicationPools.Add("VoDSitePool"); applicationPool.AutoStart = true; applicationPool.ManagedPipelineMode = ManagedPipelineMode.Integrated; applicationPool.ManagedRuntimeVersion = "v4.0"; applicationPool.ProcessModel.IdentityType = ProcessModelIdentityType.ApplicationPoolIdentity; string binding = "*:8080:"; int defaultPort = 80; if (serverManager.Sites[RoleEnvironment.CurrentRoleInstance.Id + "_" + webApplicationProjectName].Bindings.Where(b => b.EndPoint.Port == defaultPort).Any()) { binding = String.Format("{0}:8080:", serverManager.Sites[RoleEnvironment.CurrentRoleInstance.Id + "_" + "Web"].Bindings.Where(b => b.EndPoint.Port == defaultPort).First().EndPoint.Address); } Site site = serverManager.Sites.Add("VoDSite", "http", binding, siteRoot); site.Applications.First().ApplicationPoolName = "VoDSitePool"; site.ServerAutoStart = true; serverManager.CommitChanges(); } } }

El método OnStart tendrá el siguiente aspecto:

public override bool OnStart() { CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) => { if (RoleEnvironment.IsAvailable) configSetter(RoleEnvironment.GetConfigurationSettingValue(configName)); else configSetter(ConfigurationManager.AppSettings[configName]); }); string driveLetter = CreateDrive(); CreateNewSiteForVod(driveLetter); return base.OnStart(); }

Ý para terminar, hay que hacer un último paso para instalar IIS Media Services cuando se despliegue la aplicación en Windows Azure, ya que este componente es necesario para poder servir ficheros usando smooth streaming. Para eso podemos usar un Startup Task.

Para ello hay que añadir al proyecto del WebRole el instalador de IISMediaServices y un fichero “.cmd”, indicando en los dos ficheros la opción “Copy Local = true”, para que éstos se incluyan en el despliegue.

Desde el fichero de definición del servicio añadiremos la configuración para que el contenido del cmd se ejecuta al inicializar la instancia.

<Startup> <Task commandLine="setup.cmd" executionContext="elevated"> <Environment> <Variable name="EMULATED"> <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" /> </Variable> </Environment> </Task> </Startup>

 

Y en el cmd sólo hay que añadir la línea de comandos que instala de manera silenciosa IIS Media Services:

if "%EMULATED%"=="true" goto :EOF msiexec /i IISMedia64.msi /qn

VoD3

Y ya está, ya sólo es necesario desplegar la aplicación en Windows Azure y probar que todo funciona!!

En mi caso http://servicename.cloudapp.net/SmoothStreamingPlayer.html que lo que hace es mostrar un player silverlight que consume un video que se sirve de http://servicename.cloudapp.net:8080

Si os conectáis por RDP a la instancia podréis ver que la máquina tiene dos sites y que uno de ellos apunta a una unidad de disco dónde se ve el contenido del VHD que se ha subido previamente al Storage.