Updated: June 7, 2012
A cloud service in Azure consists of an application that is designed to run in the cloud service and XML configuration files that define how the cloud service should run.
The service model is determined by the settings listed in the ServiceDefinition.csdef file and configured in the ServiceConfiguration.cscfg file. The definition file is packaged with the role binaries when the application is prepared for deployment. The ServiceConfiguration.cscfg file is deployed with the package and is used by Azure to determine how the application should run.
By defining settings in the ServiceDefinition.csdef file, you can define the roles and resources for an application. An application that runs as a cloud service in Azure implements one or more instances of the available role types. Within Azure, running instances of a role are replicated across multiple computers to implement all or part of the functionality of the cloud service.
Before you start creating an application to run in Azure, you should review the information listed in Planning and Designing Azure Applications.
Azure currently supports the following types of roles:
Web role – A web role is a role that is customized for web application programming as supported by IIS 7 and ASP.NET. The benefit of using this type of role is that the IIS setup is done for you. This role is best used for providing a web based frontend for your cloud service. It is not suited for long running processes.
Worker role – A worker role is a role that is useful for generalized development, and may perform background processing for a web role. When you have a need for a background process that performs long running or intermittent tasks, you should use this role.
After you create a cloud service that is running your application, you can remotely access a role instance to configure settings in the virtual machine or troubleshoot issues. To do this, you must ensure that you upload the appropriate certificate to the Azure Management Portal, encrypt the password that is used, and add Import elements for the RemoteAccess and RemoteForwarder modules into the ServiceDefinition.csdef file.
The role instances in a cloud service communicate through internal and external connections that vary depending on the type of communication that is needed. Role instances can make these connections by using HTTP, HTTPS and Microsoft .NET APIs for TCP/IP sockets. An external connection is called an input endpoint, and an internal connection is called an internal endpoint. Endpoints are associated with ports, where the external endpoint is associated to a port that you define, and the internal endpoints are dynamically assigned ports by Azure.
You can use startup tasks to perform operations before the role instances start. Operations that you might want to perform include installing a component, registering COM components, setting registry keys, or starting a long running process. You add startup tasks to the role by defining the tasks in the ServiceDefinition.csdef file.
The RoleEntryPoint class includes methods that are called by 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. For a VM role, Windows Services are used instead of the RoleEntryPoint class.