AppFabric Team Blog

We’re Moving To The Windows Azure Team Blog

AppFabric Team — Mon, 12 Dec 2011 21:48:00 GMT

We are continually looking for ways to make it easier for you to stay on top of the latest product releases, resources, tools and news around Windows Azure. Today, we’re happy to announce another step in that direction with the consolidation of this team blog into the Windows Azure Team Blog. The Windows Azure team blog covers a wide variety of topics, from the latest news and announcements, to technical and “how-to” posts, as well as conversations with customers, partners and Windows Azure experts.

Starting today, the Windows Azure team blog is where you’ll be able to find the latest technical information about topics such as Service Bus, Access Control, Caching, Windows Azure-related workflow, as well as development, deployment, and management. (Generic workflow posts will continue to be posted to the Workflow team blog).

We hope these changes will make your life a little easier by making this blog your single destination for all the latest news and information about Windows Azure. Be sure to let us know what you think about these changes, as well as what kinds of information you’re like us to focus on by posting a comment to this post.

WF Azure Activity Pack CTP 1

Ron Jacobs — Wed, 31 Aug 2011 14:13:00 GMT

We’re so excited to announce that the WF Activity Pack for Azure has just been released! Please refer to our CodePlex page for the download information. The package is also available via NuGet, you can type “Install-Package WFAzureActivityPack” in your package manager console to install the activity pack.

The Azure Activity Pack is built on top of Windows Azure SDK (August Update, 2011). Please install the SDK on your development machine.

Introduction

The Microsoft WF Azure Activity Pack CTP 1 is the first community technology preview (CTP) release of Azure activities implementation based on Windows Workflow Foundation in .NET Framework 4.0 (WF4) and Windows Azure SDK. The implementation contains a set of activities based on Windows Azure Storage Service and Windows Azure AppFabric Caching Service, which enables developers to easily access these Azure services within a workflow application.

This Activity Pack includes the following activities:

For Windows Azure Storage Service - Blob

PutBlob creates a new block blob, or replace an existing block blob.
GetBlob downloads the binary content of a blob.
DeleteBlob deletes a blob if it exists.
CopyBlob copies a blob to a destination within the storage account.
ListBlobs enumerates the list of blobs under the specified container or a hierarchical blob folder.

For Windows Azure Storage Service - Table

InsertEntity<T> inserts a new entity into the specified table.
QueryEntities<T> queries entities in a table according to the specified query options.
UpdateEntity<T> updates an existing entity in a table.
DeleteEntity<T> deletes an existing entity in a table using the specified entity object.
DeleteEntity deletes an existing entity in a table using partition and row keys.

For Windows Azure AppFabric Caching Service

AddCacheItem adds an object to the cache, or updates an existing object in the cache.
GetCacheItem gets an object from the cache as well as its expiration time.
RemoveCacheItem removes an object from the cache.

Sample

We’ve prepared a sample for this Activity Pack, which is a simple application for users to upload a file, and view all file entities available in the system. The sample solution is created from the template of Windows Azure Project. Please refer to our CodePlex page for the source code and document of the sample.

Screenshots

Here’s what they look like in Microsoft Visual Studio.

You can configure the activity in the property grid.

There’re 4 generic activities for Azure Table service, and you need to specify the table entity type when adding them to the designer canvas. The type you specified should inherit from TableServiceEntity.

Notice

Activities in this Activity Pack don’t have special logics for handling potential exceptions. All exception behaviors are consistent with the Managed Library API provided by the Azure Service. For example, if the GetBlob activity tries to get a blob that doesn’t exist, a StorageClientException will be thrown.

So, please get prepared for the potential exceptions that may occur in the workflow. Today, the simplest approach is to wrap a TryCatch activity outside of the Azure activity.

For more information on the error handling in Windows Workflow Foundation, please refer to the “Transactions and Error Handling” section in the article “A Developer's Introduction to Windows Workflow Foundation (WF) in .NET 4”.

Feedback

You’re always welcome to send us your thoughts on WF Azure Activity Pack, and please let us know how we can do it better. You can leave feedback:

Here on the blog comments.
Open an Issue at wf.CodePlex.com

Thanks!

How to create a Custom Activity Designer with Windows Workflow Foundation (WF4)

Ron Jacobs — Mon, 15 Aug 2011 01:15:32 GMT

The Windows Workflow Foundation (WF4) - Custom Activity Designer sample demonstrates how you can build an activity and activity designer. It includes three projects

MyActivityLibrary - The activity library project
MyActivityLibrary.Design - The activity designer project
TestDesigner - A rehosted designer project useful for testing the activity

Step 1: Create the Activity

The first step is to build your activity. Don't create a designer until you are satisifed with the interface to your activity in terms of arguments and properties. This sample includes a native activity named MyActivity which simply returns a string with the activity values.

The activity includes an InArgument and two properties including an enumerated value so you can see how to use these with your activity designer.

   1: public sealed class MyActivity : NativeActivity<string>

   2: {

   3:     public MyEnum Option { get; set; }

   4:     public bool TestCode { get; set; }

5:

   6:     [DefaultValue(null)]

   7:     public InArgument<string> Text { get; set; }

8:

   9:     protected override void Execute(NativeActivityContext context)

  10:     {

  11:         this.Result.Set(

  12:             context,

  13:             string.Format(

  14:                 "Text is {0}, TestCode is {1}, Option is {2}",

  15:                 context.GetValue(this.Text),

  16:                 this.TestCode,

  17:                 this.Option));

  18:     }

  19: }

Step 2: Add the Design Project

Visual Studio uses a naming convention to locate an associated designer project. Since our assembly is named MyActivity.dll, Visual Studio will attempt to load MyActivity.Design.dll.

Select File / Add / New Project
Choose the Activity Designer Library project template
Name the project MyActivityLibrary.Design

Step 3: Add RegisterMetadata method

The activity designer class should include a method to register the metadata for that designer.

   1: public partial class MyActivityDesigner

   2: {

   3:     public MyActivityDesigner()

   4:     {

   5:         this.InitializeComponent();

   6:     }

7:

   8:     public static void RegisterMetadata(AttributeTableBuilder builder)

   9:     {

  10:         builder.AddCustomAttributes(typeof(MyActivity), new DesignerAttribute(typeof(MyActivityDesigner)));

  11:         builder.AddCustomAttributes(typeof(MyActivity), new DescriptionAttribute("My sample activity"));

  12:     }

  13: }

Step 4: Add Metadata Class

Add a class that implements System.Activities.Presentation.Metadata.IRegisterMetadata. This class will be invoked at runtime to add attributes to the activity class. In the sample, I've added a static method called RegisterAll() which will register all of the activities contained in this library. This method is called from the test designer.

   1: public sealed class MyActivityLibraryMetadata : IRegisterMetadata

   2: {

   3:     public void Register()

   4:     {

   5:         RegisterAll();

   6:     }

7:

   8:     public static void RegisterAll()

   9:     {

  10:         var builder = new AttributeTableBuilder();

  11:         MyActivityDesigner.RegisterMetadata(builder);

  12:         // TODO: Other activities can be added here

  13:         MetadataStore.AddAttributeTable(builder.CreateTable());

  14:     }

  15: }

Step 5: Add an activity image to your Design Project

Your designer should include a 16x16 ToolBox image. The sample application includes the image QuestionMark.png in the activity library. The Build Action for this file should be set to Resource

Step 6: Add the ToolboxBitmap

To support a Toolbox Bitmp you will need to add the activity image to your activity library project also and set the Build Action to Embedded Resource. The sample application has included the file QuestionMark.png as a linked file from the design project.

Next go back to your activity class and add the ToolboxBitmap attribute

   1: // TODO: Be sure the build action for your bitmap is set to Embedded Resource

   2: [ToolboxBitmap(typeof(MyActivity), "QuestionMark.png")]

   3: public sealed class MyActivity : NativeActivity<string>

Step 7: Create The Designer

The XAML in the Activity Designer Library template is for a simple designer. This sample includes a designer with support for Expand/Collapse and an activity image as well as a drop down list with enumerated values.

Here is the collapsed view where you would show only the most important values

And this is the expanded view where you can add more commonly access properties. Remember the property grid allows access to other properties that are not included on the design surface.

Step 8: Configure the Designer project for debugging

There are two options for debugging your designer project. The recommended approach is to debug with a re-hosted designer application such as the one included with this application. Set the project properties as shown for debugging support.

To test with Visual Studio it is best to use the Experimental Instance option. Debugging with Visual Studio can take a long time so it is best to test by starting without debugging.

And that’s it. Now all you need to do is manage the WPF side of things. Check the sample to see how it’s done.

Happy Coding!

Ron Jacobs
http://www.ronjacobs.com
@ronljacobs

Announcing The End of The Free Promotional Period for Windows Azure AppFabric Caching

AppFabric Team — Mon, 01 Aug 2011 21:18:45 GMT

For the past few months, we have offered the Windows Azure AppFabric Caching service free of charge for the promotional period that ends July 31, 2011. For all billing periods beginning on August 1, 2011 onward, we will begin charging at the following standard monthly rates:

$45.00 for a 128MB cache
$55.00 for a 256MB cache
$75.00 for a 512MB cache
$110.00 for a 1GB cache
$180.00 for a 2GB cache
$325.00 for a 4GB cache

If you are signed up for one of the Windows Azure Platform offers, it may include a 128MB cache option at no additional charge for a certain period of time, depending on the specific offer. You can find out whether your offer includes a 128MB cache at no additional charge by going to our page that lists our various Windows Azure Platform offers.

If you are using caching and do not desire to be billed, please be sure to stop using caching in excess of what is included with your offer immediately.

If you have any questions about the Windows Azure platform or the Windows Azure AppFabric Caching service, please visit our support page.

Thank you for your continued interest in the Windows Azure platform.

Windows Workflow Foundation - WF Migration Kit CTP 2 Released

Ron Jacobs — Mon, 01 Aug 2011 14:16:58 GMT

Update

We’re happy to announce that CTP 2 version of WF Migration Kit has been released to CodePlex, please refer to our CodePlex page for more information. The new State Machine activity for WF 4 is released with the .NET Framework 4 Platform Update 1 in April, 2011. In our CTP 2 release, we’ve added the support of State Machine migration.

If you already have CTP 1 installed, the CTP 2 installation will remove CTP 1 version on your machine.

Introduction

The WF Migration Kit helps users migrate WF3 (System.Workflow) artifacts to WF4 (System.Activities). The high level goal is to migrate workflow definitions and declarative conditions, but not code (such as workflow code-beside methods). Some WF3 workflows will be fully migratable to WF4, while others will be partially migratable and will require manual editing to complete the migration to WF4.

The WF Migration Kit provides an API as well as a command line executable tool, which is a wrapper around the API. Migrators are included for some, but not all, of the WF3 out-of-box activities. The WF Migration Kit offers an extensibility point so that custom activity migrators can be developed by third parties.

Activity migrators are provided for the following WF3 activities:

Delay
Throw
Terminate
Send, Receive
CallExternalMethod, HandleExternalEvent (requires ExternalDataExchangeMapping information)
Sequence, SequentialWorkflow
IfElse, IfElseBranch
While
Parallel
Listen
Replicator
TransactionScope
CancellationHandler, FaultHandlers, FaultHandler
StateMachineWorkflow, State, StateInitialization, StateFinalization, SetState, EventDriven

