As described previously, Microsoft Data Centers contain the clusters of Windows Server 2008 (64 bit), which are virtualized to provide the Virtual Machine Images (Cloud Virtual Machines), which in turn hosts the User Code and Runtime APIs. These are accessed through the portal using the Service Management Service (a REST-based Service). In addition to compute VM clusters, the data center also hosts Storage Clusters for the storage service. These are also accessible through Representational State Transfer (REST), a new client-server software architecture built on transfer of resource representations. The developers using Visual Studio 2008 SP1 and Visual Studio 2010, presently in Beta 2 (VS 2010 will be available during 2010), and the Windows Azure SDKs as mentioned previously need Windows Azure Visual Tools: http://www.microsoft.com/downloads/details.aspx?familyid=6967FF37-813E-47C7-B987-889124B43ABD&displaylang=en. The servers hosting SQL Azure Services are separate from the ones used for the Compute and Storage Services.

The Windows Azure Service, as you will be seeing later in Exercise 1.2, consists of components called roles enclosed within a service boundary built with managed code. This is where your executable program is hosted using this role-based model.

By design, it is mandated that the service should have at least one role. There are two kinds of roles; the Web Role, supported by IIS7 and ASP.NET, is well suited for web-applications defining a single HTTP/HTTPS endpoint for external clients and a Worker Role for running background programs. The storage service, the other component, can be accessed by the worker role to feed data to the web role. An application hosted on Windows Azure can have more than one role of each kind and a service hosted on Windows Azure can run multiple instances of these roles. The Azure Platform can replicate these across multiple virtual machine images. From an external location the service is reachable by a single Virtual IP Address (VIP) for load-balanced traffic to multiple end points.

The web role to worker role communication takes place through internal endpoints over TCP and HTTP shown schematically in the following figure:

While the previous figure shows the constituent parts of the compute service, the application is developed using Visual Studio at the user's premises. Visual Studio is the main programming IDE used. The SDKs provide the necessary hook ups to the Cloud Simulation and a number of different kinds of application templates (ASP.NET Web Application, WCF Service, Web Service, and more). The tools are needed for the application to be run in the development fabric (the program that simulates the Cloud environment locally on the premises) with the support of a locally installed IIS 7 server.

Typically, applications are developed in Visual Studio and tested in the simulated development environment followed by deployment. In the development process the development fabric comes into play and this is where 'debugging' of the application can be done effectively. The user will also have access to development user interface and a development local storage. The deployment can be a two-step process with an initial deployment to a Staging Slot (a client-specific staging URL) followed by a Public or web-facing URL, the Production Slot. After deployment, logging the messages is the only way available for developers to track the application.

The billing for the Windows Azure-hosted service starts whenever an application is hosted irrespective of whether it is in Production or Staging, irrespective of whether it is stopped or active. If you don't want to be billed you delete the application. In order to delete you must first stop it. In fact the Windows Azure Portal posts a warning to this effect.

You need to get a storage account to work with Windows Azure Storage. Cloud-hosted applications use client data stored in Storage Accounts, and/or relational data in the SQL Azure. The Storage Account accessed by the Storage Service API, which as mentioned previously, is REST-based. You manipulate data in the Storage Service using POST, PUT, and DELETE requests and retrieve using GET. SQL. Azure data, on the other hand, is accessed by both applications as well as on-premises SQL Servers using T-SQL and ADO.NET. Users can access this Azure Storage Service from within an application running in Windows Azure, or directly from the internet by sending HTTP/HTTPS (version 1.0 for some operations and HTTP/HTTPS 1.1) requests and processing the returned responses.

Users should make sure of the storage service version they will be using by looking it up here: http://msdn.microsoft.com/en-us/library/dd894041.aspx. Just as in the case of hosted services, a development storage service is provided for local testing to simulate cloud storage service using local SQL Express servers (default 2005 or 2008 versions) or any local instance of SQL Server.

The following figure shows the components of the Windows Azure Storage. The Windows Azure Drive was added on Feb 1, 2009 which writes to Page blobs. The Windows Azure Drive makes it easier to migrate applications to the cloud as it appears as another durable disk drive. For applications that use file I/0 the disk availability provides a high degree of flexibility using the standard Windows NTFS APIs.

The Storage Account you hold is the top element in the namespace, which is accessed with authentication. The REST API exposes the storage account as a resource consisting of:

SQL Azure is a relational database built leveraging SQL Server Technology in its latest embodiment — the SQL Server 2008 R2 (version 10.5). SQL Azure services offer a platform for hosting SQL Azure databases in the Windows Azure platform. Users can build web-facing database applications using SQL Azure as the 'cloud end'. In mid-February 2010, SQL Azure was updated with SU1.

Being built on SQL Server technologies and the agile, extensible, scalable data center infrastructure, SQL Azure provides a highly scalable, highly available, multi-tenant database service in the cloud. The ease with which you can create a database is truly amazing as the provisioning is extremely fast as we see later in the book.

The provisioning and management offered by this cloud service abstracts away an important part of how the databases are traditionally installed and managed. In fact many businesses do not need to employ IT professionals who work on the physical (hardware) side of database installation and management. This will be one of the selling points where the ROI is highly perceptible. As the databases are replicated in the cloud with a high degree of redundancy, users need not concern themselves regarding replication issues to the extent they were concerned traditionally. Also with the SQL Server being a mature technology there is a very little learning path to move user data to the cloud. The very familiar T-SQL is supported and the databases created in the cloud can be accessed through familiar tools such as Microsoft SQL Server Management Studio, SQLCMD, and so on.

