[This is prerelease documentation and is subject to change in future releases.]
The architecture of a service hosted in Windows® Azure™ is based on discrete scalable components built with managed code. These components are termed roles.
A service hosted in Windows® Azure™ implements one or more roles. A service may run multiple instances of a role. Within Windows Azure, running instances of a role are replicated across multiple computers to implement all or part of the functionality of a service.
This topic contains the following subtopics:
Understanding Roles
About the Service Definition
About the Service Configuration
Understanding Roles
Windows Azure currently supports the following two types of roles:
- Web role: A web role is a Web application accessible via an HTTP and/or an HTTPS endpoint. A web role is hosted in an environment designed to support a subset of ASP.NET and Windows Communication Foundation (WCF) technologies.
- Worker role: A worker role is a background processing application. A worker role may communicate with storage services and with other Internet-based services. It does not expose any external endpoints. A worker role can read requests from a queue defined in the Queue service.
A service must include at least one role of either type, but may consist of any number of web roles or worker roles.
Role Execution
Windows Azure supports common language binaries targeted for the Any CPU platform defined by Microsoft .NET Framework 3.5 SP1. The roles that comprise a service execute in this environment.
Windows Azure enforces certain restrictions at runtime by using a combination of code access security and Windows NT security policies. Developers who are designing hosted services must take into account these additional restrictions.
Role Network Communication
All roles can make outbound connections to Internet resources via HTTP or HTTPS and via Microsoft .NET APIs for TCP/IP sockets. Only web roles may listen for incoming requests over HTTP and/or HTTPS. In a service containing more than one web role, each web role must listen on a unique HTTP and/or HTTPS port.
All roles may access storage services via the REST APIs.
Windows Azure SDK Runtime API
Roles have access to the following resources via the Windows Azure SDK runtime API:
-
Optional local storage available for caching needs
-
Standard event streams for logging and for raising alerts to service operators
-
Interfaces for reporting application health to the fabric
About the Service Definition
The shape of a service is determined by the service definition file. The service definition file indicates whether a service implements a web role, a worker role, or both types. For a web role, the service definition file specifies whether it exposes an HTTP endpoint or an HTTPS endpoint, or both. It also may establish configuration parameters for the service and define a local storage resource for caching purposes.
The service definition can't be changed while the service is running in Windows Azure. To change the shape of a service, you must republish the service.
The service definition file has a default extension of .csdef. It is packaged with the role binaries when the service is packaged for publication.
The following diagram shows the possible shapes for a service, as determined by the service definition file.
.gif)
About the Service Configuration
The service configuration file sets values for the service that can be configured while the service is running in the fabric. The values you can specify in the service configuration file include the number of instances that you wish to deploy for each role, and the values for the configuration parameters that you established in the service definition file.
The service configuration file has a default extension of .cscfg. The service configuration file is not packaged with the service, but is uploaded to the Windows Azure fabric as a separate file. You can upload a new service configuration file without republishing your service.
The following diagram shows a published service running multiple instances of a web role and a worker role.
.gif)
About the Service Package
The service package is the file that packages your role binaries and service definition file to be published to the Windows Azure fabric. You can package your service by using the CSPack Command-Line Tool.
After you have packaged your service, you can upload the service package file, together with the service configuration file, to the Windows Azure fabric by using the Azure Services Developer Portal.
See Also