Due to the breaking changes introduced by the production version of the Service Bus Messaging API with respect to the CTP version, this version of the Service Bus Explorer tool doesn’t compile against the API contained in the Windows Azure AppFabric SDK V1.5 and cannot be used to managed entities in a Service Bus namespace in production. I published a new version of the Service Bus Explorer tool on MSDN and the related code on MSDN Code Gallery.
The Community Technology Preview (CTP) of Windows Azure AppFabric that was released in May 2011 introduced Queues and Topics that constitute the foundation of a new cloud-based messaging and integration infrastructure that provides reliable message queuing and durable publish/subscribe messaging capabilities to both cloud and on-premises applications based on Microsoft and non-Microsoft technologies. The new messaging functionality can be seamlessly accessed by .NET applications via a brand-new managed API (Microsoft.ServiceBus.Messaging) or WCF thanks to a new binding (ServiceBusMessagingBinding) as well as by any Microsoft or non-Microsoft applications that support HTTP requests via a REST API over HTTPS. In order to exploit the messaging capabilities introduced by Queues and Topics, it’s necessary to create a namespace on the Windows Azure Management Portal. However, the latter does not provide any user interface to administer, create and delete Topic and Queue entities. To accomplish this task, you can use both the .NET API or the REST-style interface exposed by the new messaging platform. For this reason, I decided to build a Windows Forms application that allows to connect to a given Service Bus namespace to create, delete and test messaging entities. This post is the first of a multi-part article where I will explain the functioning and implementation details of my tool whose source code is available on MSDN Archive for use or modification by any developer. In particular, in the first part I will explain how to use my tool to manage and test Queues and Topics whereas in the second post I will go through the code and explain the approach I followed to realize the application.
The following section provides basic information on the Queue and Topic entities in Windows Azure AppFabric Service Bus. For more information, see the following articles:
Queues provide messaging capabilities that enable a large and heterogeneous class of applications running on premises or in the cloud to exchange messages in a flexible, secure and reliable fashion across network and trust boundaries.
Queues are hosted in Windows Azure by a replicated, durable store infrastructure. The maximum size of a queue during the CTP is 100MB, which is expected to rise to 1GB (or more) for production. The maximum message size is 256KB, but the use of sessions allows creating unlimited-size sequences of related messages. Queues functionality are accessible through the following APIs:
Queue entities provide the following capabilities:
In the .NET API the message entity is modeled by the BrokeredMessage class that exposes various properties such as MessageId, SessionID and CorrelationId that can be used to exploit capabilities such as automatic duplicate detection or session-enabled communications. A QueueDescription object can be used to specify the metadata that models the behavior of the queue being created:
The use of Queues permits to flatten a highly-variable traffic into a predictable stream of work and distribute the load across a set of worker processes which size can vary dynamically to accommodate the incoming message volume. In a Competing Consumers scenario, when a publisher writes a message to a queue, multiple consumers compete with each other to receive the message, but only one of them will receive and process the message in question.
In a service-oriented or a service bus architecture composed of multiple, heterogeneous systems, interactions between autonomous systems are asynchronous and loosely-coupled. In this context, the use of messaging entities like Queues and Topics (see the next section) allows to increase the agility, scalability and flexibility of the overall architecture and helps decreasing the loose coupling of individual systems.
For more information on Queues, see the following articles:
Topics extends the messaging features provided by Queues with the addition of Publish-Subscribe capabilities.
A Topic entity consists of a sequential message store like a Queue, but it supports up to 2000 (this number is subject to vary in the future) concurrent and durable subscriptions which relay message copies to a poll of worker processes. Each Subscription can define one or multiple Rule entities. Each Rule specifies a filter expression that is used to filter messages that pass through the subscription and a filter action that can modify message properties. In particular, the SqlFilterExpression class allows to define a SQL92-like condition on message properties:
Conversely, the SqlFilterAction class can be used to modify, add or remove properties, as the filter expression is true and the message selected, using a syntax similar to that used by the SET clause of an UPDATE SQL-command.
Each matching rule generates a separate copy of the published message, so any subscription can potentially generate more copies of the same message, one for each matching rule. As Queues, Topics support a Competing Consumers scenario: in this context, a subscritpion can have a single consumer that receives all messages or a set of competing consumers that fetch messages on a first-come-first-served basis. Topics are the excellent messaging solution to broadcast messages to many consumer applications or distribute the work load across multiple sets of competing worker processes.
As I mentioned in the introduction, today the Windows Azure Platform Management Portal provides the ability to create, modify and delete a Service Bus namespace but it doesn’t offer any GUI to manage Queues and Topics entities.
A few months ago I created a Storage Services Explorer tool to handle Windows Azure Storage Services: Blobs, Queues and Tables, therefore I decided to undertake a similar project and develop a Service Bus Explorer to manage Topics and Queues. The following picture illustrates the architecture of the application:
In the remainder of the article I'll explain how to configure and use the Service Bus Explorer, whereas in the second part of this series I'll dive into the code and I'll provide technical details on the actual implementation.
When you launch the application, you can connect to an existing Service Bus namespace to manage its entities by choosing the Connect command under the File menu. This operation opens up a modal dialog shown in the picture below that allows you to enter the name of the Service Bus namespace that you want to connect to and the corresponding authentication credentials.
The Service Bus supports three different types of credential schemes: SAML, Shared Secret, and Simple Web Token, but this version of the Service Bus Explorer supports only Shared Secret credentials. However, you can easily extend my code to support other credential schemes. You can retrieve the issuer-secret key from the Windows Azure Platform Management Portal by clicking the View button highlighted in red in the picture below after selecting a certain namespace in the Service Bus section.
This opens up the modal dialog shown in the picture below where you can retrieve the key by clicking the Copy to Clipboard highlighted in red.
Note: by convention, the name of the Default Issuer is always owner.
For your convenience, the tool gives the possibility to define, in the configuration file, a connection string for the most frequently accessed namespaces. As you can see in the xml snippet below, each connection string is composed of 4 elements:
System, Version=220.127.116.11, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
<trace autoflush="true" indentsize="4">
<add key="debug" value="true"/>
<add key="scheme" value="sb"/>
<add address="*" maxconnection="50"/>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
If you define one or more namespaces in the configuration file, this give you the possibility to select one of them from the corresponding drop-down list and the fields within the modal dialog will be automatically populated with the corresponding connection string data.
The GUI of the Service Bus Explorer is composed of following parts:
To view the properties of an existing queue in the Main Panel, you can just select the corresponding node in the TreeView.
As already mentioned above, the current version of the Service Bus (June 2011 CTP Refresh) does not allow to change the properties of an existing queue once created. The same principle applies to the other entities.
To create a new queue in the current namespace, you can select the Queues node in the TreeView and then perform one of the following actions:
This operation displays a custom control (see the picture below) in the Main Panel that allows you to specify the following properties for the new queue:
If you don’t explicitly specify any value for one or more fields, when you click the Create button, the default value will be used for the corresponding properties.
To delete an existing queue, you can select the corresponding node in the TreeView and then perform one of the following actions:
To test a queue in the current namespace, you can select the corresponding node in the TreeView and then perform one of the following actions:
This operation shows a custom control (see the picture below) in the Main Panel that allows the user to specify the following options:
Message Text and Properties Section
You can enable logging to trace the content and properties of sent and received messages and keep track of performance statistics:
The following picture shows an example of the information that you can track and eventually archive by saving the log.
To view the properties of an existing topic in the Main Panel, you can just select the corresponding node in the TreeView.
As already mentioned above, the current version of the Service Bus (June 2011 CTP Refresh) does not allow to change the properties of an existing topic once created. The same principle applies to the other entities.
To create a new topic in the current namespace, you can select the Topics node in the TreeView and then perform one of the following actions:
This operation displays a custom control (see the picture below) in the Main Panel that allows you to specify the following properties for the new topic:
To delete an existing topic, you can select the corresponding node in the TreeView and then perform one of the following actions:
To test a topic in the current namespace, you can select the corresponding node in the TreeView and then perform one of the following actions:
Message Text and Properties Section
To view the properties of an subscription associated to a certain topic, you can expand the Subscriptions node under the topic node and select the corresponding subscription node, as illustrated in the picture below.
To add a new subscription to an existing topic, you can select the topic node in the TreeView and then perform one of the following actions:
This operation displays a custom control (see the picture below) in the Main Panel that allows you to specify the following properties for the new subscription:
To remove an existing subscription, you can select the corresponding node in the TreeView and then perform one of the following actions:
To view the properties of an rule associated to a certain subscription, you can expand the Rules node under the subscription node and select the corresponding rule node, as illustrated in the picture below.
To add a new rule to an existing subscription, you can select the subscription node in the TreeView and then perform one of the following actions:
This operation displays a custom control (see the picture below) in the Main Panel that allows you to specify the following properties for the new rule:
To remove an existing rule, you can select the corresponding node in the TreeView and then perform one of the following actions:
I strongly encourage you to download and customize my code it to better accommodate your needs. As always, I invite you to share with me your feedbacks, ideas and comments, not only on my tool but also (and above all) on the new messaging entities in the Service Bus. In the second part of this article I’ll illustrate the implementation details of the solution.
Why is the service bus explorer trying to connect to sb://<namespace>.servicebus.appfabriclabs.com instead of sb://<namespace>.servicebus.windows.net ? How can we change it?
the answer to your question is pretty straightforward: the tool tries to connect to sb://<namespace>.servicebus.appfabriclabs.com instead of sb://<namespace>.servicebus.windows.net because the messaging features (Topics & Queues) of the Service Bus are actually available only in Beta and not via existing namespaces in the Windows Azure production site. As soon as the messaging services will be available in the production site, a new version of the Service Bus API will be available which will connect to sb://<namespace>.servicebus.windows.net. When will this happen? Soon! :-)
Great post and really nice and useful blog!
Thanks for the positive feedback. FYI, in a few weeks I'll post a new version of the tool with many additional features! So stay tuned and don't hesitate to contact me here on via email. ;-)
many thanks for your availability :-) and for your blog
Outstanding article and utility. Both have been invaluable in allowing me to move forward with Topics and subscriptions. Looking forward to to your planned new versions.
Thanks Michael, I'll soon publish a new version of the tool so... stay tuned! :-)
Is it possible to use the brokering mechanism (i.e. leverage the benefits of topics and subscriptions) to multicast or must we still use the netEventRelayBinding. Seems to me like the brokering mechanism described here only supports "competing consumer" scenarios.
The answer is definitely yes, you can use topics and subscription in a pub/sub multicast scenario. My plan is to write an article to compare the netEventRelayBinding with the topics and subscriptions so your question is really spot-on. More on this blog soon. :) Besides, in one or two weeks I'll publish a new version of the Service Bus Explorer that supports the new version of the Service Bus API and with many new features, so stay tuned!