The WF Migration Kit CTP runs on top of the Visual Studio 2010 and .NET Framework 4, which can be found here. Please note that the Client Profile of the .NET Framework 4 is not sufficient since it does not contain the WF3 assemblies. State Machine migration requires .NET Framework 4 Platform Update 1, which can be found here.

The WF Migration Kit is also available via NuGet.

State Machine Migration

Now let’s take a look at how WF Migration Kit can help us with State Machine migration. Please download WF Migration Kit CTP 2 Samples.zip from our CodePlex page.

The overall steps of State Machine migration includes:

Either download and install WF Migration Kit CTP 2 Setup.msi from CodePlex, or download WFMigrationKit package from NuGet.
Execute migration on the legacy workflow project: DelayStateMachine3.
Port migrated activities to the new workflow project: DelayStateMachine4.

Installation

You can download and install WF Migration Kit CTP 2 Setup.msi from CodePlex, or download WFMigrationKit package from NuGet.

Download and install WF Migration Kit CTP 2 Setup.msi from CodePlex.

Visit WF Migration Kit homepage on CodePlex.
Download WF Migration Kit CTP 2 Setup.msi from the page.
Install WF Migration Kit CTP 2.

The WF Migration Kit is installed in the %ProgramFiles%\Microsoft WF Migration Kit\CTP 2\ folder or %ProgramFiles(x86)%\Microsoft WF Migration Kit\CTP 2\ for 64-bit operating system.

Download WFMigrationKit package from NuGet.

Download NuGet Package Manager, and install.
Open a project in Microsoft Visual Studio 2010
Right click on References and choose Manage NuGet Packages.

In the Online tab search for WFMigrationKit. Click on Install button to download the package.

Close the dialog, open a Command Prompt window and change to the package tools directory. e.g:

cd WF Migration Kit CTP 2 Samples\StateMachineMigrationSamples\Begin\packages\WFMigrationKit.1.1.0.0\tools

Test migration on the legacy workflow project: DelayStateMachine3.

Compile the DelayStateMachine3 project, which produces an executable DelayStateMachine3.exe.
Copy DelayStateMachine3.exe to the installation directory (or package tools directory for NuGet) which contains WFMigrator.exe and Microsoft.Workflow.Migration.dll.
Execute the following command in the previously opened Command Prompt:

WFMigrator DelayStateMachine3.exe

A DelayWorkflow.xaml file has been generated in the current working directory. The migration completes with information indicating actions required to manually solve custom code activities not migrated during the execution.

Port migrated activities to the new workflow project: DelayStateMachine4.

Use Microsoft Visual Studio to add the DelayWorkflow.xaml file generated earlier to DelayStateMachine4 project.
Open DelayWorkflow.xaml.

Adjust the design canvas as you need.
Inspect WriteLine activities which have been emitted in places of custom code activities, and develop corresponding WF 4 activities for a manual migration.

Verify workflow behaviors after migration.

Feedback

You’re always welcome to send us your thoughts on WF Migration Kit, and please let us know how we can do it better. You can leave feedback

Here on the blog comments
Open an Issue at wf.CodePlex.com

Thanks!

Now Available: The June CTP of Windows Azure AppFabric Service Bus REST API from Java, PHP

AppFabric Team — Thu, 28 Jul 2011 17:30:00 GMT

Good news for all PHP and Java developers: today we are publishing some Windows Azure AppFabric Service Bus samples just for you.

Since the AppFabric Service Bus REST API can be used from almost all programming languages and operating systems, it makes it very easy for applications written on any platform to interoperate with each another through Windows Azure. To illustrate the point, we took the chat application that is already available as part of the Silverlight samples and made sample clients in PHP and Java that can all work seamlessly together.

You can download the new PHP and Java samples, as well as all others for all other supported environments, from CodePlex.

The Java application is implemented as a stand-alone client application and these are the steps you need to follow to build it:

Edit the src\config\appfabric.properties file and add your Service Namespace, Issuer Name and Issuer Secret Key (obtained here).
Compile the source using Apache Ant: navigate to the application directory in a command prompt and run “ant”.
Once the build is complete, cd to the new “dist” directory and run the jar file: “java –jar AppFabricChat.jar”.

To use the PHP app, you need to:

Add your Service Namespace, Issuer Name and Issuer Secret Key to application\configs\appfabric.ini (obtained here).
Then point your webserver at the “public” directory and browse to the site.

To set up a new site in IIS:

Open “Internet Information Services (IIS) Manager”
Click “View Sites”, then “Add Web Site…”
Give the site a name such as AppFabricChat and point “Physical path” to the “public” directory of the PHP application.
Pick port and hostname information, and click OK.
Click the link under “Browse Web Site” to see the application.

Note: If PHP isn’t enabled on your web server, use WebPI to install it.

We would really like to get your feedback on these Java and PHP samples, so please feel free to ask questions and provide feedback on this at the Windows Azure AppFabric CTP Forum.

Thanks!

Alessandro Catorcini
Principal Group Program Manager
Interoperability Strategy Team

Announcing the Windows Azure AppFabric July release

AppFabric Team — Mon, 25 Jul 2011 16:00:00 GMT

Today we are excited to announce several updates and enhancements made to the Windows Azure AppFabric Management Portal and the Access Control service.

Management Portal

Localization

As announced on the Windows Azure blog: Windows Azure Platform Management Portal Updates Now Available, the Windows Azure Platform Management Portal now supports localization in 11 languages. The newly supported languages are Japanese, German, Traditional Chinese, Simplified Chinese, French, Italian, Spanish, Korean, Russian, and Brazilian Portuguese.

Users can choose their desired language from the language chooser in the top left pane of the Portal.

You can read about additional enhancements in the blog post: Windows Azure Platform Management Portal Updates Now Available.

Co-admin support

Customers can grant access to additional users (Co-Administrators) on the Windows Azure Management Portal as documented here: How to Setup Multiple Administrator Accounts.

These Co-administrators will now have access to the AppFabric section of the portal.

For any questions or feedback regarding the Management Portal please visit the Managing Services on the Windows Azure Platform forum.

Access Control

The following updates have been made to all ACS 2.0 namespaces.

Rules now support up to two input claims

The ACS 2.0 rules engine now supports a new type of rule that allows up to two input claims to be configured, instead of only one input claim. Rules with two input claims can be used to reduce the overall number of rules required to perform complex user authorization functions. For more information on rules with two input claims, see http://msdn.microsoft.com/en-us/library/gg185923.aspx.

Encoding is now UTF-8 for all OAuth 2.0 responses

In the initial release of ACS 2.0, the character encoding set for all HTTP responses from the OAuth 2.0 endpoint was US-ASCII. In the July 2011 release, the character encoding of HTTP responses is now set to UTF-8 to support extended character sets.

Quotas Removed

The previous quotas on configuration data have been removed in this release. This includes removal of all limitations on the number of identity providers, relying party applications, rule groups, rules, service identities, claim types, delegation records, issuers, keys, and addresses that can be created in a given ACS namespace.

Please use the following resources to learn more about this release:

For any questions or feedback regarding the Access Control service please visit the Security for the Windows Azure Platform forum.

If you have not signed up for Windows Azure AppFabric and would like to start using these new capabilities, be sure to take advantage of our free trial offer. Just click on the image below and get started today!

The AppFabric Team

Tutorial: Creating a custom external service in Azure AppFabric June CTP

Miguel Susffalich — Wed, 20 Jul 2011 23:41:04 GMT

In this tutorial, Alan Smith (MVP) uses the Azure AppFabric June CTP to create a basic custom external service to call the BingMaps Geocode service. This is a great starting point on how to write a basic custom external service fully integrated with the Azure AppFabric designer June CTP. Look for the webcast version coming soon on AppFabric.tv and follow up posts to add more capabilities to this custom external service, such as rich domain-specific monitoring metrics and tracing integration.

Thanks to Alan for his active contribution to the AppFabric community!

Using MSBuild to deploy your AppFabric Application

Justin Beckwith — Wed, 20 Jul 2011 20:55:00 GMT

As the hosting of applications moves from our local staging environments to the cloud, one of the areas that needs to improve is the ability to include deployment in our automated build processes. Using the June CTP AppFabric bits, Visual Studio does an excellent job of enabling developers to design, build, and deploy AppFabric applications. However, the current tools do not provide a way to integrate these tools into a standard, repeatable build process. The goal of this post is to outline the steps necessary to integrate automated AppFabric deployment into your build process, and show off some of the REST API features we’ve built into the Application Manager.

Before we get started, let’s run through a list of tools I’m using for this sample:

Visual Studio 2010 with the .NET Framework 4.0
The Windows Azure AppFabric SDK CTP – June Update
- AppFabric Samples
- AppFabric SDK
- AppFabric Tools for Visual Studio
Sample code on GitHub

Since the goal of this post is to use MSBuild to deploy our AppFabric Application, you’re going to need to register for an account over at our labs site. To request access to the CTP follow these steps:

Sign in to the AppFabric Management Portal at http://portal.appfabriclabs.com/.
Choose the entry titled “Applications” under the “AppFabric” node on the left side of the screen.
Click on the “Request Namespace” button on the toolbar on the top of the screen.
You will be asked to answer a few questions before you can request the namespace.
Your request will be in a “pending” state until it gets approved and you can start using the CTP capabilities.

Using the REST API

The AppFabric Application Manager provides a useful RESTful API to automate most tasks available in the Application Manager. We are going to take advantage of the application lifecycle methods (start, stop, deploy, etc) to write our custom task. To help you get started with the API, we’ve put together a ResourceAccessor.cs class to abstract some of the calls we’re making using the AtomPub protocol. For example, to get the details for an application you would instantiate the class using your namespace and management key:

// create a new instance of the Application Manager REST API wrapper

ResourceAccessor appManagerAPI = new ResourceAccessor(this.Namespace, this.ManagementKey);

// get some details about our application

ApplicationResource ar = appManagerAPI.GetApplication("myApplicationName");

This sample assumes you have an existing account on http://portal.appfabriclabs.com, and that you have already created a namespace. To get the management key for your namespace, click on the ‘View’ button located in the properties panel on the right side of the portal, then copy the key to your clipboard:

For our purposes, we’re mostly interested in automating the shutdown, un-deployment, import, deployment, then re-starting of the application. For example, to start the application we can issue a SendCommand call:

// attempt to start the application

Log.LogMessage(MessageImportance.Normal, "Starting the application ...");

appManagerAPI.SendCommand(this.ApplicationName, LifecycleCommand.Start);

If you’re interested in automating other application commands, the samples we’ve included should give you a head start.

Building the MSBuild Task

Now that we’re comfortable with the REST API, it’s time to start working on our custom MSBuild Task. This is relatively easy, and very well documented:

http://msdn.microsoft.com/en-us/library/t9883dzc.aspx

We need to create a new .NET Class Library project for our custom task. For this sample, I chose to implement a class that inherits from ‘Task’, and overrides the Execute method:

public class AppManagerDeploy : Task

{

    public override bool Execute()

    {    

        ...

    }

}

To deploy our custom package, the Execute method uses the REST API Wrapper to stop the running application, un-deploy the application, and then upload the new package:

 
/// <summary>

/// This is the main function that executes when creating a custom MSBuild Task. This 

/// function is responsible for uploading the given *.afpkg file to the Application 

/// Manager API.

/// </summary>

/// <returns></returns>

public override bool Execute()

