The Windows Azure Platform consists of three main components – Windows Azure, SQL Azure, and .AppFabric. Figure 2-1 shows a simple illustration of the four Windows Azure platform components.

Figure 2.1. The Windows Azure platform

The Windows Azure Operating System

Windows Azure is the underlying operating system for running your cloud services on the Windows Azure platform. Microsoft brands Windows Azure as the Operating System in the cloud, because it provides all the necessary features for hosting your services in the cloud. It provides a runtime environment that includes a web server, computational services, basic storage, queues, management services, and load-balancers. Windows Azure also provides developers with a local development fabric for building and testing services before they are deployed to Windows Azure in the cloud. Figure 2-2 illustrates the three core services of Windows Azure.

Figure 2.2. Windows Azure core services

The three core services of Windows Azure are as follows:

• Compute: The compute service offers scalable hosting of services on 64-bit Windows Server 2008 platform with Hyper-V support. The platform is virtualized and designed to scale dynamically based on demand. The platform runs Internet Information Server (IIS) version 7 enabled for ASP.NET Web applications. At the time of this writing, the underlying Windows operating system and other infrastructure components like IIS are not available directly to developers. The abstraction is at the operating system layer. Developers can write managed and unmanaged services for hosting in the Windows Azure Compute cloud without worrying about the underlying operating systems infrastructure.

• Storage: There are three types of storage supported in Windows Azure: tables, blobs, and queues. I will cover these storage types later in the book in detail. These storage types support REST-based direct access through REST APIs. Windows Azure tables are not traditional relational database tables like SQL Server tables. Instead, they provide structured data storage capabilities. They have independent data model popularly known as the entity model. Tables are designed for storing terabytes of highly available data like user profiles in a high-volume ecommerce site. Windows Azure blobs are designed to store large sets of binary data like videos, images, and music in the cloud. The maximum allowable size per blob item is 50GB. Windows Azure queues are the asynchronous communication channels for connecting between services and applications not only in Windows Azure but also from on-premise applications. You can also use queues to communicate across multiple Windows Azure role instances. The queue infrastructure is designed to support unlimited number of messages, but the maximum size of each message cannot exceed 8KB. Any account with access to storage can access tables, blobs, and queues.

• Management: The management service supports automated infrastructure and service management capabilities to Windows Azure cloud services. These capabilities include automatic commissioning of virtual machines and deploying services in them, as well as configuring switches, access routers, and load balancers for maintaining the user defined state of the service. The management services consist of a fabric controller responsible for maintaining the health of the service. The fabric controller abstracts the underlying virtualized platform infrastructure from the compute and storage services. The fabric controller supports dynamic upgrade of services without incurring any downtime or degradation. Windows Azure management service also supports custom logging and tracing and service usage monitoring.

SQL Azure

SQL Azure is the relational database in the Windows Azure platform. It provides core relational database management system (RDBMS) capabilities as a service, and it is built on the core SQL Server product code base. In the current version (CTP), developers can access SQL Azure using tabular data stream (TDS), which is the standard mechanism for accessing on-premise SQL Server instances through SQL client today. The SQL client can be any client, like ADO.NET, LINQ, ODBC, JDBC, ADO.NET Entity Framework, or ADO.NET Data Services.

Note

ADO.NET Data Services is an independent framework for accessing web-based data services. It can be used not only for consuming web-based data services but also for on-premise data services like SQL Server 2008. For more information on ADO.NET Data Services, please visit the MSDN site http://msdn.microsoft.com/en-us/data/bb931106.aspx.

Figure 2-3 illustrates the core components of SQL Azure.

Figure 2.3. SQL Azure core components

The core services offered by SQL Azure are as follows:

• Relational Data Storage: The relational data storage engine is the backbone of the SQL Azure and is based on the core SQL Server code base. This component exposes the traditional SQL Server capabilities like the tables, indexes, views, stored procedures, and triggers.

