This article is based on Azure in Action, published on October, 2010. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) eBooks and pBooks. MEAPs are sold exclusively through Manning.com. All pBook purchases include free PDF, mobi and epub. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information. [ Use promotional code ‘java40beat’ and get 40% discount on eBooks and pBooks ]

Handling Configuration at Runtime

Introduction

In this article, we will modify configuration settings at runtime and find out how to track changes when they occur. Let’s jump on the Azure portal and get started.

Modifying configuration settings in the Azure portal

You can modify the values that you set in the service configuration file dynamically at runtime by using the Azure portal. First, though, you have to redeploy your application.

After your application is redeployed and running in the fabric, you can easily modify any of your configuration settings. Select either the production or staging version of the role, and then click Configure. You’re redirected to the page shown in figure 1, in which you can modify the runtime configuration settings for the role that you selected.

Figure 1 Modifying configuration settings in the Azure portalThe Azure portal doesn’t have any fancy editors; all you see is a big text box with your service configuration file in it. Bet you’re glad you paid attention during XML school.

The Azure portal lets you directly edit the contents of the configuration settings or upload a new version of the service configuration file. After you apply your changes, they’re instantly replicated to all instances of your web role and, in some cases, you don’t have to restart any of the roles.

Figure 2 shows that you’ve modified the configuration setting mySetting from “Hello Birds Hello Trees” to “Hello Birds”.

Figure 2 Your web page showing a configuration setting that you modified via the Azure portalWow, modifying your configuration settings is easily achieved through the Azure portal. What’s even cooler is that your role can pick up and run with the changes without needing a restart. The only issue is that you might need to store a local copy of the previous setting whenever that setting changes. Let’s see how to do that.

Tracking service configuration changes

When you change a configuration setting, Windows Azure raises two events that your application can handle:

• RoleEnvironment.Changing—Fires before the changes to the setting are applied. You can still read the existing setting before the change is applied.
• RoleEnvironment.Changed—Fires after the changes to the setting are applied. You might use this event to set up a new shared resource after a cleanup of a shared resource.

To hook up and define one of these events, you can use the code shown in listing 1.

Listing 1 Tracking changes to the service configuration
[code lang=”java”]public class WebRole : RoleEntryPoint
{
public override bool OnStart()
{
DiagnosticMonitor.Start("DiagnosticsConnectionString");
RoleEnvironment.Changing += RoleEnvironmentChanging;
return base.OnStart();
}
private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e)
{
if (e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange))
{
Trace.WriteLine("Configuration Setting Changed");
// Set e.Cancel to true to restart this role instance
e.Cancel = true;
}
}
}[/code]
This rounds out our look at how to use the ConfigurationSettings functionality in Windows Azure.

Summary

We modified configuration settings at runtime and found out how to track changes when they occur. Using its ConfigurationSettings functionality, Windows Azure can read application settings from the web.config file.

This article is based on Azure in Action,published on October, 2010. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) eBooks and pBooks. MEAPs are sold exclusively through Manning.com. All pBook purchases include free PDF, mobi and epub. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information. [ Use promotional code ‘java40beat’ and get 40% discount on eBooks and pBooks ]

Developing with the Table Service

Introduction

One of the major issues with traditional SQL Server–based databases is that individual tables can grow too large, slowing down all operations against the table. Although the Windows Azure Table service is highly efficient, storing too much data in a single table can still degrade data access performance.

The Table service allows you to specify how your table could be split into smaller partitions by requiring each entity to contain a partition key. The Table service can then scale out by storing different partitions of data on separate physical servers. Any entities with the same partition key must reside together on the same physical server.

We will develop a web application to use the Table service. This application will manage our Hawaiian shirt inventory for our fictitious store website.

Creating a project

Create a new Cloud Service web role project called ShirtManagement. Open Visual Studio and select File > New > Project. Visual Studio displays a list of available templates; select the Cloud Service template group, and then select Windows Azure Cloud Service in the menu. Name the project and click OK. A pop-up menu opens in which you pick the project types you want to add to your Azure solution. Because you’re building a simple website, without any backend processing, choose the ASP.NET Web Role template. After you add the web role to the project, you can rename it; then click OK. You’ll see the New Cloud Service Project window with one solution, as shown in figure 1.

Figure 1 Creating a new Azure Application project is easy. Just add the different roles you’ll need in your solutionAs with the other storage services, communication with the Table service occurs through the REST API. Although you can use this API directly, you’re likely to be more productive using the StorageClient library provided in the Windows Azure SDK.

Whenever you create a new Cloud Service project, this library will automatically be referenced. But if you’re building a brand new class library or migrating an existing project, you can reference the following storage client assembly manually:

