Wade Wegner

On an email thread today, someone was looking for suggestions on how to start a job simultaneously across multiple worker roles running in Windows Azure.  For example, image you have ten worker roles already running and, through the command of an admin or user, you want to “release the hounds!”

Definitely an interesting scenario, and many different ways to approach it.  Initial ideas and thoughts centered around using Windows Azure storage tables or blobs – in fact, Steve Marx quickly threw out some pseudo code highlighting a reasonable way to approach the problem:

   1: while (blob.DownloadText() != “RELEASE THE HOUNDS!”)

   2:     Thread.Sleep(TimeSpan.FromSeconds(1));

   3: // do the actual work

Then to release:

   1: blob.UploadText(“RELEASE THE HOUNDS!”);

You could definitely take this approach and have success.

Of course, to me this scenario screamed multicasting with NetEventRelayBinding.

NetEventRelayBinding supports multiple listeners on the same URI, which means that you can have 1 or 1000 worker roles in Windows Azure all listening to the same URI – this gives you the ability to push out events to all listeners, as any message sent by a client gets distributed to all the listeners.

Clemens Vasters sums NetEventRelayBinding it up nicely on his blog:

The NetEventRelayBinding doesn’t have an exact counterpart in the standard bindings. This binding provides access to the multicast publish/subscribe capability in the Relay. Using this binding, clients act as event publishers and listeners act as subscribers. An event-topic is represented by an agreed-upon name in the naming system. There can be any number of publishers and any number of subscribers that use the respective named rendezvous point in the Relay. Listeners can subscribe independent of whether a publisher currently maintains an open connection and publishers can publish messages irrespective of how many listeners are currently active – including zero. The result is a very easy to use lightweight one-way publish/subscribe event distribution mechanism that doesn’t require any particular setup or management.

So, the architecture might look something like this:

In this scenario, an admin sitting on a laptop can send a message to the Service Bus, which in turn relays the message to all the listeners.  When the worker roles receive the message they will “release the hounds” and process whatever it is they need to process.

Note: this approach is just as valid for listeners that don’t reside in Windows Azure.  For example, if you have an application that is distributed across PCs and you want to send every client a message (without implementing some form of polling) this is the perfect approach.

So, without further ado, here’s the code to release the hounds!

Now, a few comments on the code:

• I wrote this using Visual Studio 2010 RTM. Your mileage may vary.
• Make sure you have the Windows Azure SDK and the Windows Azure AppFabric SDK.
• The first thing you’re going to want to do is search on YOURSERVICENAME and YOURISSUERSECRET and replace with your own values.
• It’s initially configured to run locally.  Just hit F5.
• When you run locally, three things will launch:
  1. The local development fabric, with two worker roles.
  2. A Windows Forms application with a big button (hey, it’s better than a console window!).
  3. A console window that displays traces from all your worker roles.  This is especially useful for getting information from your worker roles once you’ve deployed to Windows Azure.  I’ll blog on this another time.
• When you eventually deploy to Windows Azure, but sure to uncomment the <extensions> and <bindingExtensions> sections in the App.config, as the Windows Azure AppFabric SDK is not installed in Windows Azure, and it won’t understand NetEventRelayBinding.

I personally think this is a pretty neat solution, and can enable a lot of advanced scenarios.  I’d love to hear your feedback and comments.

If you take a look at the official Windows Azure platform website, you’ll see two definitions for the Windows Azure platform AppFabric (hereafter referred to as the Azure AppFabric) prominently called out:

• “… connects cloud services and on-premises applications.”
• “… helps developers connect applications and services in the cloud or on-premises.”

While the purpose of the Azure AppFabric seems clear to me – enable developers to connect applications and services – there are a couple things that generally cause confusion: execution and branding.  I plan to talk about how to use the Azure AppFabric quite a bit in the future, but in this post I want to address the branding.

The Azure AppFabric has been rebranded numerous times.  This isn’t surprising given that it has largely been a community technology preview, but it has lead to some confusion.

So, some brief history …

