Understanding Web Roles and Web Configuration

A key concept in Windows Azure development is the role, which is typically a single component running in the Azure environment and built in managed code. Roles can be of two types: web roles and worker roles. A Web role is generally an ASP.NET Web application, like the case of our sample scenario. As you may remember from Figure 40.2, additional Web roles are available for WCF and FastCGI applications. You may instead think of worker roles as of services running behind the scenes, like in the case of Windows services, in the cloud. An Azure project can have multiple roles and multiple instances of one role; moreover, you can configure roles as required. When you create new Cloud projects, the new solution will contain a Web role project (simply an ASP.NET Web project) and a service project where you can configure role properties. To access roles configuration, in Solution Explorer right-click the WebRole1 role and select Properties. At this point a special implementation of the My Project designer will pop up. Figure 40.3 shows what you will see on the screen.

Figure 40.3 Accessing role configuration options.

The Configuration tab enables first setting the .NET trust level for roles. By default the trust level is Full Trust. The Windows Azure partial trust level has instead some limitations and denies your role access to some resources, such as the Registry, isolated storage, printing, and OleDb connections. The full restrictions list is available here: http://msdn.microsoft.com/en-us/library/dd573355.aspx. The Instance Count field enables setting how many instances of the role are permitted, whereas VM Size enables specifying the size of the virtual machine hosting your service. Small means one CPU core, 1.7 gigabytes of memory, and 250 gigabytes of hard disk space. Medium means two CPU cores, 3.5 gigabytes of memory, and 500 gigabytes of hard disk space. Large means four CPU cores, 7 gigabytes of memory, and 1 terabyte of hard disk space; finally, ExtraLarge means eight CPU cores, 15 gigabytes of memory, and 2 terabytes of hard disk space. The Startup action group enables specifying if debugging should be launched via an HTTP or and HTTPS endpoint (which must be defined in the Endpoints tab). In the Settings tab you can define settings that you can access via the Windows Azure SDK Runtime API. By default each role has a DiagnosticsConnectionString that defines whether you need access to the local storage or the online services. In the Endpoints tab you can define endpoints for your application. Deciding to apply for an HTTPS endpoint also requires a valid SSL certificate. You add certificates to your deployment via the Certificates tab. Finally, the Local Storage tab enables configuring the file system storage resources local for each instance. All the preceding options and settings are reflected into the ServiceConfiguration.cscfg and ServiceDefinition.csdef files that you can see in Solution Explorer and that are basically XML representations of settings.

The default role for the new project is associated with the ASP.NET project that will actually run the application. You can therefore build your application directly within the Web project or add a Silverlight project, as explained in next section.