Hosting a PHP Application in Windows Azure

Introduction

At MIX ‘09 we (Microsoft) announced support for FastCGI in Windows Azure.  FastCGI allows us to host applications like PHP both safely and performantly (warning – performantly is not a real word).  In this post, I will begin with a very brief overview of what Windows Azure is and why you might consider hosting your PHP apps on Windows Azure.  I will then provide you with a couple of resources that you can use to easily publish your PHP application to Windows Azure, including a link to a screencast I created that illustrates just how to publish a PHP application to Windows Azure.

 

PHP Interop Series

This is part of a small series of blog posts and screencasts that I am doing on interoperability between PHP and the Microsoft stack.  My goal is to illustrate some features of the MS stack that PHP developers can take advantage of, as well as to illustrate how it is done.

 

What is Windows Azure (from 30,000 feet)

Simply put, Windows Azure is a cloud platform.  The platform provides the ability to host applications (Web Applications, Web Services and Services that don’t accept HTTP Requests) and to store and retrieve data in the cloud.  The important part of the last sentence is “in the cloud”.  Clearly, Windows Server 2008 (along with a multitude of other operating systems) provides the services to host applications and store and retrieve data.  The “in the cloud” part is the clear differentiator for Windows Azure.

You might then think that the cloud to Microsoft would simply be one or several datacenters filled with servers running Windows Server 2008 either virtually or on physical servers.  However, it is much more than that.  What differentiates Windows Azure from that environment is something known as the Windows Azure fabric.  This fabric ties all of the Azure nodes together into a cohesive whole.  This fabric provides several benefits to the applications running in Windows Azure, including manageability and health monitoring.

Windows Azure provides a portal where the application owner can simply configure how many instances of an application are running in the cloud.  In the case of web applications running on multiple instances, you need not worry about configuring the load balancer.  The Windows Azure fabric handles that for you.  For example, if you decide that you want your application running on 5 instances instead of 2, you simply change a single setting in a configuration file.  Windows Azure does the rest.  You application is deployed on 3 additional instances that are wired appropriately to the load balancer.

What happens when one of these instances is no longer healthy?  Another of the functions of the fabric is to monitor the health of the applications and servers.  Windows Azure will simply bring up another instance of your application and re-route traffic to that new, healthy instance.  Think of the complexity of building this kind of tolerance yourself.

 

Why Host my PHP Application in Azure?

Some of the benefits of hosting your application in Azure should be apparent from the preceding discussion.  They include scalability, availability and manageability.  Other benefits that may not be so apparent are the fact that you only pay for what you use and there is no lead-time required to bring up instances of your applications.

Pay for what you use / Lead time required

A key differentiator between all cloud platforms (not just ours) and hosted environments is that with cloud platforms you only pay for what you use and do not have to commit to future use.  In a typical hosted environment, you will likely have to commit to a defined term of use.  Further, in hosted environments, there is often a lead time required to get up and running.  There are obviously exceptions to this, notably in shared hosting scenarios.  However, if you are looking for dedicated hosting on a number of nodes, you will probably find that a significant lead time is required, along with a long-term contract. 

With Windows Azure, you simply pay for what you use and the only lead-time that is required is the amount of time required to spin up the new node.  This provides you with the flexibility to spin up new instances when demand requires and scaling back when that action is warranted. 

Scalability and Availability

This pay for what you use model allows you to scale up when demand requires and scale back when demand is down.  This can be great for startups that are intellectual property rich and cash poor.  They do not want to invest heavily in the infrastructure required to meet their forecasted demand.  However, they do want to be able to meet demand if their product or service takes off.  Further, because the Windows Azure fabric is monitoring the health of your application instances, re-routing requests to new instances where required, you can be self-assured that your application will be available to your customers.

Manageability

The goal of any abstraction layer is to hide the complexity of a given task from the end user, allowing them to focus on business-specific problems.  By hosting your PHP application in Windows Azure, you need not worry about provisioning servers, configuring the operating systems, administering patches, deploying instances of web applications and wiring them to load balancers.  All of this is neatly handled for you.  All you have to do is simply deploy your application to the Azure portal and change some simple configuration settings.

 

Resources for Publishing your PHP Application to Azure

The following are some resources that you can take advantage of.  They make it easy to publish your PHP application to Windows Azure.  They include a screencast I put together that details every step, a comprehensive blog post by Wade Wegner that lists the steps for publishing (this is what I used when I first did it), along with a link to a blog post I put together that illustrates how to get started with Azure.  The last post shows you all of the steps required to sign up for Windows Azure.

• Screencast on Hosting a PHP Application in Windows Azure
• Wade Wegner’s Post on ‘Running a PHP application on Windows Azure’
• Post on Getting Started with Windows Azure  

Comments Please

Please leave me a comment, letting me know whether this post / series is helpful to you or not.  I would really appreciate it!

PHP and IIS: Running PHP under Fast CGI and Url Rewriting

Introduction

You can run PHP (as well as other CGI apps) on IIS7 with high performance and reliability thanks to FastCGI.  CGI is a protocol that defines how web servers launch an executable resulting from a request, pass it arguments and return the dynamic response.  You have been able to host CGI applications in IIS in the past, however there have been challenges prior to FastCGI.  As it turns out, the challenge is that there are certain modules (in PHP, for instance) that are not thread safe.  For that reason, IIS traditionally spun up a new process for each request.  This provided the reliability necessary in the face of non-thread-safe modules.  However, the performance suffered due to the cost of spinning up all of these processes.  Enter FastCGI.  It guarantees that each process will handle 1 request at a time (providing the reliability), but it allows for process reuse by maintaining a pool of processes.