{    

    // output debugging information to the MSBuild console

    ...

    // create a new instance of the Application Manager API

ResourceAccessor appManagerAPI = new ResourceAccessor(this.Namespace, this.ManagementKey);

    // check to see if the requested application is in a valid state for the upload 

// operation (stopped, undeployed)

    ...

     // upload the given *.afpkg file to the Application Manager deployment service

    appManagerAPI.UploadPackage(this.ApplicationName, this.PackagePath);

    // attempt to deploy the application

    Log.LogMessage(MessageImportance.Normal, "Deploying the application ...");

    crResult = appManagerAPI.SendCommand(this.ApplicationName, LifecycleCommand.Deploy);

    // attempt to start the application

    Log.LogMessage(MessageImportance.Normal, "Starting the application ...");

    crResult = appManagerAPI.SendCommand(this.ApplicationName, LifecycleCommand.Start);

    Log.LogMessage(MessageImportance.High, "Deployment Complete!");

    return true;

}

For the full source, please visit our GitHub.

Attaching the MSBuild Task to the Azure AppFabric Application

After the custom MSBuild task is complete, we now attach the task to our current application *.csproj file. I chose to use the Stock Ticker Application available in the June CTP Samples, and the modified version of this solution is available with the source code for this post. To modify the *.csproj file, you need to:

Open your AppFabric Application solution file (Ex. StockTickerApp.sln)
Right click on the AppFabric Project containing App.cs, and unload the project
Right click on the unloaded project and edit the *.csproj file
Scroll to the bottom of the *.csproj file, and add this target just above the </project> tag:

<UsingTask TaskName="AppManagerDeploy" 

    AssemblyFile="C:\>Path to Samples>\AFDeployTask\bin\Debug\Microsoft.Samples.AppFabric.MSBuildTask.dll" 

/>

<Target Name="DeployToAppFabric" AfterTargets="Build" Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">

<Message Text="Deploying Project to AppFabric Portal" Importance="high" />        

    <AppManagerDeploy

        Namespace="justbe"

        ManagementKey="jmjMPi0GvG97U/eISgswcdt/K3zlrr+MyPS8+DQhlqk="

        ApplicationName="stockticker"                

        PackagePath="$(MSBuildProjectDirectory)\bin\release\publish\StockTickerApp.afpkg"

    />

</Target>

If you choose to implement this task as part of your build and deployment strategy, you could register the Microsoft.Samples.AppFabric.MSBuildTask.dll assembly in the GAC to avoid referencing the path to the *.dll each time. The UsingTask command attaches the new assembly to the build, and ensures we can use the AppManagerDeploy task we just created. The AppManagerDeploy task accepts the following fields:

Namespace – The application namespace generated in the Azure portal
ManagementKey – The namespace Management key accessible in the Azure portal
ApplicationName – the name of the application in the AppFabric Application Manager
PackagePath – the relative path to the *.afpkg file generated during the build

This target is configured to only execute when using the Release mode configuration. We now have two ways of executing our build with a deploy command: by building in Visual Studio using release mode, or by issuing an MSBuild command at the command prompt. Since the point of the exercise is to create an MSBuild task for automated builds, let’s step through executing our build at the Visual Studio command prompt. First navigate to the path where your application *.sln file is stored. Then execute the command to build your project:

Keep in mind; this will likely take some time to execute. However, once the deployment is complete you should get a success message in the console:

After allowing the deployment task to execute, check out the Admin Log in the Application Manager to review all of the commands that were executed:

Other Examples

For other examples of using the Windows Azure AppFabric Application Manager REST API, be sure to check out our PowerShell sample in the June CTP. For other great resources on using Azure AppFabric, please visit our blog at http://blogs.msdn.com/b/appfabric/.

Configuring, deploying, and monitoring applications using AppFabric Application Manager

adamab — Fri, 15 Jul 2011 21:19:00 GMT

In the previous blog post on developing AppFabric Applications, we showed you how to create a simple AppFabric application. This app was an ASP.NET web site that used a SQL Database. In this blog post, we’ll use the AppFabric Application Manager to configure, deploy, and monitor that application. Here is a breakdown of what we will cover:

The AppFabric Player application has been imported (where the last blog post left off). Package can be downloaded here (AppFabricPlayer.afpkg).
Update the connection string to point to a SQL Azure database
Initialize the SQL Azure Database with application data
Deploy and start the application
View aggregate ASP.NET monitoring metrics at both web app and web page granularities

Before we can do those things, we’ll sign into the AppFabric LABS Portal at https://portal.appfabriclabs.com using our Live Id. Since this is a limited CTP, only approved users will have access to the service, but all users can try the SDK and VS Tools on your local machines. To request access to the AppFabric June CTP, follow the instructions in this blog post.

After signing in with an approved account, we click on AppFabric Services in the bottom left corner and then select Applications from the tree view.

Now we can start with our first task, updating the connection string to the SQL database that is used by the AppFabric Player app. Users of the AppFabric June CTP are provided with a SQL Azure database at no charge. We will use this database. To get access to our SQL Azure connection string, we’ll click on the database in the main panel and then click View under Connection String. The resulting dialog lets us copy the connection string to the clipboard.

Now we’re ready to go to the Application Manager. We select our namespace from the main content area and then click Application Manager on the ribbon.

We can also reach the Application Manager directly by using a URL in this format: https://yournamespacehere.appmanager.appfabriclabs.com.

We click on AppFabricPlayer to manage that app.

Then we’ll click on Referenced Services in the Summary area.

Then we’ll click on the VideoDb link to configure the database. Now we will update the connection string using the value we copied earlier. Note that the DatabaseName and the ServerConnectionString fields are separate so you will have to remove the database name from the value before pasting it in.

Before Data Source=myservername;~~Initial Catalog=mydatabase~~;User ID=myuserid;Password=mypassword

After Data Source=myservername;User ID=myuserid;Password=mypassword

We update both fields and select Save.

Next we will create and populate the SQL table that this app expects in the database. We’ll go to https://manage-sn1.sql.azure.com/ to do that. We login with the same credentials that appear in our connection string.

We’ll click on New Query from the ribbon and paste in the SQL script below. We execute the script and the database is initialized.

CREATE TABLE [dbo].[AppFabricVideos] (
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Title] [nvarchar](256) NOT NULL,
    [Description] [nvarchar](2048) NOT NULL,
    [Uri] [nvarchar](1024) NOT NULL,
    CONSTRAINT [PK_AppFabricVideos] PRIMARY KEY ([Id] ASC)
)

INSERT INTO [dbo].[AppFabricVideos]
           ([Title]
           ,[Description]
           ,[Uri])
     VALUES
           ('ServiceBus HTTP / REST API'
           , 'Recently the ServiceBus team released some great new support for Queues and Topics, allowing you to access queues via a client library as well as HTTP. In this episode, I am joined by Will Perry, a tester on the ServiceBus team, who shows us how you can use the HTTP API with ServiceBus queues.Ron…'
           , 'http://media.ch9.ms/ch9/8f5a/e7dea0d6-f591-412b-8e75-9f0c012b8f5a/AppFabricServiceBusHTTP_low_ch9.mp4')

INSERT INTO [dbo].[AppFabricVideos]
([Title]
,[Description]
,[Uri])
    VALUES
    ('Announcing the Windows Azure AppFabric June CTP'
    , 'Today we are exciting to announce the release of the Windows Azure AppFabric June CTP which includes capabilities that make it easy for developers to build, deploy, manage and monitor multi-tier applications across web, business logic and database tiers as a single logical entity on the Windows Azure Platform.'
    , 'http://media.ch9.ms/ch9/9a4b/43794581-3dba-410a-bb0c-9f03017b9a4b/AppFabricTVCTPLaunch_low_ch9.mp4')

Now that the database is ready we can deploy and start our application. We go back to the Application Manager and navigate to the AppFabric Player’s Application Page. From this page, we’ll click on Deploy Application and then accept the dialog.

Once the application state changes to Started we visit the site. To do this, we’ll click on Endpoints in the Summary area and then select the app’s Published Address link.

Now that the app is running we are able to monitor important activity. To simulate activity we wrote a load test that hits the web page once every second or so. If we go back to the application page and click on Monitoring in the Summary area, we’ll see some interesting metrics.

These metrics are aggregated at the application level, but if we drill down into the ASP.NET Web Application we can see more granular metrics. We click on Containers in the Summary area and then select Web1, which represents our one and only service group. We then click on PlayerWeb, which represents our ASP.NET Web Application. We then click on Monitoring from the Summary area.

Our breadcrumb bar now indicates that we have navigated into the PlayerWeb ASP.NET Web Application. From this view, we can see exactly how many times each file in the web application has been requested as well as the average request latency for each.

And just like we saw at the application page, we can expand each row to display a chart to see how each value has changed over time.

That’s it. In this post we showed how to configure, deploy, and monitor and AppFabric application using Application Manager. In future posts, we’ll cover troubleshooting, extensibility, and more. Stay tuned.

Developing a Windows Azure AppFabric Application

Vikram Desai - Microsoft — Fri, 15 Jul 2011 21:10:00 GMT

In this post, we will go through developing an AppFabric application that contains a web frontend and a database. Before we can develop an application, we’ll sign into the AppFabric LABS Portal at https://portal.appfabriclabs.com using our Live Id. Since this is a limited CTP, only approved users will have access to the service, but all users can try the SDK and VS Tools on their local machines. To request access to the AppFabric June CTP, follow the instructions in this blog post.
After we have installed the SDK, we will launch Visual studio and create a new AppFabric Application

The application definition view (App.cs) is the default view that is opened when a new project is created. This view allows us to add and compose between various services that constitute an application. We can add the various services that make up the application here. The application consists of a frontend web tier to play videos and accesses backend database to get the list of videos. To add the web project we will open the App.cs view and click on Add New Service -> ASP.NET and name it PlayerWeb. We have also attached the completed solution for this app along with this post.

Similarly we will add a new service for database Add New Service -> SQL Azure with name: VideoDb
By default when the database is added it points to a local database in SQL Express. For developing the application locally we will create and use a database in SQL Express. When the application is deployed to the cloud the database will point to a SQL Azure database. A follow-up post covering Application Manager in detail will show how to change the database to point a SQL Azure database instead of a local database.

When we add the database, the default database name populated in properties panel is “Database”. This will need to be changed to the database used by the AppFabricPlayer application. For this app we will create a database called AppFabricPlayer in SQL Express and add a table to store the videos to be played. The table in the database is created and populated using the following script

For the app to refer to the correct database we will change the Database Name property for VideoDb definition to the database we created in SQL Express - AppFabricPlayer.

Now that we have added the ASP.NET and database services to the application we can compose from the web to the data tier. AppFabric Application allows us to specify relationships between various services within the app. The relationships allow us to define dependencies between the services within the application. The resulting composition model is used at management time to deploy, configure, control, monitor, troubleshoot and scale the application.
To compose between the ASP.NET and the database, in the application definition (App.cs) view, we will add a service reference between PlayerWeb and VideoDB. We will go to the App.CS and click on App.CS ->PlayerWeb->Add Service Reference followed by selecting VideoDb endpoint

We will rename the reference name from Import1 to VideoDbImport

The application is now completed structurally. We can view the application diagram by right clicking on App.cs in Solution Explorer and selecting view Diagram

Now we will add the logic for the application. We will create the model class called Video.cs in the web project and add the following code in the class.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Data.SqlClient;

