Today, the AppFabric team announced the first Community Technology Preview of the Azure AppFabric Service Bus V2.
The second release of Azure AppFabric Service bus is a significant milestone that the team has been hard at work on for several months. While I’ve had the privilege of attending a number of SDRs and watching this release move from ideation to actual bits, this is the first time I’ve been able to actually get my hands on the code, so I’ve spent the better part of this evening diving in.
First, if you are new to the Azure AppFabric Service Bus, there are many resources available to get you up to speed. I highly recommend this whitepaper by Aaron Skonnard: A Developer’s Guide to the Service Bus. If you are a visual learner, please consider checking out my webcast on AppFabric Service Bus here: http://rickgaribay.net/archive/2011/01/12/neudesic-appfabric-webcast-series.aspx.
In a nutshell, like most ESBs, Azure AppFabric Service Bus is the manifestation of a number of core messaging patterns that provide the ability to design messaging solutions that are loosely coupled. What makes the Azure AppFabric Service Bus unique is that it provides these capabilities at “internet scale”, meaning that it is designed to decouple clients and services regardless of whether they are running on premise or in the cloud. As a result, the AppFabric Service Bus is a key technology for enabling hybrid scenarios at the platform level (i.e. PaaS) and serves as a key differentiator in the market today for enabling organizations to adopt cloud computing in a pragmatic way.
Messaging patterns in general provide a common frame on which to think about and build composite applications. Cloud and hybrid computing necessitate many of the same messaging patterns found within the on-premise enterprise and introduce new complexities that are somewhat unique. 
Azure AppFabric Service Bus V2 introduces tried and true messaging capabilities such as Queues, Topics, Pipes and Filters (Rules/Actions) as well as sequencing semantics and of course durability.
It is important to note that the Azure AppFabric Service Bus is not a replacement for on-premise publish-subscribe messaging. It enables new scenarios that allow you to integrate your current on-premise messaging and provide the ability to compose clouds, be they your own, your partners or those of private cloud providers such as Microsoft. The drawing on the right is from the Microsoft whitepaper I mentioned in the introduction. Notice that the Azure AppFabric Service Bus is providing the ability to integrate clients and services regardless of where they reside, and for non-trivial SOA, on-premise pub-sub for decoupling composed services and clients is essential.
Queues
Queues are typically used to provide temporal decoupling, which provides support for occasionally connected clients and/or services. With a queue, a client writes to a known endpoint (private/local or public/somewhere on the network) without regard to the state of the downstream service. If the service/consumer is running, it will read work items or messages from the queue. Otherwise, the queue will retain the message(s) until the service is available to retrieve the message or the message expires.
As promised, Azure AppFabric Service Bus V2 delivers on durable messaging capabilities beyond the current Message Buffer feature with the introduction of Queues.
Queues are supported in the .NET API (shown below), REST API and with a new WCF Binding called “ServiceBusMessagingBinding”. While my preferred approach will certainly be WCF, the .NET API helps to understand the new API. In addition, the process of creating a queue is required even with WCF since queue creation is outside of WCF’s immediate area of concern.
The first thing you need to do when working with Queues, Topics and Subscribers is create a Service Bus Namespace Client which is an anchor class for managing Service Bus entities:
ServiceBusNamespaceClient namespaceClient = new
ServiceBusNamespaceClient(ServiceBusEnvironment.CreateServiceUri("sb",
serviceNamespace, string.Empty),
sharedSecretCreds);
Once you have an instance of the ServiceBusNamespaceClient, you can create a queue by simply instantiating the Microsoft.ServiceBus.Messaging.Queue class (I’ve set the queueName field to “Orders”):
Queue queue = namespaceClient.CreateQueue(queueName);
Next, create a Queue client. The Queue Client manages both send and receive operations:
1: MessagingFactory messagingFactory =
MessagingFactory.Create(ServiceBusEnvironment.CreateServiceUri("sb", serviceNamespace, string.Empty), sharedSecretCreds);
2: var queueClient = messagingFactory.CreateQueueClient(queue);
The code above uses the Microsoft.ServiceBus.Messaging.MessagingFactory which accepts your namespace and security credentials and returns an instance of the MessagingFactory.
Next, you create an instance of Microsoft.ServiceBus.Messaging.MessageSender using the CreateSender method:
1: var messageSender = queueClient.CreateSender();
2: messageSender.Send(msg);
3: messageSender.Close();
Line 7 below creates a BrokeredMessage, which is a new message class which represents a unit of communication between Service Bus clients. Note that this class has nothing to do with the System.ServiceModel.Channels Message class, however when using the ServiceBusMessagingBinding the classic WCF Message class is used. The BrokeredMessage class consists of a number of methods and some interesting properties including ContentType, CorrelationId, MessageId, Label and a property bag called Properties which we’ll explore as we progress through the new features.
In this example, I’m using an overload of CreateMessage that accepts a serializable object. The method uses the DataContractSerializer with a a binary XmlDictionaryWriter to create a BrokeredMessage.
1: Order order = new Order();
2: order.OrderId = 42;
3: order.Products.Add("Kinect",70.50M);
4: order.Products.Add("SamsungFocus", 199.99M);
5: order.Total = order.Products["Kinect"] + order.Products["SamsungFocus"];
6:
7: var msg = BrokeredMessage.CreateMessage(order);
Finally, we can send the message:
1: var messageSender = queueClient.CreateSender();
2: messageSender.Send(msg);
3: messageSender.Close();
With much of the infrastructure code out of the way, we can use the same queueClient instance to create a MessageReciever and request the BrokeredMessage message from the Orders queue:
1: var messageReceiver = queueClient.CreateReceiver(ReceiveMode.ReceiveAndDelete);
2: var recdMsg = messageReceiver.Receive();
3: messageReceiver.Close();
Note the ReceiveMode in line 1 above. This has the effect of enforcing an “Exactly-Once” “At Most Once” (thanks David Ingham) receive semantic since the first consumer to read the message will pop it off the queue. The opposite option is RecieveMode.PeekLock which provides “At Least Once” delivery semantics. As David Ingham, Program Manager on the AppFabric team kindly adds in his comments below: “If the consumer is able to record the MessageIds of messages that it has processed then you can achieve “ExactlyOnce” processing semantics with PeekLock mode too.” –Thanks David!
Once we have the BrokeredMessage, we can retrieve the body:
1: var recdOrder = recdMsg.GetBody<Order>();
2: Console.WriteLine("Received Order {0} with total of ${1}",recdOrder.OrderId,recdOrder.Total);
The cool thing about the CTP is that Microsoft is offering you a free labs environment in which to explore and play. In the CTP, you can create a maximum of 100 queues, with a maximum size of 100MB each and messages can not exceed a payload size of 256KB- pretty workable constraints for a first CTP.
To get started, and dive in for yourself, be sure to download the Azure AppFabric V2 SDK at: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=D89640FC-C552-446E-AEAD-B1E0D940F31B
In my next post, we’ll explore Topics and Subscriptions which allow for rich pub-sub including the ability to multicast to thousands of potential subscribers.
Hats off to the AppFabric Messaging team for all of their hard work with this release!