Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Azure

Microsoft : Azure Enterprise Application Development : Web Role

6/21/2011 4:53:05 PM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

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. 

Other -----------------
- Microsoft Azure: Enterprise Application Development - Worker Roles
- Working with Data in the Surveys Application : Saving Survey Response Data
- Working with Data in the Surveys Application : Testing and Windows Azure Storage
- Working with Data in the Surveys Application : A Data Model for a Multi-Tenant Application
- Enterprise Application Development : Azure Monitoring and Diagnostics
- Enterprise Application Development : Azure Diagnostics­ under the hood & Enabling diagnostic logging
- Building a Scalable, Multi-Tenant Application for Windows Azure : Scaling the Surveys Application
- Building a Scalable, Multi-Tenant Application for Windows Azure : Scaling Applications by Using Worker Roles
- Building a Scalable, Multi-Tenant Application for Windows Azure : On-Boarding for Trials and New Customers
- Introduction to SQL Azure : Creating our database
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server