Note: this is based entirely on my cyber-sleuthing and personal experience.  I’m sure I have gaps and perhaps an inadvertent inaccuracy, so as I get corrected I’ll update.  I didn’t join Microsoft until early 2008, so the early days of the Azure AppFabric precedes my Microsoft employment.

In April 2007, the BizTalk Server team announced that the CTP release of BizTalk Services was live.  They had created an Internet Services Bus (ISB) that allowed developers to create “Internet scale composite applications more rapidly.”  Clemens Vasters described this new ISB in a post.  Later, in July 2007, the BizTalk Server team talked about Hosted Workflows in BizTalk – an exciting extension to the ISB announcement.  Over time, Access Control was added into the mix as well.

Soon, word of Project Zurich started hitting the airways.  Mary-Jo Foley wrote about “’Zurich,’ Microsoft’s elastic cloud” back in July 2008, describing it as an initiative to “extend Microsoft’s .NET application development technologies to the Internet ‘cloud.’” Close, but not quite right.  My first introduction to Project Zurich came while working on a project with RedPrairie on a supply chain proof-of-concept, that ultimately culminated in a Bob Muglia keynote demonstration at PDC 2008 (around 59 minutes).

At the Professional Developers Conference (PDC) 2008 the platform was rebranded .NET Services and included as part of the Azure Services Platform.  You can actually still see some of the .NET Services branding on this BizTalk Service page.  By the fall of 2008, .NET Services had emerged as a mature platform (even though still in CTP) consisting of an Internet Service Bus, an Access Control Service (ACS), and Workflow Service.  In June 2009, the .NET Services team announced that they were pulling the Workflow Service.  As Windows Workflow Foundation in .NET 4.0 evolved, it was clear that most customers wanted Workflow Services to also follow to the .NET 4.0 model (not .NET 3.5), which it was not.  Consequently, .NET Services team pulled workflow and focused on the ISB and ACS.

At PDC 2009, .NET Services went through it’s most recent branding change, and was eventually launched in 2010 as the Windows Azure platform AppFabric.  Of course, this is a really long name, so most people just end up saying Windows Azure AppFabric or just Azure AppFabric. 

The biggest challenge I see today with the name is that, at PDC 2009, we also rebranded “Dublin” and “Velocity” as the Windows Server AppFabric – almost too much name overloading, although there are some good reasons for it that will emerge over time.  To make things clear, I’ll always say either Azure AppFabric or Server AppFabric.

If you really take a look at how this all has evolved, you can start to see how Microsoft’s cloud platform strategy has evolved over the last several years.

So, where does this leave us?

In my opinion, it leaves us with a technology that is a key differentiator in Microsoft’s cloud platform.  I’m not just saying this – I really believe it, or I wouldn’t be moving my family up to Redmond so that I can focus on it.

In closing, let’s be clear on two things – in Azure AppFabric, there’s both a Service Bus and Access Control Service.

The Service Bus is an Internet-scale enterprise service bus that makes it easy to connect applications over the Internet. Services that register on the Service Bus can easily be discovered and accessed across any network topology.

The Access Controls Service helps you build federated authorization into your applications and services, without the complicated programming that is normally required to secure applications that extend beyond organizational boundaries.

Okay, now that I’ve spent a little time  covering some history and the past, expect to see a major focus on what you can do today – and lots of code and examples.

Hope this helps.

I am excited to share that I’m taking the role of Technical Evangelist for the Windows Azure platform, focused on the Azure AppFabric.  I’m joining James Conard’s team that focuses on Windows Azure platform evangelism, working with David Aiken, Ryan Dunn, Zach Owens, and Vittorio Bertocci – truly an all-star team!  Oh, and I hope to spend a lot more time with Jack Greenfield, Clemens Vasters, Justin Smith, and everyone else on the AppFabric team!

So, what is the Windows Azure platform AppFabric (other than a mouthful)?

That’s one of the things I hope to de-mystify in my new role.  Expect to see me talking a lot about it in the future.

