Wade Wegner

Ryan Dunn and Steve Marx have a great show on Channel9 called the Cloud Cover Show.  I’ve been watching it since the beginning, and have learned a lot about different features of the Windows Azure Platform, the latest news and announcements, as well as tips and tricks.  Naturally, I was honored (and a bit scared) when they asked me to join them on the show to talk about the Windows Azure AppFabric Service Bus.

Let me state this for the record – I was right to be afraid! <grin>

Let’s talk about how I was introduced – Wegner Clawed.  Watch it for yourself.  If you aren’t laughing hysterically then there’s something wrong with you.  And for the record I am not related to Joe Wegner (at least I hope not)!

Next, Wade’s Funky Fresh Beat – a tribute to both Wegner Clawed and the funky beat in my post Using Social Web Providers in Less than 5 Minutes.  I’m moved that Steve took the time to put this together.

Of course, we did manage to spend some time talking about the Service Bus, and even showed a few demos (with a funky beat, I might add).

All-in-all, I had a ton of fun (despite losing a bit of dignity).  Can’t wait to come on again!

A couple months ago I wrote a post on how to host WCF services in IIS that expose themselves as endpoints on the Windows Azure AppFabric Service Bus.  The principal challenge in this scenario is that IIS/WAS relies on message-based activation and will only launch the host after the first request comes in.  However, until the host is launched the service will not connect to the Service Bus, and consequently will never receive a message.  A classic catch-22.

The solution I proposed was to leverage the Application Warm-Up Extension for IIS 7.5, which will proactively load and initialize processes before the first request arrives.  While this is acceptable, I’ve found a better solution using the Windows Server AppFabric Autostart (thanks to conversations with Ron Jacobs).

Windows Server AppFabric Autostart is a feature introduced in Windows 7 and Windows Server 2008 R2.  The primary use cases are for reducing the latency incurred by the first message and to host WCF transports/protocols for which their are no listener adapters.  As you can see, initializing the host so that it connects to the Service Bus is another benefit.

To set this up, ensure that you have installed Windows Server AppFabric on your machine.  I personally recommend you use the Web Platform Installer to do this for you (I detail how to do this in the first part of my post on Getting Started with Windows Server AppFabric Cache).  Once you have this installed, follow these steps:

1. Open IIS Manager.  Navigate to your web application.
2. Click on Configure in Actions pane.
3. Configure the application to either autostart all the services by choosing Enabled or specific services by choosing Custom.
4. If you specified Custom, navigate to the configuration panel for that specific service and turn autostart to Enabled.

Pretty straightforward.  I think you’ll like this solution, as it keeps everything within the AppFabric family.

Today the Windows Azure AppFabric team released an update to the SDK.  This release is what’s called a QFE (quick fix engineering) update that’s intended to address bugs or breaking issues.  To my knowledge, this is the first QFE for the Windows Azure AppFabric.  In this case, the QFE fixed one bug:

Adding a Ws2007HttpRelayBinding endpoint that uses TransportWithMessageCredential security mode to a ServiceHost that also exposes a local MEX endpoint (not visible through the Service Bus) using the mexHttpsBinding, causes the local MEX endpoint to stop working. Invoking the MEX endpoint results in an InvalidOperationException.

If you are not experiencing this bug, there is no need for you to download the new version of the SDK.

Here’s the post from the Windows Azure AppFabric team blog.

I was reading through the FAQ document for the Windows Azure platform this evening (what else is there to do on a Sunday night?), and I came across the following:

What is the Windows Azure AppFabric?

With AppFabric, Microsoft is delivering services that enable developers to build and manage composite applications more easily for both server and cloud environments. Windows Azure AppFabric, formerly called “.NET Services”, provides cloud-based services that help developers connect applications and services across Windows Azure, Windows Server and a number of other platforms. Today, it includes Service Bus and Access Control capabilities. Windows Server AppFabric includes caching capabilities and workflow and service management capabilities for applications that run on-premises.

Windows Azure AppFabric is built on Windows Azure, and provides secure connectivity and access control for customers with the need to integrate cloud services with on-premises systems, to perform business-to-business integration or to connect to remote devices.

The Service Bus enables secure connectivity between services and applications across firewall or network boundaries, using a variety of communication patterns. The Access Control Service provides federated, claims-based access control for REST web services. Developers can use these services to build distributed or composite applications and services.

I’ve spent a lot of time with the AppFabric, and believe I understand the intent of the above description.  But what about the rest of you?  If you have, or even if you haven’t, spent time using the AppFabric, how does this description resonate?  Does this help you understand the AppFabric, or are you left confused?  Do you understand it’s place and value in the larger Windows Azure platform?

I implore you to leave some feedback and let me know what you think.  Please, share your thoughts!  How can this be improved?