namespace PlayerWeb
{
    public class Video
    {
        public string Title { get; set; }
        public string Description { get; set; }
        public string VideoSourceURI { get; set; }
        public int Id { get; set; }

        public Video()
        {
        }

        public IEnumerable<Video> GetVideos()
        {
            List<Video> videos = new List<Video>();

            try
            {
                using (SqlConnection connection = ServiceReferences.CreateVideoDbImport())
                {
                    connection.Open();
                    using (SqlCommand command = connection.CreateCommand())
                    {
                        command.CommandText = "select * from AppFabricVideos";
                        using (SqlDataReader reader = command.ExecuteReader())
                        {
                            while (reader.Read())
                            {
                                videos.Add(new Video()
                                {
                                    Id = (int)reader["Id"],
                                    Title = reader["Title"] as string,
                                    Description = reader["Description"] as string,
                                    VideoSourceURI = reader["Uri"] as string
                                });
                            }
                        }
                    }

                }
            }
            catch (SqlException ex)
            {
                System.Diagnostics.Trace.TraceError("Error getting videos from database: {0}", ex);
            }

            return videos;
        }
    }
}

One thing that is different here is the code to get SqlConnection:
SqlConnection connection = ServiceReferences.CreateVideoDbImport();
Previously, when we added a service reference between ASP.NET and database, a helper method is created to access the referenced database. In our code this allows us to easily resolve the SqlConnection. Under the covers the helper method has code that reads the database name and connection string from application definition. Later when the application is configured in management portal we will see how this information can be changed by the application administrator.
To complete the application we will change the code in default.aspx, default.aspx.cs and sites.css (The full solution along with these files can be downloaded from here (download AppFabricPlayer.zip)).
We will run the application in our local environment in Visual Studio using Debug->Start Without Debugging (Ctrl-F5). The output window in Visual Studio shows when the application is ready to be tested in the local emulator.

The published address shown above is the address of the web app. Also, we get a pointer to the location of the application log files. If the ASP.NET component within the application was emitting traces, the traces will be in a file in this location. Another note if we want to debug this application in the debugger we can attach the debugger to w3wp.exe process and step through the code.
Now that we have seen the application running locally we are ready to publish it for running in the cloud. To deploy to Azure through AppFabric Application Manager, we can start by publishing the application from within Visual Studio. This can be done by clicking on the AppFabricPlayer in Solution Explorer and selecting Publish. We will need to enter the credentials required to publish to AppFabric Application Manager namespace including the management key that allows us to access AppFabric Application Manager namespace. The management key required to publish an application can be obtained from https://portal.appfabricabs.com, by clicking on AppFabric Services and selecting Applications. From the properties on the right hand side properties grid, we can get the management key, as shown from the properties pane below.

Alternatively, the application package can be imported through the AppFabric Application Manager Portal. This can be done by navigating to, and logging in to https://yournamespacehere.appmanager.appfabriclabs.com. Here, we can create a New Application (under common tasks) and select the package to import.

We showed how to develop a simple AppFabric Application and publish it to Azure; in a follow-up blog post, we will show how we will manage this application using AppFabric Application Manager.

The AppFabricPlayer solution can be downloaded from here (AppFabricPlayer.zip)

Lead Hosts versus SQL Server for Windows Server AppFabric Caching

AppFabric Team — Wed, 06 Jul 2011 23:00:00 GMT

Note: This is only relevant the on-premises version of the Caching service which is part of Windows Server AppFabric

Introduction

The following would go over the concepts of lead host and offloading in both network share configuration (aka XML configuration) and SQL configuration for the AppFabric Caching technology. In addition, it will also explain when to use one configuration over the other.

AppFabric Caching is built on top of a stateful partitioned cluster. It ensures that the cluster is consistent with minimal down time at all times. To maintain consistency the cluster needs a master which would create the cluster, maintain its uptime and ensure its validity. Hence the cluster would go offline along with its master.

Having a single master introduces a single point of failure, so we have a set of nodes called lead hosts acting as the master. Consequently, when a quorum of lead hosts goes down the cluster goes down. For instance, the quorum for a cluster of 5 cache hosts would be 3 lead hosts, quorum for 6 is 4 and so on. This is the network share configuration.

For small clusters (having 2 cache hosts), lead hosts master configuration would not work well since that means one host going down would take the cluster down (if both of them are lead hosts). For those cases, there is another master configuration where we offload the master capabilities and responsibilities to an external custom store. SQL Server custom store is shipped by default. Here SQL Server becomes the master and hence the single point of failure. This is called ‘master offloading’/’lead hosts offloading’/ or just ’offloading’ and the corresponding configuration is SQL Server configuration.

Which configuration to use?

Since lead host configuration avoids a single point of failure, we recommend this to be the default choice for customers with non-trivial deployments.

If a customer has a deployment consisting of two cache hosts or wishes to avoid managing seed nodes then offloading can be used provided he can ensure uptime of SQL for the entire cluster lifetime. The uptime requirement on SQL was not emphasized in our previous guidance and this doc is meant to clarify the same.

Managing a SQL offloaded cluster

Though offloading avoids managing lead hosts, it comes at a cost of maintaining a very high consistent uptime of SQL server to keep the cluster alive. Various techniques could be used like mirroring/failover for this purpose.

Relevant links

Database mirroring: High safety mode is required in this case.
http://technet.microsoft.com/en-us/library/ms188712.aspx
http://blogs.msdn.com/b/appfabriccat/archive/2010/11/01/disaster-recovery-for-appfabric-caching-v1-0-sql-mirroring.aspx
Failover clustering
http://msdn.microsoft.com/en-us/library/ms189134.aspx

FAQs on Offloading

Q. SQL Server going down would eventually bring the cluster down. But how soon would that be? Is there any SQL Server downtime cluster can survive?

A. If the SQL Server downtime is strictly less than one minute, the cluster would be able to survive it.

Q. Can the limit of 1 minute be increased? Or in other words, can the cluster be made to survive larger SQL Server downtimes?

A. It is possible to do that, but we do not recommend that since it would mean the violation of the original requirement of an external master – consistent uptime. In this case the network share configuration should be used.

Q. What happens during the time SQL Server is down?

A. Following are the effects during SQL Server downtime:

Management operations from administration tool would not be available.
If a host goes down during SQL unavailability it might result in a cascading effect and thus the whole cluster can go offline. The reason is when a host goes down; its neighbors would not be able to heal the cluster properly as they would not be able to talk with neither the node which went down nor the master.

Managing a lead host based cluster

In this mode, the deployment has to select a set of lead hosts so that a quorum of them is always up. This can be done as a one-time step before you bring up the cluster.

Considerations in choosing lead hosts

We recommend that you use at least 3 lead hosts. You may choose more but empirical observations have shown that you’d not require more than 7. Also have an odd number of them as having an even number (x) is not better than the previous odd number (x-1).

Steps to configure a lead host

Open the PowerShell based administration tool.
Use the following command to export the cluster configuration:
Export-CacheClusterConfig -File <filename.xml>
Open filename.xml and change the attribute ‘leadHost’ (under <host> tag in <hosts>) to true to make a particular host as a lead host.
Repeat the above step until you have sufficient number of lead hosts.
Save the file.
Import the file using the following command (the cluster should be down at this point):
Import-CacheClusterConfig -File <filename.xml>

You can also refer to http://msdn.microsoft.com/en-us/library/ee790910.aspx

FAQs on Onloading

Q. How many lead hosts should I use?

A. As stated above, you should at least have three lead hosts.

Q. Can I add a lead host dynamically when the cluster is running?

A. This functionality is not available in RTM 1.0.

Q. What is the connection between lead hosts and network share?

A. Lead host configuration is the default and the network share is used to store cluster metadata. However when SQL configuration is used, in RTM 1.0, in addition to store cluster metadata, it is automatically picked as the single master.

Q. I already have an offloading configured cluster, what should I do now to go to a lead host based one?

A. You need to bring down the cluster and reconfigure the administration tool and all the cache hosts to use network share configuration. You can do it via UI or configuration commands – New-CacheCluster, Register-CacheHost. As pointed above you need to configure individual lead hosts also.

[Update]

Q. Is it possible to use lead host management with the cache configuration in a SQL database instead of a network share?

A. No, it is not possible to do this in v1.0.

Q. What happens if the network share goes down?

A. In the network share configuration, it acts as a passive entity (unlike SQL Server). Hence the network share going down would not result in the cluster going down. However there are some limitations during its downtime:

Administration tool operations won’t work.
Named cache creation/deletion would not work.
Node installation/uninstallation would not work.
If an existing node reboots, it won’t be able to join the cluster.

Q. Does the network share have to be writable by the cache hosts?

A. No, cache hosts only read from the network share.

Amit Kumar Yadav

Kalyan Chakravarthy Sonnathi

AppFabric Caching Team

Nice post covering Windows Azure AppFabric Applications

Itai Raz - Microsoft — Wed, 06 Jul 2011 17:00:00 GMT

Neil Mackenzie, a Windows Azure MVP, has written a great blog post regarding Windows Azure AppFabric Applications which were introduced as part the Windows Azure AppFabric June CTP.

Neil summed up the concept very nicely in his post:

“I am a great advocate of the PaaS model of cloud computing. I believe that AppFabric Applications represents the future of PaaS for use cases involving the composition of services that can benefit from the cost savings of running in a multi-tenanted environment. AppFabric Applications reduces the need to understand the service hosting environment allowing the focus to remain on the services. That is what PaaS is all about.”

If you would also like to start using the June CTP here is what you need to do:

1. To request access to the Application Manager follow these steps:

Sign in to the AppFabric Management Portal at http://portal.appfabriclabs.com/.
Choose the entry titled “Applications” under the “AppFabric” node on the left side of the screen.
Click on the “Request Namespace” button on the toolbar on the top of the screen.
You will be asked to answer a few questions before you can request the namespace.
Your request will be in a “pending” state until it gets approved and you can start using the Application Manager capabilities.

2. In order to build applications you will need to install the Windows Azure AppFabric CTP SDK and the Windows Azure AppFabric Tools for Visual Studio. Even if you don’t have access to the Application Manager you can still install the tools and SDK to build and run applications locally in your development environment.

Please don’t forget to visit the Windows Azure AppFabric CTP Forum to ask questions and provide us with your feedback.

Itai Raz, Product Manager

Client Side Tracing for Windows Azure AppFabric Caching

AppFabric Team — Wed, 29 Jun 2011 17:00:00 GMT

In this post, I will describe how to enable Client-side traces for AppFabric Caching Service. I will also touch upon some basic problems you might face while trying out the same.

To configure the cache client to generate System.Diagnostic.Traces pertaining to the AppFabric cache, please follow the below steps:

Configuration File Option

In your app.config/web.config you need to add <tracing sinkType="DiagnosticSink" traceLevel="Verbose" />, to the appropriate location as per the cases below:

a. DataCacheClients Section

If you have a ‘dataCacheClients’ section in your app.config/web.config file under <configuration> section, then add the tracing section as below:

</configSections>

<hosts>

</hosts>

</messageSecurity>

</securityProperties>

</dataCacheClient>

</dataCacheClients>

...

</configuration>

Note: Tracing section should be a direct child of the <dataCacheClients> section and should not be added under <dataCacheClient> section(s), if <dataCacheClients> section is present.

