Microsoft a récemment publié une nouvelle version du SDK Windows Azure Service Bus Client SDK comprenant des versions à base de System.Threading.Tasks.Task de toutes les APIs asynchrones, ouvrant la possibilité d'écrire du code asynchrone toujours plus lisible. La dernière release a été compilée en Framework .Net 4 et fonctionnera donc aussi bien depuis Visual Studio 2012 que depuis la version précédente.
Scott Seely, développeur sénior de l'équipe Windows Azure Service Bus, fait une démonstration des fonctionnalités du SDK utilisant les Microsoft.ServiceBus.NamespaceManager et Microsoft.ServiceBus.Messaging.QueueClient sur le blog MSDN officiel dans un post intitulé Task Based APIs for Service Bus.
Dans son exemple, il commence par vérifier si la queue existe, la crée si elle n'existe pas puis envoie un message. Il se place en réception juste après. Scott fait en sorte que le message soit livré à peu près 5 secondes après qu'il a été envoyé, afin de permettre au client d'effectuer d'autres actions et de profiter du CPU plutôt que de rester bloqué, en attente de l'apparition du message, avant de continuer.
Le SDK Windows Azure Service Bus Client a été développé de façon à ce que toutes les exceptions ne soient levées qu'une fois la tâche complétée. Il permet également de se placer simplement en attente de la complétion de la tâche. Il peut être installé soit via NuGet, soit en utilisant la console Package Manager Console dans Visual Studio.
En plus des fonctionnalités susmentionnées, le Windows Azure Service Bus Client SDK supporte aussi la possibilité de parcourir les messages dans les queues, celle de suspendre et reprendre la réception et l'envoi de messages des queues et des topics grâce à l'énumération Microsoft.ServiceBus.Messaging.EntityStatus ainsi que la possibilité de supprimer automatiquement les queues, les topics ou les abonnements non sollicités après un délai spécifié par la propriété AutoDeleteOnIdle.
La dernière release du SDK introduit ainsi un modèle de messaging "Event-Driven" ou "Push" comme alternative à la boucle utilisée traditionnellement pour la réception des messages ("receive loop"). Ce modèle supporte en plus le traitement concurrent des messages et la possibilité de les traiter à différents rythmes.