Understanding Windows Azure Runtime: Part I

At a high level, Windows Azure compute environment can be compared to a component container like COM+ or J2EE. Component containers are part of application servers that host the business logic in a multi-tiered environment. Business logic is modeled around individual components that live within the container. The advantage of running business components within a container is that the lifecycle of these components is efficiently managed by the container. Developers will focus on the core business logic instead of worrying about the plumbing and the overhead of managing the resources. In the J2EE world, EJBs are managed by the containers like WebLogic, WebSphere, and Glassfish etc. The contract between the components and the container is defined through a prescriptive interface. Developers are expected to implement an interface, override certain methods and finally wrap the business logic in custom methods. The interface will ensure that the container can take charge of the EJBs at runtime. These containers provide transaction scope, object pooling, memory management and remoting services and so on.

How is this related to Windows Azure? If you visualize Windows Azure compute environment as a container offering runtime management services, think of the Web Role, Worker Role and VM Role as individual components that are hosted within the component container. The relationship between the compute runtime and role instances is comparable to the relationship between the EJB container and enterprise java beans. J2EE specification enforces the definition and description of EJBs in an XML file called the Deployment Descriptor that typically lives in ejb.xml. This will instruct the container about the instantiation, transactional and pooling requirements of individual session beans and entity beans. Similar to ejb.xml, Windows Azure expects the developers to define the service model in the service configuration files. These service configuration files (.CSDEF and .CSCFG) files provide the description of the roles declaratively. Service configuration also defines the minimum number of instances that should be made available and how individual roles are interconnected. Azure Service Runtime is responsible for deciphering the configuration.

I want to introduce the terminology that Windows Azure uses for managing the roles.

• Service - The application that runs within Windows Azure is called a Service. Service implements one or more roles. A role is a specialized instance of a virtual machine (I will discuss roles in depth in part II of this article).
• Service Model - This is the logical model of the Cloud application. Service Model is a declarative mechanism to instantiate and connecting the roles with each other. This represents the network topology and physical configuration of the application.
• Service Configuration - Service Configuration is defined through ServiceDefinition.csdef and ServiceConfiguration.cscfg files. They contain the actual definition of the Service Model.
• Service Runtime - This is the environment that controls the life of individual role instances running within Windows Azure. This runtime implements the Service Model defined in the Service Configuration.
• Service Runtime API - This is an API to programmatically control the Service Runtime. Services hosted within Windows Azure will be able to interact with the runtime through this API. This provides the methods and events that offer granular control of the life cycle.
• Service Management API - This API is primarily consumed by applications outside of Windows Azure environment to interact with the Service Runtime. The Developer Portal, PoweShell Cmdlets and various third party tools rely on this API to manage and monitor services running within Windows Azure.

In the next part, we will take a closer look at the roles and their life cycle.

- Janakiram MSV, Chief Editor, CloudStory.in