The SQL Azure service architecture follows the schematic shown in the following figure:

The hardware is installed in the Microsoft Data Centers. SQL Server instances are installed on these machines, which provide the SQL Server and SQL Server Management Services. The SQL Azure hardware is separate from hardware used for Azure Compute and Storage but is shared across all clients. The SQL Azure fabric controller works in the platform layer. The SQL Azure Fabric is a part of the computing system that handles automatic failover, load balancing, and automatic replication between the servers in the data centers. It is, therefore, tightly integrated with the data center infrastructure such as servers, network, and storage. The services layer does most of the provisioning, billing and metering and connection routing. The Services layer is accessed by the Client through the portal using TDS (Tabular Data Stream). Tabular data stream is also accessible through the familiar ODBC and ADO.NET data services. SQL Server applications and tools can access the services layer using TDS but customer applications written in any of the familiar languages such as PHP, Java, and .NET languages can access through ODBC and ADO.NET and through HTTP/REST. These are the same languages that access on-premises SQL Servers; therefore, it makes it very easy to work with SQL Azure.

At present, in addition to SQL Azure, the SQL Azure Data Sync application — based on Microsoft Sync Framework 2.0 — provides a useful tool to synchronize SQL Azure data with on-the-premises SQL Server, thus enabling remote access to data on the cloud to mobile clients connecting through remote sites.

Although SQL Server Integration Services, the SQL Server Reporting Services, are not on the cloud, these applications available in the local servers can be used with the cloud-based SQL Azure databases. It is envisaged that these Business Intelligence (BI) applications will also be available in a future version of Microsoft Azure Platform.

The AppFabric addresses the needs of securely accessing widely distributed resources. What used to be called .NET Services in the earlier versions of Windows Azure is now called AppFabric. As you will see later in this chapter, you can access the AppFabric from the Windows Azure Portal (http://windows.azure.com) after logging in with your Windows Live ID. It is a service just like the Windows Azure discussed previously.

The AppFabric consists of the Service Bus and Access control. These provide building blocks to .NET Applications to function reliably in the Microsoft Windows Azure platform. The necessity arises because one needs authentication and access to widely distributed resources that programs need, which reside behind machine firewalls and network firewalls. Furthermore, the stateless nature of web applications together with the changeable nature of the hosting environment makes for a loosely connected system requiring a way to manage connections. AppFabric provides these very important functionalities, which are needed for taking applications to the cloud:

The Service Bus "relays" messages from clients to applications running on the premises sidestepping obstacles such as firewalls, NATs, and other objects as shown in the next figure. In this respect, it may be compared to a "relay phone" in the USA, which acts as a relaying point to connect your phone to a phone in another country, for example, a procedure used by Skype. Many Internet chat services work on the same principle of relayed connectivity.

The "Service" opens a bidirectional connection to the "Relay" by an outbound connection and a "Relay Address". The client (Application) connects to this address through an outbound connection. This way the Client can connect to the Service bypassing the barriers. The client application need not know where the service resides. The Service Bus provides a network infrastructure for interconnecting applications using a variety of messaging patterns.

The Service Bus supports the following forms of communication:

The security provided by the barriers is in no way compromised. Additionally, the Service Bus can also negotiate for direct connection between applications under some circumstances as in the following image:

The Service Bus works with Access Control through claims and a trust relationship. Both the client and the service must provide credentials to the Access Control to obtain a security token. Access Control provides a generic way to implement the authentication and authorization (using claims) program separate from applications. This relieves the developers from writing custom authentication and authorization routines and rules. The Access Control provides a claims transformation program that can leverage federated identity (delegated identity) providers facilitating enterprise clients to use their authentication in Active Directory. It is envisaged that other Identity Providers, such as Facebook connect, Google Accounts, and Windows Live ID will be available in the future.

Both of these services are accessible through open protocols and standards such as SOAP, REST, ATOM, and ATOMPUB, which allows more flexible program integration.

The AppFabric SDK, which may be downloaded from here: (http://www.microsoft.com/downloads/details.aspx?FamilyID=0bd0b14f-d112-4f11-94bf-90b489622edd&displaylang=en; Version 1.0 in Beta 1, November 2009) provides a great deal of help in understanding and working with these services by way of codes and samples. Windows Communication Foundation WCF is the primary programming model for working with the Service Bus. The SDK simplifies the task of integrating these services into your .NET Applications on the premises by introducing new concepts like WCF Relay Bindings. Similar SDKs are also available for Java and Ruby developers.

Most recently, Microsoft has released (http://blogs.msdn.com/b/windowsazureappfabric/archive/2010/09/19/windows-azure-appfabric-sdk-september-release-available-for-download.aspx) Windows Azure AppFabric SDK (Version V 1.0) for both x32 and x64 bit computers. If you want to use this September release follow this link:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=39856a03-1490-4283-908f-c8bf0bfad8a5&displaylang=en.

However, note that the name of the installer has now changed to WindowsAzureAppFabricSDK-x86.msi.