Compartir a través de


Comunicación entre Web Role y Worker Role

Una aplicación de Windows Azure puede estar compuesta por uno o más roles. Los roles pueden funcionar de manera independiente pero lo más habitual es que es mayor o menor medida sea necesario comunicar los roles que conforman una aplicación entre sí.

  • Web rol: Un 'web rol' es una aplicación basada en web accesible mediante HTTP o HTTPS. Un web rol es alojado en un entorno de ejecución que soporta un subconjunto bastante amplio de ASP.NET y Windows Comunication Foundation.
  • Worker rol: Un 'worker role' es un proceso que corre en segundo plano. Sería el equivalente a un servicio de Windows en la plaforma Windows Azure. Un worker rol se puede comunicar con los servicios de almacenamiento y de colas de Windows Azure, incluso puede comunicarse directamente con otros roles.

Tipo de conexiones

Los Web Roles únicamente puede atender peticiones a través del protocolo HTTP o HTTPS.

Un Web Role sólo puede disponer de un único endpoint HTTP interno que puede emplearse para comunicaciones dentro de Windows Azure y de dos endpoints para recibir conexiones entradas (uno HTTP y otro HTTPS), conexiones desde cliente que residen fuera de Windows Azure.


Figura 1.- Configuración de un Web Role

Los Worker Roles, a diferencia de los web roles, permiten tener tantos "endpoints" como necesite y atender peticiones entrantes y salientes tanto en el protocolo HTTP, HTTPS como TCP/IP.


Figura 2.- Configuración de un Worker Role Role

Comunicación asíncrona

Una primera alternativa a la hora de comunicar dos roles entre sí, independientemente del tipo de rol, es la comunicación asíncrona. La comunicación asíncrona es un sistema comúnmente utilizado en muchas aplicaciones hoy en día, por ejemplo, para cubrir escenarios dónde la carga de proceso puede ser muy grande y poder ofrecer un alto grado de escalabilidad.

El servicio de colas de Windows Azure proporciona un mecanismo fiable y persistente para la comunicación asíncrona entre aplicaciones de Windows Azure. El API de colas de Windows Azure, construido también sobre REST, está basado en dos tipos de abstracciones: colas y mensajes.

Un escenario habitual podría ser disponer de un Web Role que sea capaz de recibir peticiones entrantes y que tenga un requisito muy alto en cuanto a la escalabilidad. En este caso, puede interesar que el Web Role reciba las peticiones y tan pronto las reciba la incluya en una cola de Windows Azure Storage.

//Añadimos el mensaje a la cola 
_Queue.AddMessage(new CloudQueueMessage(GetNumberOfPhotos()));

Un Worker Role podría encargarse de leer de forma periódica la cola, leer los mensajes que en ella encuentre y realizar la lógica necesaria con la información recibida.

//Vemos si hay un mensaje en la cola 
//Si lo hay leemos el número de fotos
CloudQueueMessage message = _Queue.GetMessage();
if (message != null)
{
int numberOfPhotos = int.Parse(message.AsString);
//Procesamos el mensaje ...
//Borramos el mensaje
_Queue.DeleteMessage(message);
}

Comunicación directa

La comunicación asíncrona es una primera alternativa para comunicar roles, aunque no la única. Como se ha visto anteriormente los roles pueden exponer endpoints internos que pueden ser utilizados para realizar comunicaciones entre roles de la aplicación que residen en Windows Azure.

Si se emplean los endpoints internos, la comunicación puede hacerse de manera directa.

A través del API que proporciona el SDK, cualquier roles es capas de descubrir de forma dinámica la información sobre el resto de roles que componen la aplicación, descubrir sus endpoints y se capaz de comunicarse con ellos una vez tiene la URI dónde se encuentran a la escucha. Lógicamente, tanto los roles como los endpoints disponen de un nombre, nombres con los cuáles un determinado rol puede descubrir la URI del rol con el que desea comunicarse.

foreach (var roles in RoleEnvironment.Roles) 
{
var instances = RoleEnvironment.Roles[roles.Key].Instances;
foreach (var instance in instances