While installing PHP on IIS7 wasn’t overly complex in the past (see this article if you want the details) we now have the Web Platform Installer that makes installing FastCGI, PHP and much much more a breeze.  Now, just because you can host PHP on IIS with reliability and high performance, it doesn’t necessarily mean you should.  You need some reasons, right?  Well, in this post, I will illustrate how to install PHP and FastCGI on IIS7 easily and illustrate one of many reasons you will want to: The UrlRewrite Module.  This module allows you to easily create SEO-friendly Uris for your application.  Let’s get to it.

 

PHP Interop Series

This is part of a small series of blog posts and screencasts that I am doing on interoperability between PHP and the Microsoft stack.  My goal is to illustrate some features of the MS stack that PHP developers can take advantage of, as well as to illustrate how it is done.

 

Screencasts

You can see screencasts on YouTube of the topics in this post here:

• Installing PHP and FastCGI on IIS7 in under 5 minutes
• Create SEO-Friendly URLs with the IIS7 UrlRewrite Module

   

Set Up a Test Environment (optional)

You can test all of this on Vista, Windows 7 or Windows Server 2008.  We have made it pretty easy for you to to set up a virtual environment for testing.  You can click here to download Windows Server 2008 Evaluation Virtual Hard Drive Images.  Although it says Virtual Server 2005 is required, the VHD works on Virtual PC 2007, as well.  You simply need to download the WS08_RTM_x86_EnterpriseVHD.exe or, if you want smaller downloads the WS08_RTM_x86_Enterprise.part01.exe and all of the subsequent rar files.  You will also need the WS08_ServerCore86_EnterpriseVHD.exe.  You simply uncompress these and register the VHD with Virtual PC or Virtual Server.  That is exactly what I did.

Install the Web Platform Installer

1. Navigate to http://www.microsoft.com/web/downloads/platform.aspx and click the download link to ‘Microsoft Web Platform Installer 2.0 Beta’
   
2. Click Run (If you get a security warning, click run again)
   
3. The Web Platform Installer is now installed.  You will see the UI, where you can choose items to install.  Feel free to close this.  You can re-open it at any time.
   

 

Install PHP, FastCGI and the URLRewrite Module

1. Open the Web Platform Installer 2 Beta (if you closed it)
2. Under ‘Web Platform’, choose ‘Web Server’.  Select the following items to install
   • Static Content
   • URL Rewrite
   • CGI

   

3. Under ‘Web Platform’, Choose ‘Frameworks and Runtimes’.  Select the following item to install
   • PHP 5.2.9-2

   

4. Click ‘Install’
5. Click ‘I Accept’ if you accept the license terms and conditions
6. That is it!  PHP is installed and FastCGI is configured for you.

 

Test a PHP Sample Application

I have a very simple PHP application that you can use to test your install (as well as the rewrites later).  You can download it here.  If you have your own application feel free to use it.  Here are the steps I used to setup my test environment on my Windows Server 2008 VHD:

1. Create a directory called Demos
2. Download the sample application from the link above
3. Copied the TestPHP directory under my new demos directory.  (if you cannot seem to copy in your virtual hard disk, make sure you may need to install the virtual pc additions)
4. Register the virtual directory in IIS
   • Open IIS
   • Right-Click on your web and choose Add Virtual Directory
     
   • Set the Alias to ‘TestPHP’ and the Path to C:\Demos\TestPHP
     
   • Open a browser and navigate to: http://localhost/TestPHP/catalog.php.  You should see something like this:
     

   To prove to yourself that php is actually running and configured, navigate to http://localhost/TestPHP/contactus.php.  Take a look at the code and you will see the line of code that adds the header ‘Contact Us’:

<?php echo "Contact Us" ?>

You can also navigate to http://localhost/TestPHP/index.php.  It will echo the results of phpinfo().

 

Add some UrlRewrite Rules

Remember that we have already installed the UrlRewrite 1.1 Module with the Web Platform Installer.  Let’s use this module so we can create some friendly URLs for our PHP Application.  We do this by adding rewrite rules.  I’m going to show you a feature that is new to version 1.1 called Rewrite Maps.  It acts just like it sounds.  It allows you to define simple rewrite maps (your basic from –> to mapping).  I would guess that this will be used pretty commonly when creating search-engine-friendly URLs.  Let’s take a look.

1. Open up IIS and click on your default web site.  Then double-click on Url Rewrite
   
   
2. Now we want to create our map.  Click on the ‘View Rewrite Maps…’ link on the right side.
   
   
3. Click ‘Add Rewrite Map…’
   
   
4. Click ‘Add Mapping Entry…’
   
   
5. Remembering that Virtual Directory name was ‘TestPHP’ and our catalog page was called ‘catalog.php’.  The URL to our page is: http://localhost/TestPHP/catalog.php.  We also had a page called ‘contactus.php’ (Url http://localhost/TestPHP/contactus.php). These are pretty ugly Urls. The extension ‘php’ means nothing to the general public.  Perhaps we want the Urls to look more like http://localhost/catalog and http://localhost/contact.  Let’s add the following 2 rules:

   

   