b. DataCacheClient Section

If you do not have a <dataCacheClients> section, and the app.config/web.config has only a <dataCacheClient> section, then add the Tracing section as below:

</configSections>

<hosts>

</hosts>

</messageSecurity>

</securityProperties>

</dataCacheClient>

...

</configuration>

Programmatic Option

You may also choose to set the System.Diagnostic.Trace for cache client programmatically, by calling the below method at any point:

//Argument 1 specifies that a System.Diagnostic.Trace will be used, and

//Argument 2 specifies the trace level filter.

DataCacheClientLogManager.SetSink(DataCacheTraceSink.DiagnosticSink, System.Diagnostics.TraceLevel.Verbose);

You may also change the level at which the trace logs are filtered, programmatically by calling the below method at any stage (say, 5 minutes after your service has started and stabilized you may want to set the cache client trace level to Warning instead of Verbose):

DataCacheClientLogManager.ChangeLogLevel(System.Diagnostics.TraceLevel.Warning);

Troubleshooting

If you are using Azure SDK 1.3 or above, and trying to get cache client side traces within a Web Role using the above mechanism on DevelopmentFabric environment, you will not be able to see the Cache client traces on the Development Fabric Emulator (or DevFabric UI)

- Reasoning/Explanation for the given behavior

With SDK 1.3, the IIS (Role Runtime) runs in a separate process as compared to web role (for ASP.Net session state provider scenario) and all the logs related to Web Role can be seen in the DevFabric UI, however, the cache client side traces go as part of IIS i.e. the Role Runtime. The DevFabric Emulator attaches its own listener “DevelopmentFabricTraceListener” by default and its UI emits logs only heard by this listener. Since IIS is in a different process, this listener is not present and logs cannot be seen on the DevFabric UI.

- Resolution

Note: The resolution below is only to see logs for DevFabric scenario; otherwise the logs would go to xStore (Azure Storage Account) in a perfectly fine manner. For your project, add the below in web.config under <system.diagnostics>\<trace>\<listeners> section:

- You may add this only for your Web.Debug.config, so that when you actually deploy to an Azure environment, this section does not get added as you will use Web.Release.config file.

- You also need *not* add a reference to the DLL “Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime.dll” as the machine on which you are deploying it on Development Fabric should have this DLL present in GAC (Search for this DLL under %windir%\assembly).

- Deploy the sample on DevFabric, and you should now be able to see the Cache traces on the Development Fabric UI.

For any questions or feedback regarding the Caching service please visit the Windows Azure Storage, CDN and Caching forum.

Sharad Agrawal

On behalf of the AppFabric Team

See what our customers are already doing with the Windows Azure AppFabric June CTP

Itai Raz - Microsoft — Fri, 24 Jun 2011 18:08:00 GMT

The Windows Azure June CTP has only been released a few days ago, and we already have great samples built by our customers that show how to use the CTP capabilities.

Alan Smith has created two webcasts on CloudCasts that show how easy it is to develop AppFabric applications using the June CTP capabilities:

Introduction to AppFabric Applications – shows how to use various capabilities released in the June CTP.
Using AppFabric Service Bus Queues – shows how easy it is to build an application that uses the capabilities in the June CTP along with Service Bus Queues in order to build an application that bridges between a web site running in the cloud, and an application running on-premises.

Watch these videos to learn more about these capabilities and how to use them. We hope you enjoy them as we did!

If you would also like to start using the June CTP here is what you need to do:

1. To request access to the Application Manager follow these steps:

Sign in to the AppFabric Management Portal at http://portal.appfabriclabs.com/.
Choose the entry titled “Applications” under the “AppFabric” node on the left side of the screen.
Click on the “Request Namespace” button on the toolbar on the top of the screen.
You will be asked to answer a few questions before you can request the namespace.
Your request will be in a “pending” state until it gets approved and you can start using the Application Manager capabilities.

Please don’t forget to visit the Windows Azure AppFabric CTP Forum to ask questions and provide us with your feedback.

Itai Raz, Product Manager

Windows Azure AppFabric will be available on the Official Windows Azure Platform Team Blog

AppFabric Team — Fri, 24 Jun 2011 16:00:00 GMT

We are combining all Windows Azure platform related content into one place: the Windows Azure Platform Team Blog at www.WindowsAzureBlog.com. This will be the new destination for all product releases, resources, tools and news around the Windows Azure platform. You can bookmark this new blog location and sign up for the Windows Azure AppFabric RSS feed there.

We will continue to post about Windows Azure AppFabric on this blog, as well as post about Windows Server AppFabric, WCF, WF, development, deployment, and management.

Why are we adding the Windows Azure AppFabric content to the Windows Azure Platform Team Blog? The Windows Azure Platform Team Blog will be the one-stop-shop blog for all components of Windows Azure platform, including Windows Azure, SQL Azure, Windows Azure AppFabric and DataMarket. If you are interested in the Windows Azure platform you will no longer have to visit multiple blog locations to be on top of all the late-breaking news and information. The Windows Azure Platform Team Blog will continue to cover the wide range of topics we have addressed on this blog, from product announcements to technical “how-to” posts. You can continue to expect the same quality content you have been receiving, on this new integrated blog. If you’re primarily interested in posts about Windows Azure AppFabric, you can subscribe to a dedicated RSS feed in the new blog or continue following it on this blog. Alternatively, now you will also have the option to get all the Windows Azure platform information in one integrated RSS feed.

To continue to provide a single view of the Windows Azure platform, expect to see a similar evolution across Facebook, Twitter, and YouTube over the coming weeks. We’ll be sure to notify you when that happens. In the meantime, we hope these changes will make your life a little easier by making the Windows Azure Platform Team Blog your destination for all the latest news and information about the Windows Azure platform.

Windows Azure AppFabric – Service Bus Access Control Federation and Rule Migration

AppFabric Team — Thu, 23 Jun 2011 22:00:00 GMT

In the Windows Azure AppFabric May 2011 CTP, we released enhancements to Service Bus including the new message-oriented middleware features around Queues and Topics. More details regarding these features can be found here: Introducing the Windows Azure AppFabric Service Bus May 2011 CTP. These enhancements will go live with an update to the commercially available service in a few months.

Currently we have two versions of the Access Control service in our production environment: the January 2010 version and the April 2011 version. More details regarding this can be found here: Windows Azure AppFabric April release now available featuring a new version of the Access Control service!.

Until the production Service Bus is updated it continues to use the January 2010 version of the Access Control service. But once Service Bus is updated it will also be able to use the new April 2011 version of the Access Control service. Once the Service Bus update goes live we strongly recommend to customers to update their Service Bus solutions to use the new version of the Access Control service for two reasons:

Service Bus will cease to use the older version of the Access Control service at some point in the future. In compliance with our lifecycle support policies for Windows Azure, we will provide you with 12 month notice before this event.
The April 2011 version of Access Control has great benefits as noted in the blog post referenced in the above.

Following are explanations on the current state, what will change once Service Bus gets updated, and how you can prepare.

Current state in the production environment

In the Windows Azure AppFabric Management Portal, the two versions of Access Control are labeled ACSV1 for the January 2010 release and ACSV2 for the April 2011 release.

Today when you create a new Service Bus namespace, a matching ACSV1 namespace is automatically created with the namespace suffix “–sb”. This ACSV1 namespace is used by Service Bus.

The two versions of the Access Control service support the same protocol and authorization token format that is expected by Service Bus today (OAuth WRAP SWT), and are fully compatible for all runtime operations. However, ACSV2 supports a new, richer management service protocol based on OData. While the two services are runtime-compatible, they are not compatible for code performing automated setup of access control rules and service identities via the management service.

Following the Service Bus update

For backwards-compatibility with existing applications, Service Bus namespaces that exist in the production environment at the time of the update will not be automatically switched over to ACSV2, and will continue to use ACSV1. You will need to migrate these namespaces from ACSV1 to ACSV2 on your own, coordinated with updates to your code that calls the management service.

As we update the service in a few months, we will provide tooling and step-by-step guidance for how to perform the migration from ACSV1 to ACSV2.

While we will provide detailed guidance as we release the update, the migration process will generally involve the following test-then-migrate sequence of steps:

First, you will create a brand-new, temporary Service Bus namespace that will automatically come paired with an ACSV2 namespace. This namespace will be used for end to end testing of your application with ACSV2, including your updated code to call the management service.
Using a to-be-provided command line tool, you will copy the state of your production ACSV1 namespace into the temporary ACSV2 namespace. Your production Service Bus namespace and corresponding ACSV1 namespace will remain untouched during this process. You can now test your application and updated code against the temporary Service Bus and ACSV2 namespace to ensure everything works as expected.
After you have verified that your application works as expected, you will use the to-be-provided command line tool to change the DNS name of the temporary ACSV2 namespace to be the name of the ACSV1 namespace associated with your production Service Bus – effectively swapping the V2 namespace into the place of the existing V1 namespace. This completes the migration.

Running applications should not experience any service disruption resulting from this switch.

The version differences and migration will mostly affect applications that automatically provision rules in ACSV1 using the management service. Since the management service differs between ACSV1 and ACSV2, the guidance will suggest a process that can be outlined as follows:

As you prepare for the switchover, you should have a mode in your application, or a procedure in your operations process, that allows you to temporarily suspend automated creation of rules. This may be a simple notice to operations staff or may require some work in your application.
Immediately before you copy rules to the temporary namespace for the final time before making the DNS name change, you should engage this suspension mode so that no new rules are created in the ACSV1 namespace that end up being orphaned after the data migration.
After you have switched to ACSV2, you can resume automated creation of rules by having your code target the new ACSV2 management service.
We suggest that you have both, the ACSV1 and the ACSV2 client code existing in your application side-by-side and that you switch between the code paths using a simple check against an HTTP URL. If a simple GET request against the ACSV2 management endpoint https://tenant.accesscontol.windows.net/v2/mgmt/service yields an HTTP status code 404, the application runs against ACSV1, otherwise it already runs against ACSV2.

How to prepare

Our LABS environment at http://portal.appfabriclabs.com already includes the enhancements to Service Bus, as well as the new version of Access Control. Hence, you can use this environment, free of charge, to start planning your migration and test it.

In the LABS environment already today, when customers create new Service Bus namespaces the system will generate a new Access Control namespace with the “-sb” suffix, but that namespace is created in ACSV2. This will be the production experience when we release the update to Service Bus in a few months.

You can immediately start developing this new management code path creating rules against ACSV2 against the versions of Service Bus and Access Control that are available in the May 2011 CTP environment at http://portal.appfabriclabs.com.

As always, if you have any questions or feedback feel free to visit the Connectivity for the Windows Azure Platform forum.

The AppFabric Team.

Announcing the Windows Azure AppFabric June CTP!

AppFabric Team — Tue, 21 Jun 2011 03:31:00 GMT

Today we are excited to announce the release of the Windows Azure AppFabric June CTP which includes capabilities that make it easy for developers to build, deploy, manage and monitor multi-tier applications across web, business logic and database tiers as a single logical entity on the Windows Azure Platform.

This CTP release consists:

AppFabric Developer Tools - Enhancements to Visual Studio that enable to visually design and build end-to-end applications on the Windows Azure platform.
AppFabric Application Manager – Powerful, yet easy way to host and manage n-tier applications that span web, middle and data-tier through the entire application lifecycle including deployment, configuration, monitoring and troubleshooting. The Application Manager includes a comprehensive application management portal that is powered by a REST API for monitoring the health of your n-tier application and performing management operations on the running applications.
Composition Model - A set of .NET Framework extensions for composing applications on the Windows Azure platform. This builds on the familiar Azure Service Model concepts and adds new capabilities for describing and integrating the components of an application. The AppFabric Developer Tools leverage the composition model to create an application manifest that is used by the AppFabric Application Manager at deployment time to understand the application structure and metadata.
Support for running Custom Code, WCF, WF - Formal support for executing Windows Workflow Foundation (WF) on Windows Azure and the composition of Windows Communication Foundation (WCF) and WF services, as well as custom code, into a composite application. In addition, it provides enhanced development, deployment, management and monitoring support for WCF and WF services.

You can read more details in this blog post: Introducing Windows Azure AppFabric Applications and the Channel 9 announcement video.

The release is already live in our LABS/Previews environment at: http://portal.appfabriclabs.com/.

There is limited space available to try out the AppFabric Application Manager CTP so be sure to sign-up as early as possible for a better chance to get access to the CTP.

To request access to the CTP follow these steps:

Sign in to the AppFabric Management Portal at http://portal.appfabriclabs.com/.
Choose the entry titled “Applications” under the “AppFabric” node on the left side of the screen.
Click on the “Request Namespace” button on the toolbar on the top of the screen.
You will be asked to answer a few questions before you can request the namespace.
Your request will be in a “pending” state until it gets approved and you can start using the CTP capabilities.

In order to build applications for the CTP you will need to install the Windows Azure AppFabric CTP SDK and the Windows Azure AppFabric Tools for Visual Studio. Even if you don’t have access to the AppFabric Application Manager CTP you can still install the tools and SDK to build and run applications locally in your development environment.

This CTP is intended for you to check out and provide us with feedback, so please remember to visit the Windows Azure AppFabric CTP Forum to ask questions and provide us with your feedback.

To learn more please use the following resources:

Composing and Managing Applications with Windows Azure AppFabric video which is part of the Windows Azure AppFabric Learning Series available on CodePlex.
Watch the relevant TechEd sessions:
MDSN Documentation
Visit the Windows Azure AppFabric website
Visit the Windows Azure AppFabric Developer page
Read the Windows Azure AppFabric Overview Whitepaper

AppFabric.tv - Announcing the Windows Azure AppFabric June CTP

Don’t forget that we already have several Windows Azure AppFabric services (Service Bus, Access Control, Caching) in production that are supported by a full SLA. If you have not signed up for Windows Azure AppFabric yet be sure to take advantage of our free trial offer. Just click on the image below and get started today!

The AppFabric Team.

Introducing Windows Azure AppFabric Applications

AppFabric Team — Tue, 21 Jun 2011 03:30:00 GMT

Posted by Karandeep Anand

Last October, at the PDC 2010 keynote, we shared our vision of building, running, and managing applications reliably and at scale in Windows Azure. Since then, the team has been heads-down to make the vision a reality, and last month at TechEd 2011, we announced that we’ll soon be releasing a rich set of new capabilities to build AppFabric Applications using AppFabric Developer Tools, run them in the AppFabric Container service, and manage them using the AppFabric Application Manager. Today, we are very pleased to announce that the day has come when we can publicly share the first Community Technology Preview (CTP) of these capabilities in Windows Azure! As announced here, the June CTP of AppFabric is now live, and you can start by downloading the new SDK and Developer Tools and by signing up for a free account at the AppFabric Labs portal. Now we’ll go into more detail about what we’ve released today and how you can get started building and managing AppFabric Applications.

AppFabric Applications

Let’s start by defining what we mean when we say AppFabric Applications. In a nutshell, it is any n-tier .NET application that spans the web, middle, and data tiers, composes with external services, and is inherently written to the cloud architecture for scale and availability. In CTP1, we are focusing on a great out-of-box experience for ASP.NET, WCF, and Windows Workflow (WF) applications that consume other Windows Azure services like SQL Azure, AppFabric Caching, AppFabric Service Bus and Azure Storage. The goal is to enable both application developers and ISVs to be able to leverage these technologies to build and manage scalable and highly available applications in the cloud. In addition, the goal is to help both developers and IT Pros, via the AppFabric Developer Tools and AppFabric Application Manager, respectively, to be able to manage the entire lifecycle of an application from coding and testing to deploying and managing.

Now, let’s take a deeper look at the 3 key pieces of the puzzle and how they all fit together to help you through the lifecycle of AppFabric Applications:

Developer Tools
AppFabric Container
Application Manager

Developer Tools

AppFabric Developer Tools provide the rich Visual Studio experience at design-time to build and debug AppFabric Applications. The key goal of the Developer Tools is to enable .NET developers to leverage their existing skills and knowledge with the .NET framework and Visual Studio and extend it to build cloud-ready applications in an easy yet rich way for Windows Azure. The Developer Tools are an extension to the existing way of building .NET applications. And the additional tooling allows developers to not only author business and presentation logic that run in the web and middle-tier, but also to easily enrich and extend their apps by composing with other services through a rich service composition experience.

The first goal with Developer Tools is to enable developers to build cloud-ready—i.e. scalable and available—applications by building on concepts they already know. The AppFabric Container service does the heavy lifting of elastically scaling and making an application available and reliable. In Developer Tools, we distilled the set of design principles and configuration knobs that a developer would need to make their application code leverage these capabilities, and we provided these via simple configuration settings on out-of-box components like WCF services and Workflows. In addition, we also provide a powerful programming model to do state management for scalable and resilient stateful services, but more on that topic later. The developer gets to specify intent on the number of scale instances, number of replicas, the partitioning policies etcetera, depending upon how much control they want; or they could go with the default settings and let the runtime manage most of it. In all cases, basic cloud design principles, like address virtualization and automatic address resolution when deployed in Azure, get taken care of automatically, without ever having to think of the underlying compute or network infrastructure.

The second goal is based on a key trend we see today: to be agile and stay competitive, developers want to focus on building code that adds value to their core offering, and therefore want to just use, or compose with, existing services. There is a large ecosystem of existing web services that help with everything from managing basic identity and access, to processing complex multi-party payments across geographies! Hence, service composition is no longer an afterthought but a core part of designing and building an application. Addressing this became one of the key design principles for the AppFabric Developer Tools experience. The tools provide a simple yet powerful experience for composing applications with first party Azure services like Caching or Storage, as well as for consuming external services like Netflix or PayPal. The extensibility of the developer tools allows even the list of service components we ship out of the box to be extended to include 3^rd party services, or your own frequently used custom services. The screenshot below shows a list of out-of-box shipping service components like ASP.Net or Caching (in blue) and some example custom service components like Authorize.Net and Facebook (in black).

To get developers started quickly, we are shipping a few templates for building applications using commonly used patterns like a high-performance ASP.NET application using Caching or a rich Silverlight Business Application. These templates get installed as part of the Developer Tools and provide an easy way to get started for building AppFabric applications.

The third key goal is to enable developers to build and debug the application as a whole. No web site or WCF service is an island; each is part of an end to end multi-tier application. AppFabric Developer Tools allow for a local simulation of building and running an application distributed across a web-tier, middle-tier and data-tier—but by building on top of the existing Windows Azure Compute Emulator that Azure developers are already familiar with.

The last design pivot is to enable developers to easily define the end-to-end multi-tier application in terms of the web and middle-tier code artifacts, database and storage resources, and a spectrum of external services referenced by the application. This metadata is automatically captured as the Composition Model. The model then gets packaged along with the application so that the management system (the Application Manager) can use it for managing the application lifecycle easily.

With CTP1, our goal is to first enable the end-to-end developer experience built around these core principles. We’ll build out richer experiences for each step in the development lifecycle as we go through future iterations of the tools.

AppFabric Container

The AppFabric Container service is the new multi-tenant middle-tier container for hosting and running mid-tier code like WCF and WF, or your custom code, at scale with high availability. At its core, the AppFabric Container consists of a large cluster of machines that have been set up to be resilient, scalable and multi-tenant, and has been pre-provisioned with the necessary frameworks and runtimes required to run your custom code, WCF services or Workflows. With AppFabric Container, we raise the level of abstraction for developers and admins so that they don’t have to deal with any of the complexity of the underlying computing, networking and storage infrastructure. Developers can focus on the business logic, and let the runtime manage the complex details of partitioning, replication, state management, address virtualization, dynamic address resolution, failover, isolation, resiliency, load balancing, request routing etcetera. You simply package and drop your WCF services, Workflows or custom .NET code into the AppFabric Container using the Application Manager or directly from Visual Studio, and let the container host, run and scale the application for you. Then you sit back and manage the service level objectives of your services via the Application Manager.

In addition, the AppFabric Container enables rich hosting scenarios & configurations for both WCF & Windows Workflows (WF). You can build and run brokered services i.e. message activated WCF services, with the integration that AppFabric Container provides with Service Bus. Also, you can run rich WF applications on AppFabric Container with support for persisting state easily and providing business process visibility through the management endpoint to get instance status. We’ll go in to a lot more detail about building WCF & WF applications to run in Windows Azure using AppFabric Container in future blog posts.

Application Manager

The Application Manager is the last piece of the puzzle. It is the infrastructure and tooling that enables you to manage any AppFabric Application through its lifecycle—configuring, deploying, controlling, monitoring, troubleshooting and scaling, all as a single logical application. It uses the metadata of the application i.e. the Composition Model, to automatically understand the components, dependencies and requirements of your multi-tier application so that you don’t have to. The screenshot below shows a sample application that spans the web, middle and data tiers; the application composes with Windows Azure and external 3^rd party services, but is being managed as a single unit in the Application Manager.

One of the first things that the Application Manager does when you publish or upload an n-tier application to it is to help you understand the end to end application structure and its contents. It then allows you to centrally configure your entire application and all its parts, including detailed WCF configuration settings—like setting timeouts and number of concurrent connections, or simple environment settings such as which database to connect to in production versus staging. Once you are done configuring the application, a single click allows you to deploy your entire application across multiple web containers and the AppFabric Container. It also wires the application up to all the internal and external referenced services, including, but not limited to, SQL Azure, Caching, Blob Storage, Service Bus Queues etc. And it uses the Access Control Service (ACS) to secure the namespaces. Anyone who has deployed a distributed application spanning multiple tiers understands all the pain that the Application Manager will take away with a single-click! And never once will you have to deal with any virtual machines, network settings or storage configurations.

In addition to centrally configuring and deploying your application, the Application Manager also helps you manage certificates to secure your application, configures the monitoring and diagnostics stores for your app automatically, and creates the right end points and URIs for your deployed services in your namespace.

Other key investments in the Application Manager are in out-of-box monitoring and troubleshooting support for your application. Once you start using your deployed application, you’ll notice a rich set of metrics being automatically generated and collected for your application—everything from basic ASP.NET metrics like number of requests, to request latency numbers for ASP.NET and WCF services, to SQL DB call execution time, to the number of times your cache gets called. All without writing a single line of code during development! And these metrics get aggregated for you across all the instances of your scaled out application, as it is running on the web and AppFabric Container. In addition, if you have built custom components, say for example, a PayPal service that you reference from your application, you can even generate custom metrics in CTP1. You can then start tracking items like the number of orders sent, the number of orders over $1000 processed, and see those custom metrics rendered along with other out-of-box metrics using rich chart controls right in the Application Manager.

