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 https://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

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.

In an effort to make it easier for you to stay on top of the latest product releases, resources, tools and news around the Windows Azure platform, today, we’re excited to announce that the SQL Azure blog is moving into what will now be called the ‘Windows Azure Platform Team Blog’.  From now on, you can find all SQL Azure blog posts at www.WindowsAzureBlog.com.

This one-stop-shop blog is where you’ll be able to find the latest information about the Windows Azure platform and all its components, including SQL Azure. This blog will continue to cover the wide range of topics we have always addressed, from product announcements, to technical “how-to” posts, and conversations with our customers. If you’re primarily interested in just the posts about SQL Azure, you can subscribe to a dedicated RSS feed for that. Alternatively, you have the option of getting all the Windows Azure platform posts 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 those properties are integrated.  In the meantime, we hope these changes will make your life a little easier by making the Windows Azure Platform blog your single destination for all the latest news and information about SQL Azure and the rest of Windows Azure Platform.

-- Steve

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:

1. 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.
2. 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 https://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 https://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.

MSDN has created a Q&A article on Odata (Open Data Protocol). OData applies web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores. As web development continues to move forward, learning about new languages, like OData, will become more invaluable. Making an OData feed from a SQL Azure or SQL Server database is incredibly easy, usually requiring just a few lines of code.

Let me know your thoughts after reading the article.

Click here to open the article: Open Data Protocol Q&A.

-Steve

Bob Dylan

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin at elit eu mauris congue posuere. Pellentesque commodo consequat dui, a ornare lectus convallis commodo. Maecenas id mollis lacus. Maecenas vel mauris eget enim pulvinar tincidunt vel quis eros.

View Website

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: https://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 https://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:
  • Introduction to Windows Azure AppFabric Composite Applications
  • A Lap around Windows Azure AppFabric
  • Workflow in Windows Azure AppFabric
• 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.

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:

1. Developer Tools
2. AppFabric Container
3. 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

Cihan Biyikoglu has written an interesting article on database schema when working with Federations.

“With federations, you take parts of your schema and scale it out. With each federation in the root database, a subset of objects are scaled-out. You may create multiple federations because distribution characteristics and scalability requirements may vary across sets of tables. For example, with an ecommerce app, you may both have a large customer-orders set of tables and a very large product catalog that may have completely different distribution requirements.”

To learn more, click here for the article from Cihan Biyikoglu’s blog, “Considerations When Building Database Schema with Federations in SQL Azure.

-Steve

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

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 https://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
https://blogs.msdn.com/rjacobs
Twitter: @ronljacobs https://twitter.com/ronljacobs