6. Now we need to add the rewrite rule that uses the map.  Click ‘Add Rules…’
   
   
7. Choose ‘Rule with rewrite map’
   
   
8. Leave the rule action set to ‘Rewrite’.  Under the ‘Choose the rewrite map’ section, choose the map you created earlier.  Mine was named ‘PHPTestMap’.  Click ‘OK’
   
   

 

Test It

Now we can type in our friendly URI into the address bar of our browser.  Nice.

Conclusion

As you can see, the Web Platform Installer makes configuring PHP to run on IIS a simple task.  You can also see the power of the IIS pipeline.  There are a wide array of modules like the UrlRewrite module that you can take advantage of.

Azure Application Part 3: Expose (REST) Web Service And Consume in Silverlight

This is part 3 in this series where I am building an Azure shopping cart application from the ground up.  In this post, I will create a RESTful service using WCF and host it in Windows Azure.  This service will source it’s data from Azure Table Storage.  I will then illustrate how to consume this service from a Silverlight component hosted in Windows Azure.  Giddyup.

(In part 2 I illustrated how to set up and access Azure Table Storage in both the development environment, as well as in the cloud.  I created a Wine table, added a few entities and retrieved them both locally and from the cloud.  I did all this taking advantage of the ADO.NET Data Services .NET Client Library and the StorageClient sample application.)

 

Watch the Screencast

• deCast – Building an Azure App Part III: Hosting Web Services and Silverlight 

Building Our RESTful Service

By now, you have more than likely heard of REST and have at least an ancillary understanding of it.  I further hope you have had the chance to develop RESTful services, taking advantage of our webHttpBinding in WCF.  If not, I invite you to look at my 10 part series on REST in WCF.  In that series, I provide an overview of REST and illustrate how to implement RESTful services using WCF 3.5.  The goal of this post is not to do a deep dive on REST, rather, to illustrate that you can host these WCF RESTful services in Windows Azure (as well as consume them from components hosted in and out of Windows Azure).  That being said, if you are not familiar, I will provide a 50,000 foot description of what REST is.  (please forgive me, but I am copying this description almost verbatim from an earlier post of mine)

 

REST Overview

REST is an architectural style that embraces the standards of the web such as HTTP and URI.  Because it is an “architectural style” there are endless debates as to what is RESTful and just what REST means.  I only intend to provide a general overview of REST here, as addressing that debate is beyond the scope of this post.  However, if you are interested in an in-depth understanding of REST, please read/view my 10+ part series of posts and screencasts on the subject.

In general, exposing services using a RESTful architectural style simply means embracing and adhering to the standards of the web.  What the heck does that mean?  Here are some examples:

• Treat everything as a resource and use URIs to uniquely identify resources.  My customers may be represented as http://www.robbagby.com/customers, whereas a single customer named fred may be represented as http://www.robbagby.com/customers/fred.  Finally my customers that have not paid may be represented as http://www.robbagby.com/deadbeatcustomers.
• Use the appropriate HTTP Verbs (GET, PUT, POST, DELETE) for the appropriate action.  Issue an HTTP GET to http://www.robbagby.com/customers/fred fetch a representation of fred, whereas issue an HTTP DELETE to the same URI to perform a delete action.
• Where appropriate, use standard representation formats (ATOM, XHTML, Microformats, etc.) to represent resources. 
• Use HTTP Headers appropriately
  • Use HTTP Status Codes to alert the caller as to the result of the call.
  • The Accept HTTP Header can be used to alert the server to the representation format you would prefer.
  • Use the Authorization header for authorization credentials.

The above list is certainly not an exhaustive list, but should give you a general idea of what REST is (with regards to services).

 

Why Build a RESTful Service

For the purposes of this post, we are going to create a simple GET service that simply exposes the Wines that we are storing in Azure Table Storage.  Why are we going to do that?  Azure Table Storage data is already exposed RESTfully, isn’t it?  Well there are a few reasons.  They are as follows:

• Perhaps we want to expose our wines without requiring authentication.
• Perhaps we want to expose our wines in a different representation format than ATOM (such as JSON or POX or whatever we feel like)
• Perhaps we want to massage the data prior to exposing it.
• Perhaps this data was not sourced in Azure Table Storage.  Perhaps this data was stored in SDS.
• We want to consume this data from Silverlight.  Silverlight precluded you from adding an Authentication header when making a request.  Therefore, as of now, you cannot directly access Azure Table Storage via Silverlight.
• This is a sample, so I want to keep this part simple.  I do not want to overcomplicate the sample with a bunch of data manipulation.
   

  Implement Our RESTful Service

  There are many ways to skin a cat (I just learned last night that this saying has nothing to do with felines, rather Catfish – go figure).  What I mean is that there are multiple ways to create a REST service with WCF.  There are 2 out-of-the-box templates and a bunch more in the WCF REST Starter Kit on CodePlex.  I am going to use the AJAX template (and de-AJAXify it) because it take a few steps and renders very clean code.  For production applications, I would strongly urge you to take a look at the WCF REST Starter Kit.  Enough babbling, here are the steps to create the service:

1. Right-Click on the AzureStore_WebRole project > Add > New Item
2. Choose the ‘AJAX-enabled WCF Service template and Name it: WineService.svc
   