• Data Sync: The Data Sync capabilities provide the synchronization and aggregation of data to and from SQL Azure to enterprise, workstations, partners and consumers devices using the Microsoft Sync Framework.

  Note

  The Microsoft Sync Framework is included in the SQL Server 2008 product (http://msdn.microsoft.com/en-us/sync/default.aspx).

• Management: The management component provides automatic provisioning, metering, billing, load-balancing, failover and security capabilities to SQL Azure. Depending on the SLA, each database is replicated to one primary and two secondary servers. In case of a failover, the switching between the primary and the secondary server is automatic without interruptions.

• Data Access: The Data Access component defines different methods of accessing SQL Azure programmatically. Currently, SQL Azure will support Tabular Data Stream (TDS), which includes ADO.NET, Entity Framework, ADO.NET Data Services, ODBC, JDBC, and LINQ clients. Developers can access SQL Azure either directly from on-premise applications or through cloud services deployed in Windows Azure. You can also locate a Windows Azure compute cluster and a SQL Azure instance together for faster data access. I will discuss SQL Azure in detail later in this book.

.NET Services

.NET Services is the middleware engine of Windows Azure platform providing access control service and service bus.

Note

Later Microsoft may enable Workflow services, which was part of the original AppFabric offering but was discontinued to align it with the Windows Workflow 4.0 release. In this book, I will not cover Workflow Services because its future was uncertain at the time of this writing.

AppFabrichas a service-oriented architecture and allows the creation of federated access control and distributed messaging across clouds and enterprises. I consider AppFabricto be the integration backbone of the Windows Azure platform, because it provides connectivity and messaging capabilities among distributed applications. It also provides capabilities for integrating applications and business processes not only between cloud services but also between cloud services and on-premise applications.

AppFabricalso provides a development environment integrated into Visual Studio .NET 2008 SP1 and beyond. Developers can build WCF-like services in Visual Studio .NET and publish endpoints to the cloud from within Visual Studio .NET design environment. Figure 2-4 illustrates the two core services of .NET Services.

Figure 2.4. AppFabriccore services

The two core services of AppFabricare as follows:

• Access Control: The access control component provides rules-driven, claims-based access control for distributed applications. You could define claims-based rules and authorization roles in the cloud for accessing on-premise as well as cloud services.

• Service bus: The service bus is a generic .NET Internet service bus. It is analogous to the Enterprise Service Bus (ESB) popularly seen in large enterprises. Unlike the ESB, the AppFabricServiceBus is designed for Internet scale and messaging with cross-enterprise and cross-cloud scenarios in mind. The service bus provides key messaging patterns like publish/subscribe, point-to-point, and queues for message exchanges across distributed applications in the cloud as well as on-premise.

I will discuss AppFabricin detail later in this book.

Live Services

Microsoft Live Services is a collection of consumer centric applications and frameworks like Identity Management, Search, Geospatial, Communications, Storage, and Synchronization. Live Services and Live Framework are commonly confused for each other. Live Framework is a unified development model for building applications for Live Services. Live Framework provides the capabilities of building synchronization applications called the Mesh Applications for synchronizing data across multiple desktops and mobile devices seamlessly.

Live Framework also provides a local development environment integrated into Visual Studio .Net and a local runtime environment for on-premise development and testing. Figure 2-5 illustrates the core components of Live Services.

Figure 2.5. Live Services core components

The core components of Live Services are as follows:

• Mesh services: Mesh services provide programmatic access to users, devices, applications and the data synchronization across them.

  • The users service provides management and sharing of resources across devices and other users.

  • The devices service provides management, access, sharing and security of user devices across the Internet.

  • The applications service provides deployment, configuration, versioning and access control to applications across the Live mesh.

  • The data sync service provides synchronization of data and metadata across multiple devices, applications and the Live mesh cloud.

• Identity services: the identity service provides identity management and delegated authentication across the Live Services. E.g. Windows Live Identity Provider.

• Directory Services: The Directory Services manages the relationships and the graphs of the Users, Identities, Devices, Applications and their connected network. E.g. Relationship between users and devices in Live Mesh.

• Storage: The Storage service manages the storage of transient and persistent data for the Users, Devices and Applications in the Mesh. E.g. Windows Live Skydrive and Live Mesh storage

• Communications & Presence: The Communication and Presence service provides the communications infrastructure between devices and applications, and manages their presence information for connections and display, for example, Windows Live Messenger and Notifications API.

• Search: The Search Service provides search capabilities for users, web sites and applications, for example, Bing.

• Geospatial: The Geospatial Service provides rich geo-mapping, location, routing, search, geocoding and reverse geocoding services to web sites and applications, for example, Bing Maps (or Virtual Earth).

• Live Framework: Live Framework is a uniform model of programming Live Services across platforms, programming languages and devices. The three core components of the Live Framework are:

  • Live Operating Environment (LOE): The LOE is the uniform runtime environment for Live Services objects in the cloud as well as in the local device environment. Developers can connect to the LOE in the cloud or on the local device. LOE gives offline operational capabilities to the Live Mesh. LOE also enables Live Mesh to synchronize offline operational data with the cloud LOE and other devices.

  • Resource Model: The Live Framework resource model exposes the LOE resource objects like Data, Applications, Communications, Mesh and Identities via open protocols and formats like HTTP, XML, ATOM and RSS. You can use any programming language supporting these protocols to access LOE resources.

  • Live Programming Model: The Live Programming Model provides a common programming model from JavaScript, Silverlight and .NET programming languages. You can build Client, Web and Rich Internet Applications using any of the above mentioned programming languages and deploy them in the Live Mesh. The Live Programming Model provides a uniform resource model across Live Services and exposes these services as REST (Representational State Transfer) resources. The Live Programming model supports open protocols and formats like HTTP, XML, ATOM and RSS for accessing Live Services.

I will discuss Live Services and Live Framework in detail later in this book.

In Scenario 1, the developer develops cloud services for Windows Azure, .NET Services, SQL Azure and Live Services on a local development environment and then tests these applications in the local development fabric before deploying them to the Windows Azure platform. The Windows Azure environment can host web as well as background process applications (called Worker) that can communicate with .NET Services, SQL Azure or Live Services depending on the business requirements of the application. Developers can also build services directly targeting each individual Windows Azure platform component. Once the services are deployed in their respective environments in the cloud, enterprises and consumers can start using them. The typical development cycle consists of designing, developing and testing the application in the local development fabric before it is deployed into a cloud staging environment. After testing the application in the cloud staging environment, it is deployed to the cloud production environment for end users to start using it.

In the Figure 2-6, Enterprise B is a payroll processing company that processes paychecks for Enterprise A. Enterprise A needs to send employee information to Enterprise B for payment processing on a periodic basis. After payment processing, Enterprise B needs to send a consolidated payment report to Enterprise A for accounting purposes. What I want to illustrate here is that there is a two-way financial relationship between the two enterprises and automated data exchange between both the enterprises is a business requirement. Traditionally, to achieve this, the IT departments from both the enterprises would have had to open up Firewall ports for transferring data back and forth from both the enterprises, and create a trust relationship between the directory domains in both the enterprises so the users from one enterprise are recognized in the other.

In the Windows Azure platform, you could achieve this by following these steps:

Enterprise B is a payroll processing company that processes payroll calculations and reporting for more than 500 companies. Enterprise B has to generate consolidated payroll reports for all the 500 organizations at the same time, because the payroll date is the same for all the enterprises. After the payroll is processed, Enterprise B has to electronically send the reports to its customers the following day, due to compliance reasons. As Enterprise B is growing, it is not able to keep up with the computing capacity it needs to process reports for all the 500 organizations in a single day. So, Enterprise B decides to offload report processing to the Windows Azure platform by synchronizing the on-premise SQL Server database with SQL Azure, and running the report processing application on Windows Azure platform. Enterprise B can now scale the report processing application within the cloud, in proportion to the company's growth. Thus, Enterprise B has successfully offloaded a processor intensive application to the Windows Azure platform without worrying about its on-premise infrastructure and processing capacity.

In the fourth scenario, you have a role to play. Assume that in the past decade, the number of devices you and your family owns has increased to seven: one personal computer, three smart phones, and three laptops. Out of these, two laptops are owned by the company you work for.

One day, you decide to write a book on Windows Azure platform, and your company permits you to dedicate 10–15% of your daily time to writing the book. The challenge you are facing is sharing your writings between the enterprise PC at work and home laptop. You also want the ability to write your chapters from the garden next to your house on a perfectly sunny day. You need seamless access to your documents across multiple devices and locations.

You install Live Mesh on all your devices and pick and choose the files that you want to synchronize across them. Now, when you work on the chapters at home, they are automatically synchronized on your work computer. The next day, when you go to work, your work machine is up to date with the new content, and you can start working on the book at work. You can also work on your files from the garden with no network connectivity. When you return home and connect your laptop, Live Mesh automatically synchronizes the documents across all the selected devices for you. Thus, by using Live Mesh, you have created a seamless synchronization network among your own devices for sharing not only documents, but also other artifacts like photos, videos, and files.

The types of developers that may be interested in developing Windows Azure applications follow:

Understanding the following technologies and concepts are the primary skills required for developing with Windows Azure:

Essentially, any proficient .NET developer should be able to develop Windows Azure services comfortably. This book assumes that you are comfortable programming in C# using Visual Studio .Net and .NET Framework. Even though all the examples in this book are written in C#, they could easily be ported to any programming language supported by the .NET Framework.

The Windows Azure developer portal is the primary location for developers interested in developing Windows Azure application. You navigate across all the Windows Azure platform components from the portal and then manage your Windows Azure deployments from the web page. Once you sign in with your account, you will be redirected to the Windows Azure developer portal. Figure 2-8 illustrates the Windows Azure developer portal landing page (Summary section).

Figure 2.8. The Windows Azure developer portal

In the Windows Azure developer portal, there are three top-level navigation options—Summary, Account, and Help. In the Summary page, as shown in Figure 2-8, you can view the list of existing projects that you can administer. If you have not created any projects or are visting the site for the first time, the projects list will be empty. Click one of the listed projects to go to the Windows Azure services list, shown in Figure 2-9.

Figure 2.9. Windows Azure services list

Click the New Service link to go to the Create a New Service page shown in Figure 2-10.

Figure 2.10. The Create New Service page in the Windows Azure developer portal

In Figure 2-10, you can create two types of services: Storage Account and Hosted Services Project. I will cover these project types in details in later chapters. You can assume for now that this page is used for creating Windows Azure cloud services. In Figure 2-9, I already have three services created: ProAzure, ProAzure NW Storage, and ProAzureStorage. As the name suggests, ProAzure NW Storage and ProAzure Storage are storage accounts. The ProAzure project is a compute project for hosting web applications and background processing applications. You can click any of the services to go to its respective management page. Figure 2-11 shows the management page for the ProAzureStorage service.

Figure 2.11. The ProAzureStorage management page

The storage service does not run user-specific applications; instead, it provides URL access points to its storage infrastructure. The storage service management page lists the URL endpoints for the blob, queue, and table services. The page also lists the access keys for securely accessing the storage service and the affinity of the storage service towards a particular geolocation. Figure 2-12 shows the management page for the ProAzure compute service.

Figure 2.12. ProAzure management page

Unlike storage service, the compute service actually runs your applications, so the management page provides upgrade, run, configure, and delete operations on your compute service. In the preceding example, I have four different roles deployed in production. The numbers next to each role indicate the number of instances of each role. The Web Site URL http://proazure.cloudapp.net is the URL of the web application deployed in this service. The service will run only after I click the Run button. On the compute service management page, you have the option of running your application either in the staging environment or the production environment.

Figure 2-13 shows the staging and production environments management page.

Figure 2.13. Staging and production environment management

The staging environment has nothing deployed, because it was swapped to production during the latest release. In any case, it is always a best practice to first test your cloud service in staging before promoting it to production. The Deploy button takes you to the staging deployment page as shown in Figure 2-14.

Figure 2.14. The Staging Deployment page

From the deployment page, you can upload your cloud service application package and its associated configuration file. The number of roles and their instances are all contained in the cloud service application package. Later in this chapter, you will build a simple cloud service package for Windows Azure.

Figure 2-15 shows the contents of the Account page of the Windows Azure developer portal.

Figure 2.15. Windows Azure developer portal Account page

The Account page is generally used for managing account-related information like the invitation tokes received from Microsoft, X.509 API certificates for the Windows Azure Service Management API, and affinity groups for geolocating your services in Windows Azure.

Figure 2-16 illustrates contents of the Help page of the Windows Azure developer portal.

Figure 2.16. Windows Azure developer portal Help page

The Help page is a resource page and provides links to software development kits, Windows Azure product blogs, and articles about Windows Azure. The Help page is also the primary feedback page where users can enter product feedback through forums.

To navigate to the AppFabricdeveloper portal, click on the AppFabriclink on the Windows Azure portal. The AppFabricsubscription is included in Windows Azure subscription at the time of this writing. The AppFabriclanding page lists the AppFabricsolutions and links to AppFabricSDK, MSDN resources, and forums, as shown in Figure 2-17.

Figure 2.17. AppFabricLanding Page

From the AppFabriclanding page, you can add AppFabricsolutions as shown in Figure 2-17. Each solution consists of a solution name, access control service (ACS), service bus registry, and credentials for accessing ACS and ServiceBus endpoints. Each link (ACS, ServiceBus, and Credentials) takes you to their respective management pages. An ACS is a cloud-based claims-mapping service that can be used in cloud-based as well as on-premise applications that use claims-based identity model. ServiceBus is an Internet message bus for sending and receiving messages across the Internet between applications. The Credentials page lets you manage credentials for accessing ACS and ServiceBus services. Figure 2-18 shows the credentials management page from the AppFabricportal.

Figure 2.18. AppFabricCredentials Management

You can have three types of credentials for accessing AppFabricendpoints: Solution Password, Windows CardSpace Information Card, and X.509 certificates. You can use any one of the credentials for accessing the AppFabric endpoints.

To navigate to the AppFabric developer portal, click the SQL Azure link on the Windows Azure portal. If you are logging in for the first time, you may need an invitation token to enter before the portal takes you to the SQL Azure developer portal. From the SQL Azure developer portal, you can manage your projects and create/delete databases. Figure 2-19 shows the list of projects I am allowed to administer in my account.

Figure 2.19. SQL Azure Projects

Clicking the Manage link will take you to the server administration page, where you can create and delete databases. Figure 2-20 shows the server administration page with five databases. The master database is the SQL Server master database you receive with all the SQL Azure instances.

Figure 2.20. SQL Azure Project management page

The Create Database and Drop Database buttons let you create a new database or drop an existing database respectively. The Connection Strings button gives you the format of the database connection string you can use for accessing the database from SQL Server clients.

You may use Windows Vista SP1 (Home Premium, Enterprise, or Ultimate), Windows 7, or Windows 2008 Server.

I have divided the software requirements for each service into its own section. The "general" section lists the software required for all Windows Azure platform development work.

The installation of all these software components and SDKs is fairly straightforward. In this chapter, we will use only Windows Azure SDK. In later chapters, you will need the AppFabric and Live Framework SDKs.

The objectives of this example follow:

The service architecture consists of a simple Windows Azure web role cloud service developed in the local development environment by the developer and then uploaded to the Windows Azure cloud portal. Figure 2-15 illustrates the service architecture for this example. In Figure 2-21, the developer develops the cloud service on-premise and then deploys it to the Windows Azure cloud platform.

Figure 2.21. HelloService Architecture

Figure 2-22 illustrates the developer workflow for developing the Windows Azure web role cloud service.

Figure 2.22. Developer Workflow

The developer workflow illustrates the steps required to develop, build, and deploy a simple web role cloud service to the cloud.

I have divided the remainder of this example into two separate sections: "Developing the Service" and "Deploying the Service." In the development section, you will develop and test your service locally in the Windows Azure development fabric. In the deployment section, you will deploy the service as a Windows Azure cloud service.

The step-by-step walkthrough for the Windows Azure Web cloud service example is as follows:

Figure 2.25. Cloud services solution

The HelloService project is the new cloud services project containing configuration and metadata of the Windows Azure cloud service and reference to the web role project. The Roles folder holds references to all the roles in the cloud service. The HelloAzureCloud project is the ASP.NET web application, which is called a web role in context of the cloud service. On its own, HelloAzureCloud is a regular ASP.NET web application.

The ServiceConfiguration.cscfg file is the configuration file of the cloud service. It contains configuration settings for the service. There are two main sections under the Role element—Instances and ConfigurationSettings, as shown in Listing 2-1.

<?xml version="1.0"?>
<ServiceConfiguration serviceName="Ch2Solution" xmlns=
"http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
  <Role name="HelloAzureCloud">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString"
value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

The default configuration setting includes a DiagnosticsConnectionString for instrumentation and logging. For the sake of simplicity, let's not change the default values in the ServiceConfiguration.csfg. The main difference between web.config and ServiceConfiguration.csfg is that Web.config is application specific and ServiceConfiguration.csfg is service specific across multiple instances and roles. The contents of the ServiceConfiguration.csfg can be changed dynamically from the configure section of the deployed cloud service in Windows Azure developer portal.

The ServiceDefinition.csdef contains the metadata information about the service for the Windows Azure Fabric as shown in Listing 2-2.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="Ch2Solution" xmlns="http://schemas.
microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="HelloAzureCloud">
    <InputEndpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
    </InputEndpoints>
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString" />
    </ConfigurationSettings>
  </WebRole>
</ServiceDefinition>

The file contains information like HTTP input endpoints for the service and configuration information that will apply to all the instances of roles launched by Windows Azure. Next, we're going to set up the web controls for the service.

Figure 2.31. Development Fabric with two instances

You just started two instances of the same application by just adjusting the Instances count in the ServiceConfiguration.cscfg file. This is a very powerful feature, because it lets you scale the service based on demand, without any infrastructure investments like servers and load-balancers. The Windows Azure Fabric abstracts the infrastructure intricacies from service scalability.

So, you have developed and tested your Windows Azure cloud service in the local development fabric. Now, you are ready to deploy the service in the Windows Azure cloud. To do so, you will need to open an account with Windows Azure. In this section, I will show the deployment using my own account, but you should be able to configure the same application using your account details.

The service package is deployed to the staging environment. During the deployment, Windows Azure extracts all the assemblies and files from the package and also reads the service configuration file to keep the package ready to run. When the deployment of the package completes, the staging cube changes its color from gray to light blue. If there is some problem in the package or any errors in the ServiceConfiguration.cscfg file, the deployment may fail changing the cube color to red.

Figure 2.40. Service package deployed

When you click the Run button, web role state changes from Allocated to Initializing, and the Run button changes to Suspend button. Initialization may take a few minutes for Windows Azure to configure virtual machines and deploy the service to them. Once the service is initialized, the web role state changes to Started as shown in the Figure 2-43.

Figure 2.43. Started Staging Application

Now, you can test your service:

You successfully developed, tested, and deployed your first Windows Azure cloud service without purchasing any server or load-balancer hardware.

In this example, you saw how easily an ASP.NET web application can be developed, tested, and deployed to the Windows Azure cloud as a cloud service. You learned to use Visual Studio .NET tools for developing Windows Azure cloud service. You also saw how easy it is to start multiple instances of the same web role application to enhance availability and scalability. Imagine the efforts it would require to create a multi-instance ASP.NET application across multiple machines in your local or an enterprise environment. The key idea to take away from this example is how Windows Azure abstracts the hardware and software complexities of deploying and scaling cloud services in a production environment. The intricacies involved in commissioning servers, network switches, load balancers, and network connectivity are abstracted from application developers. With just a few mouse clicks and XML settings, you can increase or decrease the number of role instances in Windows Azure.

The simplicity of the ASP.NET web application was on purpose to keep the overall solution simple and take you through the entire life cycle of creating Windows Azure cloud service. You can enhance this service by adding more complex features like AJAX and external Web Service Access.