The role of the web
In Azure, a web role is an HTTP
or HTTPS endpoint, and so a web role can include both front-end websites
as well as web services. Web roles can also make outbound connections
to web services via HTTP.
Web roles can access Azure
storage services (queue, blob, or table) via either the REST API or
Windows Azure Storage Client Library, and can also connect to SQL Azure.
Azure uses IIS7 and supports FastCGI for interpreted languages such as
PHP or native code. Azure supports additional IIS modules such as the
URL rewrite module.
Web roles can be an important
way to collect or distribute information. Information can be supplied or
collected via web services, or users can access websites to perform any
number of functions.
With a few small
differences, web development using Azure is nearly identical to standard
web development. Microsoft is making a concerted effort to support a
number of platforms and languages. In our example, we'll use Visual
Studio 2008 and VB.NET, but SDKs have been developed for PHP/Eclipse and
Ruby.
At this point, our example web
role is simply a web form to upload a picture of the production
progress on our RV. In this article, we're going to develop the web
form. We'll be using the local development fabric and a local SQL
Server, and we'll discuss SQL Azure connections when we deploy our
application.
Web roles, déjà vu, and ASP.NET
If you've ever travelled to a
new place but felt like you've been there before, then you'll be
prepared for Azure development. Most components between the web role and
the ASP.NET web application are the same .aspx pages, classes, web.config, among other things. New components to our web role include three new assembly references, a WebRole.vb (or WebRole.cs) file, and a trace listener addition in the Web.config file.
The new assembly references are:
Microsoft.WindowsAzure.Diagnostics, which contains the diagnostics and logging classes
Microsoft.WindowsAzure.ServiceRuntime, which allows the recycling of roles and also allows access to configuration settings
Microsoft.WindowsAzure.StorageClient, which is the library for the Blob, Table, and Queue Storage REST interfaces
These three assemblies are referenced in addition to the other references we need in our application.
The new WebRole.vb (or WebRole.cs) file is just some template code for setting up the logging and diagnostics (VB code shown in further section).
Creating the solution and web role project
Now that we've discussed
how similar Azure and ASP.NET development are, we need to start with
something slightly different. In order to develop using Azure, we need
to have the SDK and Visual Studio tools installed.
These tools add new project and item templates that we need to use in
Visual Studio.
To create our Azure project, open Visual Studio, start a new project, open the language (in our case, Visual Basic) and select Cloud. Under Templates, choose a Windows Azure Cloud Service and give a suitable name to the project.
Once the solution and project is created by Visual Studio, we are
prompted to add roles to our project. At this time, we only need to add a
single web role to our project.
Our new project now looks like this:
One of the new project components needed for Azure development is WebRole.vb. This file is automatically created when our web role was created, and contains the following boilerplate code:
Imports Microsoft.WindowsAzure.Diagnostics
Imports Microsoft.WindowsAzure.ServiceRuntime
Public Class WebRole
Inherits RoleEntryPoint
Public Overrides Function OnStart() As Boolean
DiagnosticMonitor.Start("DiagnosticsConnectionString")
' For information on handling configuration changes
' see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.
AddHandler RoleEnvironment.Changing, AddressOf RoleEnvironmentChanging
Return MyBase.OnStart()
End Function
Private Sub RoleEnvironmentChanging(ByVal sender As Object, ByVal e As RoleEnvironmentChangingEventArgs)
' If a configuration setting is changing
If (e.Changes.Any(Function(change) TypeOf change Is RoleEnvironmentConfigurationSettingChange)) Then' Set e.Cancel to true to restart this role instance
e.Cancel = True
End If
End Sub
End Class
Application diagnostics and logging in the cloud
Think of how we currently log
our events and diagnostics. We have IIS logs and application logs to
help us see things in the event of something not working. These logs
live on our physical servers, and we can access them anytime we need.
Now, think of how our application lives in Windows Azure. We don't have
any physical machines to save logs or any control of IIS. How are we
going to store our logs for debugging problems?
Fortunately, even Microsoft
had to confront this problem and it came up with an appropriate answer.
First, we need to ensure our application has a trace listener enabled; a trace listener is a link between our application and Azure's diagnostic tools. We need to confirm the following code is present in the web.config file:
<system.diagnostics>
<trace>
<listeners>
<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics">
<filter type="" />
</add>
</listeners>
</trace>
</system.diagnostics>
We don't have access to logs on physical servers, but then what do we
have? When developing locally in our development fabric, we can see
everything in the Development Fabric UI. To achieve this, run the
application in debug mode and we will see that our development fabric
starts (in Windows 7, we may need to enable the permission to "run as
administrator" for the development fabric to start). Right-click on the
fabric icon in the notifications area of your taskbar, and select the Show Development Fabric UI option as shown in the next screenshot:
This will open up the
Development Fabric UI. From here, we can drill down into our web role
instance to see everything we have set to log.
This is great news for
local development, but what about logging in the cloud? Because we don't
have our physical machines to store our logs on, and we don't have a
Production Fabric UI, then what do we have? Well, the answer is we have
Windows Azure Storage at our fingertips. Not only did Microsoft give us a
way to keep this information in Windows Azure Storage, but they also
built a nice way to log information in our code.
Specific information needs to be
kept in a particular type of storage, whether it is Blob or Table
Storage. The following is the correct storage type for each log:
Blob Storage: IIS7 logs, Failed Request logs, Crash Dumps, and Custom Error logs
Table Storage: Windows Azure logs, Windows Diagnostic infrastructure logs, Windows Event logs, and Performance Counters
At this point, our application
doesn't include any logging. We're still developing locally, so we have
the UI to debug. Before an application is released into the production
cloud, it would be wise to add some type of logging and diagnostics.