The best part about focusing on the Azure AppFabric is that it doesn’t restrict me to just one technology – because the Azure AppFabric is the glue that integrates and secures applications across the Internet, I’ll get to leverage the entire Windows Azure platform, various mobile platforms, web technologies, and almost everything else in our technology stack – not to mention interoperability with other platforms!

So, what does taking this role mean?

• I’m moving the entire family to Redmond, WA. Incidentally, want to buy a house in Glen Ellyn, IL?
• I hope to spend more time in Visual Studio than in Outlook.
• I’m going to spend a lot more time writing blog posts and recording screen casts.  Lots of really neat things to share.
• I’ll continue speaking at events like PDC, TechEd, and MIX, and hope to hit even more online and local events.
• I want to work with all of you to find new and interesting ways to leverage the Azure AppFabric.

I am leaving an amazing group of people here in Central Region DPE.  I want to thank everyone on my team – both local and extended – for making my time as an Architect Evangelist enjoyable and fulfilling.

See you soon in Redmond!

George Huey has done it again!  He has just published some significant updates to the SQL Azure Migration Wizard.

Previously, I’ve described the SQL Azure Migration Wizard as a tool that helps you migrate your SQL Server database into SQL Azure.  This is still true, but now, thanks to updates made by George Huey, you can also migrate from SQL Azure-to-SQL Server and SQL Azure-to-SQL Azure.  These are significant updates to the tool!

Please watch the following video for an updated explanation of the tool:

As I said, the updates made by George enable all the following scenarios for database migration …

• SQL Server-to-SQL Azure
• SQL Azure-to-SQL Server
• SQL Azure-to-SQL Azure

These last two updates are significant!  Take a look at this thread on the SQL Azure Migration Wizard codeplex site – the user had a scenario where they wanted to migrate a 1 GB database in SQL Azure into a 10 GB database in SQL Azure.

Please take a look at the SQL Azure Migration Wizard up on Codeplex, where you can download the source code and/or binaries.

Last week I presented at the Wisconsin Azure User Group for the second time, along with Clark Sell.  Our goal was to provide an overview of everything announced at the Professional Developers Conference (PDC) 2009.  We made a ton of announcements, and I recommend you check out the Microsoft PDC website for more information, including videos and decks from all the presentations.

Shameless plug: watch my session on migrating applications to the Windows Azure platform with Accenture, CCH, Dominos, and Original Digital – Lessons Learned: Migrating Applications to the Windows Azure Platform.

While I was supposed to only spend twenty minutes talking about updates to the Windows Azure platform, I ended up spending over an hour.  There was too much information to share; here’s a short outline:

• Rebranding of the .NET Services as the Windows Azure platform AppFabric.
• Microsoft Codename “Dallas”, a content brokerage and discovery platform available as a CTP at commercial launch.
• Windows Azure platform integration with Microsoft Pinpoint.
• Enhanced service architectures (i.e. inner role communication, worker roles exposed outside the datacenter, etc.).
• Enhanced diagnostics in Windows Azure.
• Ability to use existing NTFS APIs to store data in durable drives in Windows Azure (called Windows Azure XDrive).
• Administrator privileges in the Windows Azure virtual machines.
• Deployment of pre-configured virtual machine images while still benefiting from the Windows Azure service model.
• User-selectable geo-locations for replicas of Azure storage.
• Secondary indices on Windows Azure tables.
• Content Delivery Network.
• Remote terminal server access to virtual machines.
• Tool for data synchronization called SQL Azure Data Sync, built on the Microsoft Synch Framework and ADO.NET Sync Services.
• Claims-based access control for REST web services through the Access Control Service.
• Commercial launch in and paid usage in February, 2010.
• Datacenter options in USA, Europe, and Asia.

Thanks to everyone for their patience – especially Clark – as I went on, and on, and on …

Don’t forget that you can request and redeem tokens for the Commercial Technology Preview (CTP) at http://windowsazure.com/.  This provides you free usages, with quotas, through February 1, 2010.

Here’s the deck I presented:

Thanks to everyone that attended – I had a great time!