• Microsoft.WindowsAzure.StorageClient

In addition, you’ll need to reference the ADO.NET Data Services assemblies:

• System.Data.Services
• System.Data.Services.Client

ADO.NET Data Services

The Table service exposes its HTTP REST APIs through its implementation of the ADO.NET Data Services framework. The use of this framework means we can utilize the ADO.NET Data Services client assemblies to communicate with the service rather than having to develop or use a custom REST wrapper.

Because ADO.NET Data Services is used by the Storage Client SDK, you’ll need to reference those assemblies too.

Now that we’ve set up our project, let’s look at how we can add our product entity class to the project.

Defining an entity

Before we create our product-management web page, we need to create our entity in the web project. At this stage, we’ll just add our entity directly to our web page.

To keep our example simple, we’ll just store the shirt name and description. Add a new class to your web project named Product.cs and define the class as shown in listing 1.

Listing 1 Product entity
[code lang=”java”]public class Product : TableServiceEntity
{
public string Name { get; set; }
public string Description { get; set; }
}[/code]
In listing 1, the Product class inherits from the TableServiceEntity base class (Microsoft.WindowsAzure.TableService.TableServiceEntity). This base class contains the three properties required by all table storage entities:

• Timestamp
• PartitionKey
• RowKey

Now that we’ve set up our project and defined our entity, we need to create a table to store our entity in. The same method can be used in both the development and live environments.

Creating a table

The simplest method of creating a table is to create a PowerShell script or to use one of the many storage clients that are available. In this chapter we’ll use Azure Storage Explorer, which you can download from CodePlex: http://azurestorageexplorer.codeplex.com/.

In this section, we’ll look at how to create a table in two ways: using Azure Storage Explorer and using code.

Creating a table using the Azure Storage Explorer

Once you have downloaded and fired up Azure Storage Explorer, it will automatically connect you to your development storage account as long as your local development storage service is running.

To create a new table in your storage account, all you need to is select Table > New Table and enter the name of your table (Product, in this case). Figure 2 shows our newly created Product table in Azure Storage Explorer.

Figure 2 The Azure Storage Explorer showing our newly created Product tableAlthough using a tool such as Azure Storage Explorer is probably the easiest method of creating a new table, you may wish to do this manually in C#.

Creating a table in code

In this example, we’ll manually create a console application that will create a new table in our storage account when it’s run. Although we’ll use a console application in this example, we could easily use a web application, Windows Forms application, or Windows Presentation Foundation application. The deployment application doesn’t need to be a cloud application (web or worker role); it can be a standard application that you run locally.

To create the application, perform the following steps:

1. Create a console application targeting .NET 3.5.
2. Add a reference to System.Data.Services.
3. Add a reference to System.Data.Services.Client.
4. Add a reference to Microsoft.WindowsAzure.StorageClient.
5. Add an app.config or web.config entry with your storage account credentials.
6. Add the following code to create the table:

[code lang=”java”]CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>
{
configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));
});
var storageAccount =
CloudStorageAccount.FromConfigurationSetting("DataConnectionString");
CloudTableClient tableClient =
storageAccount.CreateCloudTableClient();
tableClient.CreateTableIfNotExist("Product");[/code]
The code added in step 6 retrieves storage account information from the app.config and then calls the CreateTableIfNotExist method from the CloudTableClient object, passing in the name of the table to create (Product).

Deploying to live

The code used to create a new table won’t only work on your development storage account but will also work against the live system. All you need to do to make this code work against the live system is to change the DataConnectionString configuration setting to your live account.

Now that we know how to create our table both in the live system and in development storage, it’s worth taking a quick peek at how this is implemented in the development storage backing store. Figure 3 shows how tables are represented in the development storage SQL Server database.

Figure 3 How tables are represented in the development storage SQL Server databaseAs we can see in figure 3, the SQL Server database that stores our entities is pretty flexible. The TableContainer table keeps a list of all the tables stored in our development storage account. Because we can create tables dynamically, any new table created will contain a new entry in this table.

Each row in the TableRow table in figure 3 stores a serialized version of our entity. As you can see from this table definition, the only fixed data that’s stored in this table are AccountName, TableName, PartitionKey, RowKey, and TimeStamp. All other properties are stored in the Data column. As you can see, the actual development storage schema relates to the logical representation that we can see in table 1.

Summary

The Table service provides massively scalable storage and it differs from traditional relational databases, such as SQL Server. The Table service is a scalable way of storing and querying entities. We can sometimes assume we need relational databases when there are other ways of representing data in our solution. Designing systems is all about tradeoffs, and the tradeoff with relational databases is scalability. By using the Table service, you gain scalability, but the cost is that you have to think and design systems in a different way.