3. The template did a few things for us:
   • It added references for us, including System.ServiceModel
   • It added a System.ServiceModel element in the web.config (if there wasn’t on, which in our example there wasn’t).  Under this node, it added the appropriate WCF Configurations, including an endpoint with our RESTful binding webHttpBinding and a pointer to an enableWebScript endpoint behavior (the AJAXiness of this template).
   • It added an svc file.  This file acts as the endpoint when hosting in IIS or WAS.  The file has a ServiceHost directive, pointing to the type that contains the service code, among other things as we’ll see in a minute
     
   • It added a class file that contains the implementation.  The ServiceHost above points both to the physical location of this class (CodeBehind), as well as the type (Service).  This class is where we are going to do our work.

   

4. Open the web.config and delete the System.ServiceModel section of the configuration (from <System.ServiceModel>… to </System.ServiceModel>).  This template used a configuration approach.  We are going to go with a configurationless model.  We do this by declaring a Factory in the ServiceHost directive in the svc file.
5. Open up the svc file (right-click on the svc file > View Markup).
6. Add Factory=”System.ServiceModel.Activation.WebServiceHostFactory” to the ServiceHost directive.  This is the configurationless model.  This factory will dynamically set up an instance of the WebServiceHost in response to requests.  It will set up a default endpoint, if appropriate, with the binding set to webHttpBinding, our REST-Friendly binding.
   
7. So, now we are all set up from a configuration(less) poing of view.  Now we just need to write the service for the code. 
   • Open WineService.svc.cs
   • Replace the code with the following:
     
