Build an Application that Runs in a Cloud Service in Azure

Build an Application that Runs in a Cloud Service in Azure

Updated: October 24, 2014

An application designed to be a cloud service in Windows Azure consists of different computational resources that collectively process information and interact with each other and the external world. A cloud service in Windows Azure can contain up to five of the following role definitions:

  • Web Role – A service component that is customized for web application programming as supported by Internet Information Services (IIS) 7 and ASP.NET. The web role is intended to serve as the front-end to your cloud service.

  • Worker Role – A service component that is useful for generalized development, and may perform background processing for a web role. A worker role is frequently used for long-running tasks that are non-interactive, but you can host any type of workload.

You can use the following information to understand the use of roles in an application:

In Windows Azure, the web role contains websites or other code that are supported by Internet Information Services (IIS). Typically this is an ASPX page or a web service, but you can use other web development tools such as a hypertext preprocessor (PHP) to provide your services. An ASP.NET web role in Windows Azure is similar to an ASP.NET web application in that it is built with .aspx files and source code, but it includes additional tools that allow it to run in the Windows Azure environment. For more information on ASP.NET web projects, see ASP.NET Web Projects.

A web role can also host most other applications that use the HTTP protocol, such as a WCF service by using the basicHttpBinding schema. For more information, see basicHttpBinding. Windows Azure Tools for Microsoft Visual Studio provide templates to simplify creating applications that fit these scenarios. To download these tools, see Windows Azure Downloads.

The primary difference between a web role and a worker role is support for IIS. The web role is tooled to present an interface through IIS hosted websites and web applications. In contrast, the worker role is flexible and open ended. Most types of applications can be hosted in a worker role, including those that use non .NET languages or run unmanaged code.

Some of the differences are:

  • The web role provides support for presenting a user facing frontend through IIS. While you can write code to present a user interface using a worker role, the web role makes creating this type of application easier.

  • In the web role, IIS handles the efficiency of threading. In the worker role you must handle threading issues yourself.

  • You must provide a run method that is called to initiate processing.

  • The security perimeter is different between the web and worker role. In the web role the access control lists (ACLs) for certificates are set to support IIS and network services by default. When using a worker role you must set the ACLs to support the permissions your application requires.

The types of tasks a worker role is typically used are:

  • Long running tasks that are asynchronous that the user does not have to wait for.

  • To host application services that do not require a user interface.

  • Background services listening to a queue.

  • Running TCP based services.

  • Compute intensive jobs.

In the Windows Azure SDK, web roles access the full power of IIS. When you create an application for Windows Azure, it is configured to use the full capabilities of IIS. For additional information about web roles and IIS, see Configure a Web Server to Serve Content (IIS 7.0).

Web roles include:

  • Support for multiple websites and applications in a single web role instance. For more information on configuring your web role to host multiple sites, see Configure a Web Role for Multiple Web Sites.

  • Scripting of start-up configuration tasks. For more information on start-up tasks, see Configure IIS Components in Azure.

  • Running websites and applications directly under IIS.

  • Using application domains in the standard IIS manner.

You can manage how your role responds when it is started, running, or stopped in Windows Azure by using the following information:

The RoleEntryPoint class includes methods that are called by Windows Azure when it starts, runs, or stops a web or worker role. You can optionally override these methods to manage role initialization, role shutdown sequences, or the execution thread of the role. A worker role must extend the RoleEntryPoint class. For web roles, extending RoleEntryPoint is optional.

When extending RoleEntryPoint, you should be aware of the following behaviors of the methods:

  • The OnStart and OnStop methods return a boolean value, so it is possible to return false from these methods.

    If your code returns false, the role process is abruptly terminated, without running any shutdown sequence you may have in place. In general, you should avoid returning false from the OnStart method.

  • Any uncaught exception within an overload of a RoleEntryPoint method is treated as an unhandled exception.

    If an exception occurs within one of the lifecycle methods, Windows Azure will raise the UnhandledException event, and then the process is terminated. After your role has been taken offline, it will be restarted by Windows Azure. When an unhandled exception occurs, the Stopping event is not raised, and the OnStop method is not called.

If your role does not start, or is recycling between the initializing, busy, and stopping states, your code may be throwing an unhandled exception within one of the lifecycle events each time the role restarts. In this case, use the UnhandledException event to determine the cause of the exception and handle it appropriately. Your role may also be returning from the Run method, which causes the role to restart. For more information about deployment states, see Common Issues Which Cause Roles to Recycle.

If you are using the Windows Azure Tools for Microsoft Visual Studio to develop your application, the role project templates automatically extend the RoleEntryPoint class for you, in the WebRole.cs and WorkerRole.cs files.

You can affect the lifecycle of a role by using the following methods of the RoleEntryPoint class:

The OnStart method is called when your role instance is brought online by Windows Azure. While the OnStart code is executing, the role instance is marked as Busy and no external traffic will be directed to it by the load balancer. You can override this method to perform initialization work, such as implementing event handlers and starting Windows Azure Diagnostics. For more information about diagnostics, see Collect Logging Data by Using Azure Diagnostics.

If OnStart returns true, the instance is successfully initialized and Windows Azure calls the RoleEntryPoint.Run method. If OnStart returns false, the role terminates immediately, without executing any planned shutdown sequences.

The following code example shows how to override the OnStart method. This method configures and starts a diagnostic monitor when the role instance starts and sets up a transfer of logging data to a storage account:

public override bool OnStart()
    var config = DiagnosticMonitor.GetDefaultInitialConfiguration();

    config.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter = LogLevel.Error;
    config.DiagnosticInfrastructureLogs.ScheduledTransferPeriod = TimeSpan.FromMinutes(5);

    DiagnosticMonitor.Start("DiagnosticsConnectionString", config);

    return base.OnStart();

The OnStop method is called after a role instance has been taken offline by Windows Azure and before the process exits. You can override this method to call code required for your role instance to cleanly shut down.

Code running in the OnStop method has a limited time to finish when it is called for reasons other than a user-initiated shutdown. After this time elapses, the process is terminated, so you must make sure that code in the OnStop method can run quickly or tolerates not running to completion. The OnStop method is called after the Stopping event is raised.

You can override the Run method to implement a long-running thread for your role instance.

Overriding the Run method is not required; the default implementation starts a thread that sleeps forever. If you do override the Run method, your code should block indefinitely. If the Run method returns, the role is automatically gracefully recycled; in other words, Windows Azure raises the Stopping event and calls the OnStop method so that your shutdown sequences may be executed before the role is taken offline.

You can use the ASP.NET lifecycle methods, in addition to those provided by the RoleEntryPoint class, to manage initialization and shutdown sequences for a web role. This may be useful for compatibility purposes if you are porting an existing ASP.NET application to Windows Azure. The ASP.NET lifecycle methods are called from within the RoleEntryPoint methods. The Application_Start method is called after the RoleEntryPoint.OnStart method finishes. The Application_End method is called before the RoleEntryPoint.OnStop method is called.

One of the most common application patterns in Windows Azure is for a web role to receive incoming requests and then use Windows Azure queues to pass them to instances of a worker role to process. The worker role periodically looks in the queue for messages to see if there is any work to do. If there is, it performs the task. The web role typically retrieves completed work from persistent storage, such as a blob or a table. The following diagram shows this typical design pattern.

Roles communicate through queues

For more information about using storage services, see Azure Storage.

© 2015 Microsoft