I’ve put together a little tool to help with some development work I am doing. While Azure and .NET Services are still in CTP the tooling is a bit limited so, what with necessity being the mother of invention and all that, I’ve spent an afternoon hacking together my Service(Bus)Browser.

Basically, all the endpoints you create in a .NET Services solution – routers, queues, relay endpoints etc – are all listed in the service registry which is exposed as an Atom feed at the base URL of your solution. So, if you create a solution called “MySolution”, your registry root is at https://mysolution.servicesbus.windows.net. Point your favourite web browser at it and you’ll see what I mean.

However, only endpoints whose discoverability policy is set to public will appear unless you also submit the correct credentials when requesting the Atom feed. Here’s an example :

We can see three entries in the feed each denoting a node in the registry. Submitting a similar request to the URL of a node will retrieve the Atom feed of its child nodes and so on. Here’s the Atom feed for the testrouters node :

That’s the entry for a router along with an Atom extension element describing the router policy.

Here’s the UI. It’s basically a TreeView for the registry nodes, a PropertyGrid for the node properties and a RichTextBox for the raw Atom.

Currently it will manage multiple solutions, walk the Atom tree, display the nodes and their properties, policies and subscriptions. It also allows you to delete queues and routers. Next steps, when I get a bit more time, are to fix the subscription display for the router nodes and to allow the creation of routers and queues (and perhaps subscriptions). Current impediments, other than time, are that the Atom feed to the subscription URL on a router always seems to come back empty even when there are subscriptions 😦

You can download the source here. Feedback and comments welcome unless they are a 17 page treatise on why I should have used [insert your favourite UI stack here] and the [insert your favourite pattern here] pattern 🙂

Please note : Since I wrote this article and posted the code there have been a number of changes to .NET Services, the Service Bus and the Access Control Service, most notably in the November CTP where, amongst other things, we lost Routers and Queues. As a result this code will no longer work. I am working on an updated solution that demonstrates the same functionality which I will post as soon as it’s ready.

Like this:

I presented to the UK Azure User Group at Microsoft in London last night. Thanks to everyone who came along and thanks also for all the kind words afterwards. I’m glad so many of you enjoyed it. As promised my slide deck and demo code are now available for download here.

I’ve tried to make the demo as self-contained as possible so anyone can get it up and running easily. However, please read the setup and prerequisite instructions included in the solution and if you have any problems don’t hesitate to drop me an email and let me know.

Also, if you think the .NET Services and Service Bus components of the Azure Services Platform are cool, exciting, compelling, interesting, useful, revolutionary or any of the other terms I heard used last night, please make some noise about it and about anything you are doing with them. Microsoft do monitor the community chatter during a CTP to guage the response to different features and we should be as quick, as loud and as forthright coming forward with our positive responses to these things as we are when they go wrong or we find bugs.

Thanks again.

Please note : Since this presentation there have been a number of changes to .NET Services, the Service Bus and the Access Control Service, most notably in the November CTP where, amongst other things, we lost Routers and Queues. As a result this code will no longer work.It would also seem that both the UKAzureNet site and ExposareRoom.com have shut down so there’s no video anymore 😦 I will attempt to find a backup 🙂

Like this:

A couple of niggles have come to light today. The first one is that Windows Azure does not seem to support the latest version of the Azure .NET Services Bus. The recent release of the .NET Services SDK, the July CTP, included a new version of Microsoft.ServiceBus.dll (0.16.0.0). This version is not available on Windows Azure. After I had updated my SDK I rebuilt and redeployed a Windows Azure cloud application with a Web Role that calls service bus endpoints. This started throwing all kinds of odd exceptions which was confusing as it (of course) worked fine on my machine. I eventually tracked the issue down and the only way round it at the moment is to set the Copy Local property in the properties of the reference to Microsoft.ServiceBus.dll to true. That way it will get deployed with the application.

The second issue was a kind of two in one. I’m developing some prototypes for Windows Mobile using the .NET Compact Framework 3.5. One of the things I’m working on is a method of keeping mobile devices synchronised via .Net Service Bus queues and routers. There is no native support for the Service Bus on .NETCF but fortunately I only need to make REST calls using a meteor pattern to poll a queue for sync messages.

I had two problems. The first was that I could only poll a queue twice using HttpWebRequest before I’d start getting timeouts. This turned out to be because I was hitting the max connections limit (2 by default), even though I was carefully disposing of responses and closing response streams etc. The second was that I would always get an ObjectDisposedException at System.Threading.WaitHandle.CheckResultInternal when I closed the application. The polling of the queue was of course being done on a background thread, so looking at the two together it did seem that some resource was not being correctly released somewhere.

Looking into the stack trace of the ObjectDisposedException exception I could see references to HttpWebRequest and stream writes. It occurred to me that because I was using REST I was only ever sending headers in my HttpWebRequests, and no body. When I was calling WebRequest.Create() it was possible that the request stream was being opened and because I wasn’t using it it never got closed. As these requests were being created on my background thread they would not dispose correctly and they would continue to consume connection resources and possibly casue thread termination exceptions.

The answer was to close the request stream before sending the request :

Like this:

I was preparing a blog post on easyJet’s new HALO patform and the work we’ve been doing with the Microsoft Azure Services Platform and mobile devices. However it seems Computer Weekly have jumped the gun. More to follow, but here’s the first scoop :

Warning

When this blog got transferred from LiveSpaces some of the code formatting got messed up. I'm fixing this when I can be arsed (which isn't often) but if there's something bugging you let me know and I may have mercy.