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.
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.
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”.
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.
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.
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.
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.