On similar lines, we’ve made troubleshooting of your distributed application a lot easier by collecting and centralizing all troubleshooting logs (you get to pick the diagnostics level of the app when you build it) from all the instances of web and AppFabric Container to which the app is deployed to at any given point. All logs are available from one location in the Application Manager, and you can open the downloaded logs in the SvcTraceViewer tool for detailed debugging and diagnosis. You no longer have to write tons of scripts, peer through files, and separate infrastructure issues from application issues. You get all the logs through a UI, and programmatically through our REST API. Yes, we do offer a full REST API (and PowerShell samples too!) to automate, or programmatically access anything that the UI can do, using your own custom dashboards and management tools.

Last but not the least, the Application Manager allows you to scale-out your application with a single-click. You select the number of instances you want to scale different parts of your application to (there are restrictions on the max scale count in CTP1 as we are paying your bills!). And voila—the application automatically and elastically gets scaled out without any downtime!

While I can go on for a while describing all the cool and powerful things you can do with the CTP1 bits, I’ll wrap up this blog post by saying that we are super excited to share this technology preview and hope that you’ll be as excited to try them out and discover all the things we’ve built, and to take the conversation of building and managing applications to the next level! And remember, we have a limited capacity for CTP1 so sign-up quickly for your free account.

We have an exciting roadmap ahead, but we’ll get to that in future blog posts – for now, we’d love to hear what you have to say about your experience with CTP1. Watch out for a series of blog posts in the coming weeks that’ll go in to a lot more detail about the various scenarios, features and capabilities across the 3 key parts we’ve discussed today. Meanwhile, you can start with the samples that get installed with the AppFabric June CTP SDK or use the tutorials available on MSDN. You can also watch this short video on Channel 9 that Ron Jacobs and I did to give you a quick overview and demo of the things we’ve discussed above.

Welcome to a new era of building and managing rich cloud applications on Windows Azure!

Karandeep Anand for the AppFabric Team

Updates to Windows Azure AppFabric SDK available for download

AppFabric Team — Fri, 17 Jun 2011 11:57:00 GMT

An update to the Windows Azure AppFabric SDK is available for download. The updated SDK introduces fixes to a few bugs related to the Caching service. You can find more details on the bugs it addresses here.

If you are not experiencing any of the issues the updated SDK solves there is no need to install the updated SDK. You can download the updated SDK here.

Note: This is the production environment SDK, not the SDK used to develop for the LABS/Previews environment.

As always, feel free to ask questions and provide us with feedback on the Windows Azure Platform Forums.

If you haven’t signed up for Windows Azure AppFabric be sure take advantage of our free trial offer. Just click on the image below and get started today!

The AppFabric Team

How To Load WF4 Workflow Services from a Database with IIS/AppFabric

Ron Jacobs — Thu, 16 Jun 2011 14:05:26 GMT

Cross Post from Ron Jacobs blog

This morning I saw a message post on the .NET 4 Windows Workflow Foundation Forum titled Load XAMLX from database. I’ve been asked this question many times.

How can I store my Workflow Service definitions (xamlx files) in a database with IIS and AppFabric?

Today I decided to create a sample to answer this question. Lately I’ve been picking up ASP.NET MVC 3 so my sample code is written with it and EntityFramework 4.1 using a code first approach with SQL Server Compact Edition 4.

Download Windows Workflow Foundation (WF4) - Workflow Service Repository Example

AppFabric.tv - How To Build Workflow Services with a Database Repository

Step 1: Create a Virtual Path Provider

Implementing a VirtualPathProvider is fairly simple. The thing you have to keep in mind is that it will be called whenever ASP.NET wants to resolve a file or directory anywhere on the website. You will need a way to determine if you want to provide virtual content. For my example I created a folder in the web site called XAML. This folder is empty but I found that it has to be there or the WCF Activation code will throw an exception.

When I want to activate a Workflow Service that is stored in the database I use a URI that will point to this directory like this http://localhost:34372/xaml/Service1.xamlx

     public class WorkflowVirtualPathProvider : VirtualPathProvider

    {

        #region Public Methods

        public override bool FileExists(string virtualPath)

        {

            return IsPathVirtual(virtualPath)

                        ? GetWorkflowFile(virtualPath).Exists

                        : this.Previous.FileExists(virtualPath);

        }

        public override VirtualFile GetFile(string virtualPath)

        {

            return IsPathVirtual(virtualPath)

                        ? GetWorkflowFile(virtualPath)

                        : this.Previous.GetFile(virtualPath);

        }

        #endregion

        #region Methods

        private static WorkflowVirtualFile GetWorkflowFile(string path)

        {

            return new WorkflowVirtualFile(path);

        }

        // TODO (01.1) Create a folder that will be used for your virtual path provider

        // Note: System.ServiceModel.Activation code will throw an exception if there is not a real folder with this name

        private static bool IsPathVirtual(string virtualPath)

        {

            var checkPath = VirtualPathUtility.ToAppRelative(virtualPath);

            return checkPath.StartsWith("~/xaml", StringComparison.InvariantCultureIgnoreCase);

        }

        #endregion

    }

Step 2: Create a VirtualFile class

The VirtualFile class has to load content from somewhere (in this case a database) and then return a stream to ASP.NET. Performance is a concern so you should definitely make use of caching when doing this.

    public class WorkflowVirtualFile : VirtualFile

        {

            #region Constants and Fields

            private Workflow workflow;

            #endregion

            #region Constructors and Destructors

            public WorkflowVirtualFile(string virtualPath)

                : base(virtualPath)

            {

                this.LoadWorkflow();

            }

            #endregion

            #region Properties

            public bool Exists

            {

                get { return this.workflow != null; }

            }

            #endregion

            #region Public Methods

            public void LoadWorkflow()

            {

                var id = Path.GetFileNameWithoutExtension(this.VirtualPath);

                if (string.IsNullOrWhiteSpace(id))

                {

                    throw new InvalidOperationException(string.Format("Cannot find workflow definition for {0}", id));

                }

                // TODO (02.1) Check the Cache for workflow definition

                this.workflow = (Workflow)HostingEnvironment.Cache[id];

                if (this.workflow == null)

                {

                    // TODO (02.2) Load it from the database

                    // Note: I'm using EntityFramework 4.1 with a Code First approach

                    var db = new WorkflowDBContext();

                    this.workflow = db.Workflows.Find(id);

                    if (this.workflow == null)

                    {

                        throw new InvalidOperationException(string.Format("Cannot find workflow definition for {0}", id));

                    }

                    // TODO (02.3) Save it in the cache

                    HostingEnvironment.Cache[id] = this.workflow;

                }

            }

            /// <summary>

            ///   When overridden in a derived class, returns a read-only stream to the virtual resource.

            /// </summary>

            /// <returns>

            ///   A read-only stream to the virtual file.

            /// </returns>

            public override Stream Open()

            {

                if (this.workflow == null)

                {

                    throw new InvalidOperationException("Workflow definition is null");

                }

                // TODO (02.4) Return a stream with the workflow definition

                var stream = new MemoryStream(this.workflow.WorkflowDefinition.Length);

                var writer = new StreamWriter(stream);

                writer.Write(this.workflow.WorkflowDefinition);

                writer.Flush();

                stream.Seek(0, SeekOrigin.Begin);

                return stream;

            }

            #endregion

        }

Step 3: Register the Virtual Path Provider

Finally you register the provider and you will be on your way.

    protected void Application_Start()

    {

        Database.SetInitializer(new WorkflowInitializer());

        AreaRegistration.RegisterAllAreas();

        RegisterGlobalFilters(GlobalFilters.Filters);

        RegisterRoutes(RouteTable.Routes);

        // TODO (03) Register the Virtual Path Provider

        HostingEnvironment.RegisterVirtualPathProvider(new WorkflowVirtualPathProvider());

    }

Ron Jacobs
http://blogs.msdn.com/rjacobs
Twitter: @ronljacobs http://twitter.com/ronljacobs

Announcing WCF Express Interop Bindings

Abu Obeida — Mon, 13 Jun 2011 21:36:38 GMT

Today, we are pleased to further simplify the WS-* interop challenge by providing the WCF Express Interop Bindings Extension for Visual Studio 2010, launched at wcf.codeplex.com. This new extension enables WCF developers to avoid much of the formerly needed guesswork to configure a WCF service to connect with the top Java platforms via the known WS-* specifications, by creating custom interoperable WCF bindings on demand, building on settings described in the WS-* interop white papers.

When we shipped .NET 4, we asked you to send us your top concerns about WCF interop with Java. You've shared your thoughts, wishes and complaints. I am glad to report that we've taken your feedback to heart and are delivering on it. The most mentioned concern was reducing the complexity of configuration needed to enable .NET WCF interop with Java. Since WCF allows for all sorts of knobs to be turned, configuring an interoperable WCF service has never always been easy.

Until now, the bindings in WCF provided a wide range of interoperable and non-interoperable options to establish connections. Developers burned the midnight oil too many times, perusing various reports from WS-I, or huddling in online forums figuring out the required interop settings. Java web services, mostly relying on policy based configurations, proved tricky for .NET WCF developers to configure their services and clients. .NET Developers needed to configure security settings, algorithms, policies in various bindings elements in an often time consuming manner, resulting in a challenge larger than necessary.

We took the first step towards simplifying interop with Java by releasing a series of white papers outlining settings required for security interop with IBM WebSphere and Oracle WebLogic and Metro, along with various guidance on interop with Java datatypes and SAP.

Today, we are taking the second step in releasing this extension that simplifies interop with the leading java middleware platforms:

Simply select your platform of choice, the options of Reliable Messaging, Security, MTOM, and the extension generates a complete WCF service, configured with a dynamically generated binding that works right out of the with box with the Java platform of your choice. This extension is the best interop solution for the novice and intermediate WCF developer. Advanced developers can further customize the pre-defined settings that we have tested with the leading Java platforms for their own use. What required hours and days before is now doable in mere minutes!

The extension is provided as an open source project at wcf.codeplex.com amongst other projects by the WCF Team. Download the source code and the binary here.

We will be publishing a series of walkthroughs on codeplex helping you establish quick interoperable services. The first of which is here.

Feel free to customize this extension for your own enterprise use, and share your feedback on how this might evolve to cover more scenarios.

Thanks,

Abu Obeida Bakhach

Interoperability Program Manager

Updated IP addresses for AppFabric Data Centers

AppFabric Team — Sat, 11 Jun 2011 01:31:00 GMT

Today (6/10/2010) the Windows Azure AppFabric has updated the IP ranges on which the AppFabric nodes are hosted. If your firewall restricts outbound traffic, you will need to perform the additional step of opening your outbound TCP ports and IP addresses for these nodes. Please see the 1/28/2010 “Additional Data Centers for Windows Azure AppFabric” for full list of IP ranges, which was updated today to include changes shown below.

Updates made today are shown below:

Added IPs

United States (South/Central)
157.55.196.0/22,157.55.200.0/22

United States (North/Central)
65.52.106.240/28,65.52.106.16/28,65.52.107.0/28,65.52.106.224/28,65.52.106.32/27,65.52.106.64/27,65.52.106.160/27,65.52.106.192/27,65.52.106.96/27,65.52.106.128/27,157.55.24.0/21,157.55.208.0/21,157.55.60.240/28

