The Great Azure Update – 1.3, November 2010

Well here we are with the single biggest release for Windows Azure since it became available earlier this year. Little about this update is a surprise as everyone was covered in depth at PDC10 back in October. But as of yesterday we have the new 1.3 SDK and associated training kit. We also got an updated Windows Azure Management Portal. I won’t be diving deeply into any of these for the moment, the Windows Azure team has their post up on it and is doing a webcast tomorrow. So it seems unnecessary.

What I do want to do today is call out a couple things that the community at large has brought to light about the updates.

Wade Wegner, Microsoft’s Technical Evangelist for the Windows Azure AppFabric has invested a non-trivial amount of time updating the BidNow sample used at PDC for the latest release. I have it on good authority, that this is something Wade was really passionate about doing and excited to finally be able to share with the world.

The Azure Storage team has a blog post that outlines fixes, bugs, and breaking changes in the Azure 1.3 SDK.

The 1.3 Azure SDK is only for VS 2010 and will automatically update any cloud service solution you open once its been loaded. Additionally, all the new 1.3 features can not be used by deployed services until they are rebuilt using the new SDK and redeployed. This includes features like the remote desktop.

The new management portal includes enhanced functionality for managing Windows Azure and SQL Azure services. However, as yet there is no updated portal for the Azure AppFabric. Hopefully this will come soon. Additionally, if you’re using IE9, be sure to enable pop-ups when at the portal or you won’t be able to launch the SQL Azure Management Portal (previously known as project “Houston”).

The new portal, being a web app, takes a few moments to get your head wrapped around. So I put together a quick guide using the following image.


The “Silo” Selection area in the lower left is where we select which set of assets (SQL Azure, Azure AppFabric, Azure Connect, etc…) we want to work with. Once an area has been selected, we can then jump a bit on the left to the Navigation section to move around within our selected silo, switching SQL Azure database servers or moving between Windows Azure services. Once we select an item in the Navigation menu, we can then view it in the large Workspace area. Lastly, across the top is our tool bar or a Context Menu. I prefer the term context menu because the options on this menu and their enabled/disable state will vary depending on your selections in the other areas.

You can switch back and forth between the new and old portals easily. Just look for the links at the top (in the old) or bottom (on the new). This is helpful because not everything in the old portal is in the new one. I was helping a friend with a presentation and noticed the new portal doesn’t have the handy “connection strings” button that was in the old SQL Azure portal.

I can’t wait to start digging into this but unfortunately I’m still preparing for my talk on the Azure AppFabric at next week’s AzureUG.NET user group meeting. So get out there and start playing for me! I’ll catch up as soon as I can.

PS – ok Wade. Can I go to bed now? Winking smile


Enter the Azure AppFabric Management Service

Before I dive into this update, I want to get a couple things out in the open. First, I’m an Azure AppFabric fan-boy. I see HUGE potential in this often overlooked silo of the Azure Platform. The PDC10 announcements re-enforced for me that Microsoft is really committed to making the Azure AppFabric the glue for helping enable and connect cloud solutions.

I’m betting many of you aren’t even aware of the existence of the Azure AppFabric Management Service. Up until PDC, there was little reason for anyone to look for it outside of those seeking a way to create new issuers that could connect to Azure Service Bus endpoints. These are usually the same people that noticed all the the Service Bus sample code uses the default “owner” that gets created when a new service namespace is created via the portal.

How the journey began

I’m preparing for an upcoming speaking engagement and wanted to do something more than just re-hash the same tired demos. I wanted to show how to setup new issuers so I asked on twitter one day about this and @rseroter responded that he had done it. He was also kind enough to quickly post a blog update with details. I sent him a couple follow-up questions and he pointed me to a bit of code I hadn’t noticed yet, the ACM Tool that comes as part of the Azure AppFabric SDK samples.

I spent a Saturday morning reverse engineering the ACM tool and using Fiddler to see what was going on. Finally, using a schema namespace I saw in Fiddler, I had a hit on an internet search and ran across the article "using the Azure AppFabric Management Service" on MSDN.

This was my Rosetta stone. It explained everything I was seeing with the ACM and also included some great tidbits about how authentication of requests works. It also put a post-PDC article from Will@MSFT into focus on how to manage the new Service Bus Connection Points. He was using the management service!

I could now begin to see how the Service Bus ecosystem was structured and the power that was just waiting here to be tapped into.

The Management Service

So, the Azure AppFabric Management API is a REST based API for managing your an AppFabric service namespace. When you go to the portal and create a new AppFabric service namepace, you’ll see a couple of lines that look like this:


Now if you’ve worked with the AppFabric before, you’re well aware of what the Registry URL is. But you likely haven’t worked much with the Management Endpoint and Management STS Endpoint. These are the endpoints that come into play with the AppFabric Management Service.

The STS Endpoint is pretty self-explanatory. It’s a proxy for Access Control for the management service. Any attempt to work with the management service will start with us giving an issuer name and key to this STS and getting at token back we can then pass along to the management service itself. There’s a good code snippet at the MSDN article, so I won’t dive into this much right now.

It’s the Management EndPoint itself that’s really my focus right now. This is the root namespace and there are several branches off of it that are each dedicated to a specific aspect of management:

Issuer – where our users (both simple users and x509 certs) are stored

Scope – the service namespace (URI) that issuers will be associated with

Token Policy – how long is a token good for, and signature key for ACS

Resources – new for connection point support

It’s the combination of these items that then controls which parties can connect to a service bus endpoint and what operations they can perform. It’s our ability to properly leverage this that will allow us to do useful real work things like setup sub-regions of the root namespace and assign specific rights for that sub-region to users. Maybe even do things like assign management at that level so various departments within your organization can each manage their own area of the service bus. J

In a nutshell, we can define an issuer, associate it with a scope (namespace path) which then also defines the rules for that issuer (Listen, Send, Manage). Using the management service, we can add/update/delete items from each of these areas (subject to restrictions).

How it works

Ok, this is the part where I’d normally post some really cool code snippets. Unfortunately, I spent most of a cold, icy Minnesota Sunday trying to get things working. ANYTHING working. Unfortunately I struck out.

But I’m not giving up yet. I batched up a few questions and sent them to some folks I’m hoping can find me answers. Meanwhile, I’m going to keep at it. There’s some significant stuff here and if there’s a mystery as big as what I’m doing wrong, it’s that I’m not entirely sure why we haven’t heard more about the Management Service yet.

So please stay tuned…

What’s next?

After a fairly unproductive weekend of playing with the Azure AppFabric Management Service, I have mixed emotions. I’m excited by the potential I see here, but at the same time, it still seems like there’s much work yet to be done. And who knows, perhaps this post and others I want to write may play a part in that work.

In the interim, you get this fairly short and theoretical update on the Azure AppFabric Management Service. But this won’t be the end of it. I’m still a huge Azure AppFabric fan-boy. I will let not let a single bad day beat me. I will get this figured out and bring it to the masses. I’m still working on my upcoming presentation and I’m confident my difficulties will be sorted out by then.