8. That’s it.  We are ready to test.
9. Run your project (F5)  (remember that we are still pointing at Azure Table Storage in the cloud.  You might want to change your configuration settings back to point at local developer storage
10. Change the URI in Internet Explorer to the following:  http://127.0.0.1:81/WineService.svc/wines  Here is what you should see:
    
11. Cool, our service is working.  We now need to change the ResponseFormat back to Json.  Change the ResponseFormat to WebMessageFormat.Xml in WineService.svc.cs.
    

     

Create Our Silverlight Component

We are going to build a Silverlight component that will consume the RESTful service we just created. In this post, we will start building out the catalog component.  If you remember back to the first screencast, this is the portion of the application where the wines were exposed and you were able to page through it.  I will implement the paging in a future post.  What we are going to do here is to:

• Create a ListBox in Xaml
• Wire up an event handler for the loaded event
• Call our RESTful service
• Deserialize the response to a collection
• Bind our ListBox to the collection
• Pretty Up the Xaml

Well, now that we know what we are going to do, let’s get to doing it:

1. Add a Silverlight Application Project to the Solution:  Right-Click the Solution > Add > New Project > Silverlight > Silverlight Application
   
   
2. Leave the defaults on the Add Silverlight Application.  These choices will add this project to the Silverlight Applications for our web role, will create 2 test pages that by default contain a control from our project and setup debugging.
   
3. Add a ListBox directly under the grid. 
   • Give it an x:Name of WineListBox.
   • Set the DisplayMemberPath to ShortWineName.  I realize this is soooooo WinForms.  We will pretty this up in just a bit. 
     
4. Wire up a Loaded Event Handler to fetch the Wines
   • Open Page.xaml.cs
   • Wire up the event handler in the constructor
      
   • Add a private property that returns the root Uri to the web.  We will use this to calculate the Uri to our RESTful service
     
   • Code up the event handler for the loaded event.  Here we want to call our RESTful service
     
     • Start by using the helper method we created earlier to calc the Uri to our RESTful service
     • Create an instance of the WebClient class.  This is the simplest HTTP networking class to use in Silverlight.
     • We are going to call the OpenReadAsync method to issue an HTTP GET to our RESTful service.  The call is asynchronous (as are all networking calls in Silverlight), so we must first wire up an event hander to handle the response.
   • Add references to System.ServiceModel.Web and System.Runtime.Serialization.  We need these to use the DataContractJsonSerializer to deserialize the response.
     
   • OK, so now we are ready to write the callback method for our HTTP GET to our RESTful service.  This is where it may seem a bit tricky.  Remember that our service returns a List<Wine>.  The challenge we will have is that our Silverlight control has no concept of what a ‘Wine’ is.  That class exists on the server, and the control is on the client.  So what we need to do is to create a Wine class on the client that we can use to deserialize our response.
     
   • Write the event handler for OpenReadCompleted.  We will be passed the response as a Stream in the EventArgs.  We will use the DataContractJsonSerializer to deserialize the response.  Once deserialized, we can simply set the ItemsSource of the ListBox.
     
5. Test It
   
6. Pretty it up.  We got it working, but it isn’t very nice looking.
   • Open App.xaml
   • Add the Layout Styles and the ListBox Styles
     
     
   • Open Page.xaml
   • Delete the Height and Width attributes from the UserControl node
   • Update the layout of the control.  Replace the Xaml with the following:
     
   • Add a DataTemplate to the ListBox
     
   • Copy the Images Directory from the Web into the Silverlight Project
7. Test It
   

Well, now we’re getting somewhere!  It’s starting to look pretty good.  In the next post, I will implement paging, so don’t simply fetch all of the wines, rather we fetch a few at a time.  In future posts, I will illustrate how to use SOAP services instead of REST, implement the cart, security, and much, much more.  Until then…

Azure Application Part 2: Access Azure Table Storage

This is part 2 in this series where I am building an Azure shopping cart application from the ground up.  In this post, I will create a simplified ASP.NET version of the wine catalog.  We will create a table in developer storage (the local version of Azure Storage) to store our wines and write 2 web pages: 1 to view all wines and another to add a wine.  We will then access the same table in the cloud in Azure Table Storage.

(In part 1 I prepared my environment by setting up my development environment, creating a Windows Azure Account and creating a Hosted Service account.  I then created a Web Cloud Service project in Visual Studio and wrote a very simple “Hello, World” example.  I ran this sample locally and debugged it.  I then deployed it to the cloud.)  

 

Watch The Screencast

• deCast – Building an Azure App Part II: Azure Table Storage

 

Add The 2 ASP.NET Web Pages

Let’s get started by adding the 2 ASP.NET web pages we are going to be working with in this post.  We want a page to view all wines (we will work with paging in a subsequent post) and a page to add a wine.  I don’t plan on illustrating editing a wine, but if I receive any feedback – hint, hint – I can change my plans.

1. Right-Click on the AzureStore_WebRole project > Add > New Item
2. Choose Web > Web Form > Name: ViewWines.aspx
   
3. Add a GridView (WineGridView) and a Button (AddWineButton)
   
4. Follow the same process as above to create a web form named AddWine.aspx
5. Add the following controls using whatever layout you wish (I know – tables are so 2002.  BTW, do you know when it is actually good practice to use tables?  When you want a table)
   
6. Download the images folder that contains the wine images from here
7. Add the Images folder (and it’s contents) to the  AzureStore_WebRole project

We’ll get back to these pages after we have our table set up…

 

A Brief Overview of Azure Tables

Azure Storage Tables are table-like structured storage.  I say table-like because they do not conform to the rows / columns structure we are used to for tables.  Azure Tables store Entities which are analogous to a row.  Entities are comprised of name-value pairs called Properties.  It is important to understand that Azure Tables do not enforce schemas.  Therefore, a table can store entities with wholly different structures.  However, the developer can choose to enforce schemas via code.

The Storage Account acts as the parent namespace for Table Storage, therefore you will not have any naming collisions with others that have similarly named tables.  Here is the best visual I could come up with to illustrate the structure:

  

You may have noticed that, unlike some other cloud storage systems, the properties are typed.  Here is a list of supported types:

• Binary
• Bool
• DateTime
• Double
• GUID
• Int
• Long
• String

There are 3 properties that every entity must have!  They are:

• PartitionKey (string) – Tables are partitioned.  The goal of Table Storage is to support massive scalability and availability.   We therefore load balance across storage nodes.  The partition key is used to tell the infrastructure that entities with the same partition key need to be stored together.  The partition key forms half of the entities primary key.
• RowKey (string) – The RowKey is other half of the dual key.
• Timestamp (DateTime) – This property is used to store the last modified date and is used for things like optimistic concurrency.

 

Setting Up For Azure Tables

In a previous post, I discussed ad nauseam the REST API for Azure Table Storage, the role of ADO.NET Data Services, as well as the purpose of the StorageClient application so I am not going to go into much detail here.  To summarize that post bullet style in less than 500 words:

• ADO.NET Data Services is a framework that allows one to easily expose and consume data services. 
• The framework includes a server library that exposes data securely as RESTful services, as well as client libraries to enable consuming these services easily.  One such library is the .NET Client Library.
• The ADO.NET Data Services team implemented a REST API that is compliant with the ADO.NET Services API, with some minor differences (for a listing of those differences, see this documentation). 
• One of the notable differences is the Shared Key (Lite) Authentication extension.  This is how requests to Azure Table Storage are authenticated. 
• The Windows Azure SDK shipped with a StorageClient sample application that extends the .NET Client Library, adding functionality such as signing the requests.

We are going to take advantage of the StorageClient sample application, using it as our API.  The nice thing about StorageClient and the .NET Client Library is that they completely abstract away the complexity of making these RESTful calls.  They hide the HTTP calls, the serialization and deserialization, as well as the message signing.  We just work with objects.  Let’s get started coding by creating the object that will represent our entity.

 

Create The Object That Represents Our Entity

We need to start by creating a class that represents our entity.  When fetching an entity from Table Storage, it will be deserialized into this type.  We will also use this entity for actions.  Let’s get started.

1. Add a reference to System.Data.Services.Client
2. Set a reference to the StorageClient library.  You can either add the sample project to the solution and add a project reference or you can add a reference to the compiled dll.  I am going to add the StorageClient project to the solution and add a project reference. 
3. Add a new class named Wine.cs to the AzureStore_WebRole project
4. Add 5 properties to the class. 
   • string ShortWineName (can be auto-implemented)
   • string WineLabelUri (can be auto-implemented)
   • string Vintage(can be auto-implemented)
   • double BottlePrice (can be auto-implemented)
   • int WineID (do not make it auto-implemented)

   

    

5. Implement class TableStorageEntity from StorageClient. 
   • You will have to import the Microsoft.Samples.ServiceHosting.StorageClient namespace
   • Remember that every entity in Table Storage requires 3 properties: PartitionKey, RowKey and TimeStamp.  The TableStorageEntity base class has these properties.
   • Every entity in ADO.NET DataServices needs to have a unique key.  ADO.NET DataServices uses a DataServiceKeyAttribute to annotate what the unique key is.  As pointed out earlier, the PartitionKey and the RowKey form a dual key.

   
   

6. Add a default constructor (this will be called upon deserialization), as well as a convenience constructor.  In the overloaded constructor we can call the base class constructor, passing the PartitionKey and the RowKey.  The base constructor simply sets those properties.  In this example I am not partitioning wines, so I set the PartitionKey to be the same for all wines.  I may address partitioning in a later post.  
   
7. If the convenience constructor is called, our entity is set up correctly and can be added to Table Storage.  If the default constructor is called, you will note that the PartitionKey is set, but the RowKey is not.  EVERY entity in TableStorage requires a PartitionKey, RowKey and TimeStamp.  The infrastructure handles the TimeStamp, so we only need to set the other properties.  It should now be clear why I didn’t use an auto-implemented property for WineID.  We need to set the RowKey in the setter.
   
8. That is it for the Wine Class.  Here is the complete code:
   

 

Create Our DataServiceContext Class

In a previous post detailing the REST API for Azure Table Storage I discussed the role of the DataServiceContext, as well as what the StorageClient’s TableStorageDataServiceContext class brought to the table.  To summarize, the DataServiceContext (part of the ADO.NET Data Services .NET Client Library) maintains state between interactions in order to support features such as identity resolution and optimistic concurrency.  The TableStorageDataServiceContext subclasses the DataServiceContext, adding functionality such as digitally signing the requests for authentication purposes.  Here we will create our TableStorageDataServiceContext:

1. Add a class named CohoContext to the AzureStore_WebRole project
2. Implement TableStorageDataServiceContext.  You will need to import the Microsoft.Samples.ServiceHosting.StorageClient namespace.
3. We now need to add a DataServiceQuery, exposing Wines, to the class.  Quoting Mike Flasko and Elisa Flasko from Expose And Consume Data in A Web Services World, “The DataServiceQuery object represents a specific query against the store defined using the URI syntax”.
   
4. That’s it for the DataServiceContext Class

 

Add Configuration Settings

We need to store the Table Storage configuration settings (our AccountName, our SharedKey used to sign the requests and the TableStorageEndpoint which is the URI to our TableStorage.  Remember that we may have multiple instances of our roles, so we store the configuration settings in the cloud service project.  Specifically, we add the configuration definitions in a csdef file, with the actual values in a cscfg.  Let’s add our settings.

1. Open the ServiceDefinition.csdef file from the AzureStore cloud service project.
2. Add a ConfigurationSettings node just below the end InputEndpoints.
3. Add 3 Settings: AccountName, AccountSharedKey and TableStorageEndpoint
   
4. Open the ServiceConfiguration.cscfg file from the AzureStore cloud service project.
5. Add the Settings with the development store values.  The development store values are the same for all machines.  Here is the full key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
   
6. We are done for now.  We will update these settings later when we create our Table Storage project in the cloud.  For now, we will work with the local development environment.

 

Create The Tables In The Development Store

The TableStorage class from the StorageClient sample has a static method named CreateTablesFromModel.  You pass it your context and your account information for authentication and it will infer a list of tables from every type in the context class that is derived from DataServiceQuery.  It will create those tables if they do not exist.  However, this does not work for development storage.  Not to worry, out friend Visual Studio knows how to do the same thing for us. 

If you didn’t know, the developer storage actually uses Sql Server to store the data locally.  Visual Studio can infer the list of tables, as well and will create the local tables.  Let’s do it:

1. Save and build your project
2. Right-Click on the cloud service project (AzureStore) and choose ‘Create Test Storage Tables’
   
3. Wait for the confirmation
4. (Optional) Open Sql Server Management Studio and look at the new database (AzureStorage) and table (Wine)
   

That is it.  We are ready to write some code, accessing the data.  Let’s get to it.

 

Build A Class To Encapsulate The Data Calls

1. Add a class named CohoDB to the AzureStore_WebRole project
2. Add GetWines, AddWine and InitializeTables static methods to the class.  We will call InitializeTables when working with the cloud storage.
   

   

     

Update Our Web Pages

Now it is time to consume our calls.  Let’s start with ViewWines.aspx.

1. Update the Page_Load with the following Code
   
2. (Optional) Format the GridView.  You can watch the screencast to see how I formatted the grid.

 

Now let’s update AddWine.aspx

1. Wire up an event handler for the SaveButton Click event
2. Implement the event handler.  Create the wine, call our AddWine method and redirect to the ViewWines.aspx page.
   

 

Test It

1. Set ViewWines as your start page and run the application (F5)
2. No wines exist so the grid will be empty
3. Click the AddWines button, add a wine and click Save
4. Repeat a few times

Here is what you should see (if you formatted the grid like me):

I fully realize that this is still somewhat ugly.  We will fix that in subsequent posts where we convert this to a Silverlight application.  The goal of this post was to introduce how to access table storage and make use of it.  The only thing we have left to do is to update the application to actually use the cloud and not the developer storage. 

 

Consume Table Storage In The Cloud

This is easier than you might think.  If you created a WIndows Azure Account, received your invitation token and redeemed it, all you need to do is to create a Storage Account.

1. Open the Azure Services Developer Portal
2. Click on Add Project
3. Click on Storage Account
   
4. Add a label, description and a name for your account.  This name must be globally unique.  Here is what you will see after you have created the project
   
5. Open the ServiceConfiguration.cscfg file from the AzureStore cloud service project.
6. Update the AccountName setting to the account name you created in step 4
7. Update the AccountSharedKey to the Primary Access Key you are given for your account
8. Update the TableStorageEndpoint to “http://table.core.windows.net/”.  DO NOT INCLUDE THE ACCOUNT NAME IN THIS SETTING.  In my case, I might be tempted to set the TableStorageEndpoint setting to “http://bagby.table.core.windows.net”, but THAT WOULD BE WRONG and I will be punished for it.

Once I have made those changes, I can test it again – Sort of.  We have to do one small thing.  Our Wine table was not created in the cloud. I need to make a call to TableStorage.CreateTablesFromModel in my code.  It is good practice to treat this method call similarly to how you treat a CREATE DATABASE call in traditional applications.  Many examples you will see will look like what you see below with the call in a Get or some other action.

While this works, it is inefficient.  I will keep it for this example, as I <insert some semi-valid excuse to hide the fact that I am lazy and this is the end of a long post>. 

Now we can access our data in the cloud.  After you have added a few wines like you did in the local storage demo, open up your favorite HTTP sniffer.  Mine is Fiddler.  Take a look at the traffic to prove to yourself that you are accessing the cloud.  Here is what it looks like for me:

 

In my next post, I will illustrate how you can expose your own custom services in Windows Azure.  Catch you soon…

Azure Application Part 1: Setup and running “Hello World”

This is part 1 in this series where I am building an Azure shopping cart application from the ground up.  In this post, I will illustrate how to setup your development environment, setup your Azure Services Developer Portal, including the process of requesting a token.  I will then build out a simple hello world example, run it in the development fabric, debug it and finally publish it to the cloud.  If you are already familiar with these topics and are already set up, please feel free to go directly to part II (if it is published).

 

Watch the Screencast

• deCast – Building an Azure App Part I: Setup and Hello World 

Setting Up Your Environment

As I mentioned, the first few posts of this series deal strictly with Windows Azure offerings (we will be working with .NET Services and Sql Data Services in later posts).  This greatly simplifies setting up our development environment.  For this post, I will limit the setup information to what is necessary for Windows Azure.  As I delve into other areas, I will provide the necessary setup info.

 

Development Environment

A great thing about working with Windows Azure is that we have a simulated environment for you for development and testing.  We simulate both the Windows Azure Fabric, as well as Windows Azure Storage on you local machine so you are able to build and test applications taking advantages of these services without deploying to or accessing the cloud.  All you need to do is to install the following:

• The Windows Azure SDK
• Visual Studio Tools

You can go here to see details about pre-requisites for the SDK, but for your convenience, I have summarized below:

• Operating System
  • (for x86 version of SDK) – 32-bit editions of Windows Vista SP1 or Windows Server 2008.
  • (for x64 version of SDK) – 64-bit edition of Windows Vista® SP1 or Windows Server® 2008
• .NET Framework 3.5 sp1
• Sql Server
  • Express 2005
  • Express 2008
  • Local Instance of 2005, 2008 – See here for more details
• Internet Information Services (IIS) 7.0 must be enabled, with ASP.NET and Windows Communication Foundation (WCF) HTTP Activation – Click here for details how to configure

The prerequisites for the Visual Studio tools include everything above plus:

• Microsoft Visual Studio 2008 SP1 or Microsoft Visual Web Developer 2008 Express Edition with SP1
• Hotfix: Native Debugging Improvements
• Hotfix: Improve Visual Studio Stability
• Hotfix: Support for FastCGI on the Development Fabric

 

Set Up Your Windows Azure Account

With your development environment set up, you have everything you need to get started developing our Azure store sample application.  However, you might want to actually deploy this code to the cloud.  For that you are going to need an Azure account.  We are currently in CTP, so there is no charge for this account (that will chance when we go to release).  You do, however, need a token.

To Request A Token:

1. Navigate to www.microsoft.com/azure.  Click on Try It Now
   
2. Click on Try It Now to register with Connect and Request a Token
   
3. Log In with your Windows Live ID (you will need to create an account if you don’t already have one)
   
4. You will then have to complete the registration information (no screenshot required)
5. Click on the connection directory tab
   
6. Scroll until you see Azure Service Invitations
   
7. You are registered and should see a page like this:
   

 

To Setup Your Azure Services Developer Portal

1. Navigate to https://lx.azure.microsoft.com
2. Log In with your live id
3. Fill in your country and lanugage and press I Agree to create a new account
   
4. You will be re-directed to a confirmation page.  Press continue
   
5. You will be redirected to a page where you can redeem your invitation token.  This token is necessary to create a Hosted Services project, as well as a Storage project.  Don’t worry about closing the page or pressing cancel.  You will be re-directed here the next time you log in.  As I annotated below, you may have to wait a bit to receive your token (i.e. don’t proceed directly to Outlook and continually press refresh until you receive it).  We are in CTP and have a limited number of tokens to hand out at any given time.
   
6. Once you have your token entered appropriately, you will no longer see this page.  You will instead be re-directed to a page in the portal where you can create a project.  Here is what you would see if you chose ‘Cancel’ on the previous page or if you click the ‘New Project’ link under the ‘Summary Tab’.
   
7. Here is the view you would see if you had entered a valid token:
   
8. You are now ready to create your Hosted Services Project.  Click on ‘Hosted Services’ to add a new Hosted Services project.
9. On the next page, enter the following information:
   • Project Label – Enter a label for your Hosted Services project.  This label will be exposed on the Azure Services Developer Portal
   • Project Description – Enter a description of the project you will be hosting

   

10. On the next page, enter a service name – a unique service / domain name to create the unique DNS name.  You can check on the availability of service names.  After you have settled on a unique service name, press the ‘Create’ button.
    
11. Your project is now created and you are ready to deploy a solution.  We will get to that later.

* You can also take a look at the How Do I: Get Started Developing with Windows Azure? and the How Do I: Deploy a Windows Azure Application? screencast for walkthroughs on getting started with Windows Azure and deploying a Windows Azure Application.

 

Creating our Cloud Project in Visual Studio

Assuming that you set up your development environment as described above, you are ready to create your Cloud project.  In this part, we are going to create a “Hello World” web application, test it on the local development fabric and deploy it to the cloud.  In part II, we will access data from Azure Table Storage.  While you can also use Visual Web Developer Express, I am going to be using Visual Studio.  Let’s get started:

 

Create the Cloud Project

1. Choose File > New > Project from the Visual Studio Menu
2. Choose Cloud Service > Web Cloud Service
   
3. That’s it!

 

What was created?

It is kind of funny how I sometimes view project templates.  I almost assign some kind of magical value to them – like they just created life – when in reality, they are just templates.  They set up project files, add appropriate code files and set up config appropriately.  Perhaps I assign the magical value in the fact that it is so hard to create a good project template.  That should change with future versions of VS.  Anyhow, I digress.  The template created 2 projects.  The goals of these projects are as follows:

A Cloud Service Project

• Allows you to build and package your cloud application to run in the local development fabric
• Allows you to debug your cloud application in the local development fabric
• Allows you to build and package your cloud application to deploy to the cloud
• Stores configuration settings that apply to all instances of each role
• Allows you to configure the number of instances to be created for each role

A Web Role

A web role in this template is really just an ASP.NET application.  We have created additional web role projects, including a Cgi Web Role which allows you to host PHP and Ruby apps.  This template, however creates an ASP.NET application.

 

Add Some Code

1. Add a label to Default.aspx, giving it an ID and setting runat=”server”.
   
2. Add some code to Default.aspx.cs that executes on the server that sets the text of the label.  It doesn’t matter what you put here, we just want to illustrate that the server is doing some work and this is not simply a static page.
    

 

Run In The Development Fabric

Run It

Press F5 or the Start Debugging button to run the application in the development fabric.  Here is the result:

What Happened

The Visual Studio tool do some nice work for you.  Here is what happens.

• Visual studio created a Windows Azure Service Package.  This is the same package that is used to deploy to the web.  However, in that instance, the package is zipped and encrypted.  When running in the local development fabric, the extension of the package is csx and if you are running with debug symbols, you will find this in the debug directory. (See this post by Jim Nakashima for more information on how the service package is created)
  
• VS ensures that development storage is started
• VS ensures that the development fabric is started and deploys your package to the fabric (CSRun is the exe that does this)
• If you are running with debug symbols, Visual Studio will attach the debugger to a role running in the development fabric

(See this documentation for more information on the development fabric)

Debug It

Set a breakpoint on our code that sets the text of the label and start with debugging.  Here is what you see:

It is that easy to debug our applications.  Please note that it is not possible to attach a debugger to instances running in the cloud.  For those situations, you need to use logging appropriately.  We will cover that in future posts.

 

Deploy Our Application To The Cloud

* This section assumes that you have created a Windows Azure account, received your token and redeemed your invitation token as detailed above.  It also assumes that you have created a Hosted Services project.  I will use the token <accountName> to represent the label for the account.

 

Remember that when we publish to the cloud, we are packaging the application in the exact same way as when we are running it in the development fabric.  The only difference is that the file is zipped and encrypted.  Oh, and it has a different extension.

Here is the process to deploy to the cloud:

1. (optional) Set the application id in the project properties from your Hosted Service Application ID
   • Copy the application id from the Hosted Service Project to the clipboard
     
   • Right-Click on the cloud services project (AzureStore) > Properties > Portal
   • Paste the application id
     
2. Right-Click on the cloud services project (AzureStore) > Publish
   
3. A browser will be launched and it will automatically navigate you to the appropriate project if you completed step 1.  Otherwise, navigate to the Hosted Service project where you want to deploy.  An explorer window also opened to the location where the cspkg (encrypted, zipped project) and the cscfg files are.
4. Click on the Deploy button under Staging
   
5. Click on the Browse buttons and navigate to the publish directory under your project.  It is the directory the explorer opened to.
   
6. Click Deploy.  This process may take a few minutes.
7. Press Run.  This process may also take a few minutes.
8. When the WebRole reads ‘Running’, you are ready to test.
9. Click on the ‘Web Site Url’ link.
   
10. That is it, you are running in the cloud!  You are in staging, but feel free to swap it to production.
    

 

In my next post, I will set up Azure Table Storage.  I will create our Wine table for the catalog, write some code to add wines and fetch wines.  I will then write some simple aspx pages to consume that code.  Lastly, I will target the cloud instead of the local development environment.  Until then…

« Previous Page — Next Page »