This article is based on Azure in Action, published on October, 2010. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) eBooks and pBooks. MEAPs are sold exclusively through Manning.com. All pBook purchases include free PDF, mobi and epub. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information. [ Use promotional code ‘java40beat’ and get 40% discount on eBooks and pBooks ]

Introduction

A cache is a temporary, in-memory store that contains duplicated data populated from a persisted backing store, such as a database. Because the cache is an in-memory data store, retrieving data from the cache is fast (compared with database retrieval). Since a cache is an in-memory temporary store, if the host process or underlying hardware dies, the cached data is lost and the cache needs to be rebuilt from its persistent store.

Never rely on the data stored in a cache. You should always populate cache data from a persisted storage medium such as Table storage, which allows you to persist back to that medium if the data isn’t present in the cache.

NOTE For small sets of static reference data, a copy of the cached data resides on each server instance. Because the data resides on the actual server, there’s no latency with cross-server roundtrips, resulting in the fastest possible response time.

In most systems, two layers of cache are used: the in-process cache and the distributed cache. In this article, we’ll look at both.

Let’s take a look at the first and simplest type of cache you can have in Windows Azure, which is the ASP.NET in-process cache.

In-process caching with the ASP.NET cache

As of the PDC09 release, the only caching technology available to Windows Azure web roles is the built-in ASP.NET cache, which is an in-process individual-server cache. Figure 1 shows how the cache correlates with your web role instances within Windows Azure.

Figure 1 shows that both server A and server B maintain their caches of the data that’s been retrieved from the data store (either from the Table storage or from the SQL Azure database). Although there’s some duplication of data, the performance gains make using this cache worthwhile.

In-process memory cache

You should also notice in figure 1 that the default ASP.NET cache is an individual-server cache that’s tied to the web server worker process (WaWebHost). In Windows Azure, any data you cache is held in the WaWebHost process memory space. If you were to kill the WaWebHost process, the cache would be destroyed and would need to be repopulated as part of the process restart. Because the VM has a maximum of 1 GB of memory available to the server, you should keep your server cache as lean as possible.

Although in-memory caching is suitable for static data, it’s not so useful when you need to cache data across multiple load-balanced web servers. To make that scenario possible, we need to turn to a distributed cache such as Memcached.

Distributed caching with Memcached

Memcached is an open-source caching provider that was originally developed for the blogging site Live Journal. Essentially, it’s a big hash table that you can distribute across multiple servers. Figure 2 shows three Windows Azure web roles accessing data from a cache hosted in two Windows Azure worker roles.

Microsoft has developed a solution accelerator that can serve as an example of how to use Memcached in Windows Azure. This accelerator contains a sample website and the worker roles that host Memcached. You can download this accelerator from http://code.msdn.microsoft.com/winazurememcached. Be aware that memcached.exe isn’t included in the download but can be found online.

Hosting Memcached

Although we’re using a worker role to host your cache, you could also host Memcached in your web role (saves a bit of cash).

To get started with the solution accelerator, you just need to download the code and follow the instructions to build the solution. Although we won’t go through the downloaded sample, let’s take a peek at how you store and retrieve data using the accelerator.

Setting data in the cache

If you want to store some data in Memcached, you can use the following code:
[code lang=”java”]AzureMemcached.Client.Store(Enyim.Caching.
[CA]Memcached.StoreMode.Set, "myKey", "Hello World");[/code]
In this example, the value “Hello World” is stored against the key “myKey”. Now that you have data stored, let’s take a look at how you can get it back (regardless of which web role you’re load balanced to).

Retrieving data from the cache

Retrieving data from the cache is pretty simple. The following code will retrieve the contents of the cache using the AzureMemcached library:
[code lang=”java”]var myData = AzureMemcached.Client.Get<string>("myKey"));[/code]
In this example, the value “Hello World” that you set earlier for the key “myKey” would be returned.

Although our Memcached example is cool, you’ll notice that we’re not using the ASP.NET Cache object to access and store the data. The reason for this is that, unlike the Session object, the Cache object (in .NET Framework 3.5SP1, 3.5, or 2.0) doesn’t use the provider factory model; the Cache object can be used only in conjunction with the ASP.NET cache provider.

Using ASP.NET 4.0, you’ll be able to specify a cache provider other than the standard ASP.NET in-memory cache. Although this feature was introduced to support Microsoft’s new distributed cache product, Windows Server AppFabric Caching (which was code-named Velocity), it can be used to support other cache providers, including Memcached.