United States (North/West)
65.52.98.96/28,65.52.103.128/27,65.52.98.96/28,65.55.19.64/26,65.52.99.0/24,65.52.101.0/24,65.55.25.96/28

Europe (North)
157.55.3.0/24

Europe (West)
213.199.128.0/20,213.199.180.112/28,213.199.180.32/28,213.199.180.96/28,213.199.180.192/26,213.199.183.0/24,157.55.8.128/28,157.55.8.144/28,157.55.8.160/28,157.55.8.64/26

Asia (Southeast)
207.46.48.0/20, 111.221.16.0/21, 111.221.80.0/20,111.221.96.0/20

Asia (East)
207.46.72.0/26, 207.46.89.16/28, 207.46.95.32/27, 207.46.77.224/28, 207.46.87.0/24, 207.46.67.160/27, 207.46.67.192/27

Removed IPs

None.

The AppFabric Team.

Making an activity's display name readonly in the Workflow 4 designer

Patrick D. Fletcher [MSFT] — Tue, 31 May 2011 06:10:06 GMT

To make an activity's display name readonly, it isn't enough to use the ReadOnlyAttribute on the DisplayName. In order to do this, create a custom PropertyValueEditor that displays a string in a text block, then declare an editor attribute on the "DisplayName" property of your activity. The following code demonstrates how to create a read-only custom PropertyValueEditor.

public class ReadOnlyStringEditor : PropertyValueEditor

{

    public ReadOnlyStringEditor()

    {

        FrameworkElementFactory factory = new FrameworkElementFactory(typeof(TextBlock));

        factory.SetBinding(TextBlock.TextProperty, new Binding("Value"));

        this.InlineEditorTemplate = new DataTemplate();

        this.InlineEditorTemplate.VisualTree = factory;

    }

}

The following code demonstrates how to assign the custom property editor. This should be done in the constructor for the designer.\

// Add attribute onto MyCustomActivity.DisplayName

AttributeTableBuilder builder = new AttributeTableBuilder();

builder.AddCustomAttributes(typeof(Activity), "DisplayName", new EditorAttribute(typeof(ReadOnlyStringEditor), typeof(PropertyValueEditor)));

MetadataStore.AddAttributeTable(builder.CreateTable());

Finally, assign the display name in the custom activity's constructor.

this.DisplayName = "Custom Sequence Activity";

An Introduction to Service Bus Topics

David Ingham — Wed, 25 May 2011 18:00:00 GMT

In the May CTP of Service Bus, we’ve added a brand-new set of cloud-based, message-oriented-middleware technologies including reliable message queuing and durable publish/subscribe messaging. Last week I posted the Introduction to Service Bus Queues blog entry. This post follows on from that and provides an introduction to the publish/subscribe capabilities offered by Service Bus Topics. Again, I’m not going to cover all the features in this article, I just want to give you enough information to get started with the new feature. We’ll have follow-up posts that drill into some of the details.

I’m going to continue with the retail scenario that I started in the queues blog post. Recall that sales data from individual Point of Sale (POS) terminals needs to be routed to an inventory management system which uses that data to determine when stock needs to be replenished. Each POS terminal reports its sales data by sending messages to the DataCollectionQueue where they sit until they are received by the inventory management system as shown below:

Now let’s evolve this scenario. A new requirement has been added to the system: the store owner wants to be able to monitor how the store is performing in real-time.

To address this requirement we need to take a “tap” off the sales data stream. We still want each message sent by the POS terminals to be sent to the Inventory Management System as before but we want another copy of each message that we can use to present the dashboard view to the store owner.

In any situation like this, where you need each message to be consumed by multiple parties, you need the Service Bus Topic feature. Topics provide the publish/subscribe pattern in which each published message is made available to each subscription registered with the Topic. Contrast this with the queue where each message is consumed by a single consumer. That’s the key difference between the two models.

Messages are sent to a topic in exactly the same way as they are sent to a queue but messages aren’t received from the topic directly, instead they are received from subscriptions. You can think of a topic subscription like a virtual queue that gets copies of the messages that are sent to the topic. Messages are received from a subscription in exactly the same way as they are received from a queue.

So, going back to the scenario, the first thing to do is to switch out the queue for a topic and add a subscription that will be used by the Inventory Management System. So, the system would now look like this:

The above configuration would perform identically to the previous queue-based design. That is, messages sent to the topic would be routed to the Inventory subscription from where the Inventory Management System would consume them.

Now, in order to support the management dashboard, we need to create a second subscription on the topic as shown below:

Now, with the above configuration, each message from the POS terminals will be made available to both the Dashboard and Inventory subscriptions.

Show Me the Code

I described how to sign-up for a Service Bus account and create a namespace in the queues blog post so I won’t cover that again here. Recall that to use the Service Bus namespace, an application needs to reference the AppFabric Service Bus DLLs, namely Microsoft.ServiceBus.dll and Microsoft.ServiceBus.Messaging.dll. You can find these as part of the SDK download.

Creating the Topic and Subscriptions

Management operations for Service Bus messaging entities (queues and topics) are performed via the ServiceBusNamespaceClient which is constructed with the base address of the Service Bus namespace and the user credentials. The ServiceBusNamespaceClient provides methods to create, enumerate and delete messaging entities. The snippet below shows how the ServiceBusNamespaceClient is used to create the DataCollectionTopic.

Uri ServiceBusEnvironment.CreateServiceUri("sb", "ingham-blog", string.Empty);

string name = "owner";

string key = "abcdefghijklmopqrstuvwxyz";

ServiceBusNamespaceClient namespaceClient = new ServiceBusNamespaceClient(

baseAddress, TransportClientCredentialBase.CreateSharedSecretCredential(name, key) );

    Topic dataCollectionTopic = namespaceClient.CreateTopic("DataCollectionTopic");

Note that there are overloads of the CreateTopic method that allow properties of the topic to be tuned, for example, to set the default time-to-live to be applied to messages sent to the topic. Next, let’s add the Inventory and Dashboard subscriptions.

    dataCollectionTopic.AddSubscription("Inventory");

    dataCollectionTopic.AddSubscription("Dashboard");

Sending Messages to the Topic

As I mentioned earlier, applications send messages to a topic in the same way that they send to a queue so the code below will look very familiar if you read the queues blog post. The difference is the application creates a TopicClient instead of a QueueClient.

For runtime operations on Service Bus entities, i.e., sending and receiving messages, an application first needs to create a MessagingFactory. The base address of the ServiceBus namespace and the user credentials are required.

Uri ServiceBusEnvironment.CreateServiceUri("sb", "ingham-blog", string.Empty);

string name = "owner";

string key = "abcdefghijklmopqrstuvwxyz";

MessagingFactory factory = MessagingFactory.Create(

baseAddress, TransportClientCredentialBase.CreateSharedSecretCredential(name, key) );

From the factory, a TopicClient is created for the particular topic of interest, in our case, the DataCollectionTopic.

TopicClient topicClient = factory.CreateTopicClient("DataCollectionTopic");

A MessageSender is created from the TopicClient to perform the send operations.

MessageSender ms = topicClient.CreateSender();

Messages sent to, and received from, Service Bus topics (and queues) are instances of the BrokeredMessage class which consists of a set of standard properties (such as Label and TimeToLive), a dictionary that is used to hold application properties, and a body of arbitrary application data. An application can set the body by passing in any serializable object into CreateMessage (the example below passes in a SalesData object representing the sales data from the POS terminal) which will use the DataContractSerializer to serialize the object. Alternatively, a System.IO.Stream can be provided.

BrokeredMessage bm = BrokeredMessage.CreateMessage(salesData);

bm.Label = "SalesReport";

bm.Properties["StoreName"] = "Redmond";

bm.Properties["MachineID"] = "POS_1";

ms.Send(bm);

Receiving Messages from a Subscription

Just like when using queues, messages are received from a subscription using a MessageReceiver. The difference is that the MessageReceiver is created from a SubscriptionClient rather than a QueueClient. Everything else remains the same including support for the two different receive modes (ReceiveAndDelete and PeekLock) that I discussed in the queues blog post.

So, first we create the SubscriptionClient, passing the name of the topic and the name of the subscription as parameters. Here I’m using the Inventory subscription.

    SubscriptionClient subClient = factory.CreateSubscriptionClient("DataCollectionTopic", "Inventory");

Next we create the MessageReceiver and receive a message.

MessageReceiver mr = subClient.CreateReceiver();

BrokeredMessage receivedMessage = mr.Receive();

try

{

ProcessMessage(receivedMessage);

receivedMessage.Complete();

}

catch (Exception e)

{

receivedMessage.Abandon();

}

Subscription Filters

So far, I’ve said that all messages sent to the topic are made available to all registered subscriptions. The key phrase there is “made available”. While Service Bus subscriptions see all messages sent to the topic, it is possible to only copy a subset of those messages to the virtual subscription queue. This is done using subscription filters. When a subscription is created, it’s possible to supply a filter expression in the form of a SQL92 style predicate that can operate over the properties of the message, both the system properties (e.g., Label) and the application properties, such as StoreName in the above example.

Let’s evolve the scenario a little to illustrate this. A second store is to be added to our retail scenario. Sales data from all of the POS terminals from both stores still need to be routed to the centralized Inventory Management System but a store manager using the Dashboard tool is only interested in the performance of her store. We can use subscription filtering to achieve this. Note that when the POS terminals publish messages, they set the StoreName application property on the message. Now we have two stores, let’s say Redmond and Seattle, the POS terminals in the Redmond store stamp their sales data messages with a StoreName of Redmond while the Seattle store POS terminals use a StoreName of Seattle. The store manager of the Redmond store only wishes to see data from its POS terminals. Here’s how the system would look:

To set this routing up, we need to make a simple change to how we’re creating the Dashboard subscription as follows:

    dataCollectionTopic.AddSubscription("Dashboard", new SqlFilterExpression("StoreName = 'Redmond'");

With this subscription filter in place, only messages with the StoreName property set to Redmond will be copied to the virtual queue for the Dashboard subscription.

There is a bigger story to tell around subscription filtering. Applications have an option to have multiple filter rules per subscription and there’s also the ability to modify the properties of a message as it passes in to a subscription’s virtual queue. We’ll cover these advanced topics in a separate blog post.

Wrapping up

Hopefully this post has shown you how to get started with the topic-based publish/subscribe feature being introduced in the new May CTP of Service Bus.

It’s worth noting that all of the reasons for using queuing that I mentioned in the introduction to queuing blog post also apply to topics, namely:

Temporal decoupling – message producers and consumers do not have to be online at the same time.
Load leveling – peaks in load are smoothed out by the topic allowing consuming applications to be provisioned for average load rather than peak load.
Load balancing – just like with a queue, it’s possible to have multiple competing consumers listening on a single subscription with each message being handed off to only one of the consumers, thereby balancing load.
Loose coupling – it’s possible to evolve the messaging network without impacting existing endpoints, e.g., adding subscriptions or changing filters to a topic to accommodate new consumers.

We’ve only really just scratched the surface here; we’ll go in to more depth in future posts.

Finally, remember one of the main goals of our CTP release is to get feedback on the service. We’re interested to hear what you think of the Service Bus messaging features. We’re particularly keen to get your opinion of the API. So, if you have suggestions, critique, praise, or questions, please let us know at http://social.msdn.microsoft.com/Forums/en-US/appfabricctp/. Your feedback will help us improve the service for you and other users like you.