Windows Azure AppFabric Applications

The Windows Azure AppFabric team is on a bit of a roll. After releasing Service Bus Queues and Topics into CTP last month, the team has just released AppFabric Applications into CTP. Nominally, AppFabric Application simplifies the task of composing services into an application but, in practice, it appears to rewrite the meaning of platform-as-a-service (PaaS).

The Windows Azure Platform has been the paradigm for PaaS. The platform supports various services such as ASP.NET websites in web roles, long running services in worker roles, highly-scalable storage services in the Windows Azure Storage Service, and relational database services in SQL Azure. However, the Windows Azure Platform does not provide direct support, other than at the API level, for integrating these various services into a composite application.

With the introduction of AppFabric Applications, the Windows Azure Platform now provides direct support for the composition of various services into an application. It does this by modeling the various services and exposing, in a coherent form, the properties required to access them. This coherence allows for the creation of Visual Studio tooling supporting the simple composition of services and the provision of a Portal UI supporting the management of deployed applications.

In AppFabric Applications, services are allocated to deployment containers which control the scalability of the services in them. Different containers can run different numbers of instances. These containers are hosted on the Windows Azure fabric. The services use that fabric in a multi-tenant fashion with, for example, instances of a stateless WCF service being injected into already deployed Windows Azure worker role instances.

In classic Windows Azure, the developer must be aware of the distinction between roles and instances, and how an instance is deployed into a virtual machine (VM). This need vanishes in AppFabric Applications, where the developer need know only about services and need know nothing about how they are deployed onto Windows Azure role instances.

The AppFabric Applications Manager runs on the AppFabric Labs Portal, and provides a nice UI allowing the management of applications throughout their deployment lifecycle. Unlike the regular Windows Azure Portal, the AppFabric Applications Manager provides direct access to application monitoring and tracing information. In future, it will also support changes to the configuration of the application and the services it comprises.

The AppFabric team blog post announcing the Windows Azure AppFabric June CTP, which includes AppFabric Applications, describes how to request access to the CTP.  Karandeep Anand and Jurgen Willis introduced AppFabric applications at Tech-Ed 11 (presentation, slides). Alan Smith has posted two good videos on AppFabric Applications – one is an introduction while the other shows how to use Service Bus Queues in an AppFabric Application. The MSDN documentation for AppFabric Applications is here.

This post is the latest in a sequence of posts on various aspects of Windows Azure AppFabric. The earlier posts are on the Windows Azure AppFabric Caching service and Service Bus Queues and Topics.

Applications, Containers and Services.

AppFabric Applications supports the deployment of composite applications to a Windows Azure datacenter. An application comprises one or more services, each of which is deployed into a Container (or Service Group) hosted by Windows Azure. The container is the scalability unit for deployments of AppFabric Applications. An application can have zero or more of each type of container, and each container can be deployed as one or more instances.

AppFabric Applications supports three types of container:

• AppFabric Container
• Stateful AppFabric Container
• Web

An AppFabric Container can contain the following stateless services:

• Code
• WCF Service
• Workflow

A Code service is used to create long-running services in an AppFabric Application, and essentially provides the  functionality of a worker role in classic Windows Azure. A WCF Service is a stateless WCF service. A Workflow service is a Windows Workflow 4 service.

A Stateful AppFabric Container can contain the following stateful services:

• Task Scheduler
• WCF Stateful Service

A Task Scheduler service is used to schedule tasks.  A WCF Stateful service supports the creation of services which preserve instance state. To enhance scalability, WCF Stateful services support the partitioning of data and its replication across multiple instances. Furthermore, to ensure the fair allocation of resources in a multi-tenant environment WCF Stateful Services also implement the eviction of data when the 500MB limit per service is reached.

A Web container can contain:

• ASP.NET
• WCF Domain Service – Web
• WCF Service – Web

The ASP.NET service is an ASP.NET (or MVC) web application. The WCF Domain Service contains the business logic for WCF RIA Services application. The WCF Service is a web-hosted WCF service.

Applications are composed using more or less arbitrary mixes of these services. The services are related by adding, to an invoking service, a reference to the endpoint of another service.  For example, a reference to the endpoint of a stateless WCF service could be added to an ASP.NET service. A simple application could comprise, for example, 2 instances of a Web container hosting an ASP.NET service with 1 instance of an AppFabric Container hosting a stateless WCF service.

When a service reference is added to a service, the reference is given a default name of Import1. This name can be changed to a more useful value. The Visual Studio tooling then adds a generated file, ServiceReferences.g.cs, to the project for the service importing the endpoint for the service. The following is an example of the generated file when a stateless WCF service is added to another service (using the default name of Import1):

class ServiceReferences
{
    public static AppFabricContainer1.StatelessContract1.Service1.IService1 CreateImport1()
    {
        return
Service.ExecutingService.ResolveImport<AppFabricContainer1.StatelessContract1.Service1.IService1>(“Import1”);
    }

    public static AppFabricContainer1.StatelessContract1.Service1.IService1 CreateImport
        (System.Collections.Generic.Dictionary<string, object> contextProperties)
    {
        return Service.ExecutingService.ResolveImport<AppFabricContainer1.StatelessContract1.Service1.IService1>(“Import1”, null, contextProperties);
    }
}

This generated file adds two methods that return a proxy object that can be used inside the service to access the stateless WCF service, as with traditional WCF programming. Note that if the service name had been changed from the default Import1 to MyWcfService, the methods would have been named CreateMyWcfService instead of CreateImport1.

As well as the core services, AppFabric Applications also supports the use of referenced services – which are services not hosted in AppFabric Applications containers. The following referenced services are supported directly by the June CTP:

• AppFabric Caching
• Service Bus Queue
• Service Bus Subscription
• Service Bus Topic
• SQL Azure
• Windows Azure Blob
• Windows Azure Table

Both core services and referenced services are modeled so that the Visual Studio tooling can handle them. (To avoid confusion referenced services should really have been called something like external services.) This modeling provides for the capture, through a properties window, of the core properties needed to configure the referenced service. For example, for Windows Azure Blob these properties include the storage service account name and key, the container name, whether development storage should be used and whether HTTPS should be used.

The modeled properties typically include a ProvisionAction and an UnprovisionAction providing information required to provision and de-provision the referenced service. For example, for a SQL Azure referenced service the ProvisionAction is either InstallIfNotExist or None while the UnprovisionAction is either DropDatabase or None. In this case, a ProvisionAction of InstallIfNotExist is invoked only if a Data Tier Applications (DAC) package is provided as an Artifact for the SQL Azure referenced service.

The effect of adding a referenced service to a service is the same as with core services. The following is an example of the generated file when a Windows Azure Table referenced service is added to a stateless WCF service (using the default name of Import1):

namespace StatelessContract1
{
    class ServiceReferences
    {
        public static Microsoft.WindowsAzure.StorageClient.CloudTableClient CreateImport1()
        {
            return
               Service.ExecutingService.ResolveImport<Microsoft.WindowsAzure.StorageClient.CloudTableClient>(
                   “Import1”);
        }

        public static Microsoft.WindowsAzure.StorageClient.CloudTableClient
            CreateImport1(System.Collections.Generic.Dictionary<string, object> contextProperties)
        {
            return
               Service.ExecutingService.ResolveImport<Microsoft.WindowsAzure.StorageClient.CloudTableClient>(
                   “Import1”, null, contextProperties);
        }
    }
}

This generated file adds two methods that return a CloudTableClient object that can be used inside the service to access the Windows Azure Table Service. Note that if the service name had been changed from the default Import1 to CloudTableClient, the methods would automatically have been named CreateCloudTableClient instead of CreateImport1. The following is the service implementation for a WCF Stateless Service taken from an sample in the MSDN documentation:

namespace GroceryListService
{
    public class Service1 : IService1
    {
        private const string tableName = “GroceryTable”;
        private CloudTableClient tableClient;

        public Service1()
        {
            tableClient = ServiceReferences.CreateCloudTableClient();
            tableClient.CreateTableIfNotExist(tableName);
        }

        public void AddEntry(string strName, string strQty)
        {
            GroceryEntry entry = new GroceryEntry() { Name = strName, Qty = strQty };
            TableServiceContext tableServiceContext = tableClient.GetDataServiceContext();
            tableServiceContext.AddObject(tableName, entry);
            tableServiceContext.SaveChanges();
        }
}

The service objects exposed through ServiceReferences.g.cs when a reference service is referenced by another service are as follows:

Azure Blob	Microsoft.WindowsAzure.StorageClient.CloudBlobClient
Azure Table	Microsoft.WindowsAzure.StorageClient.CloudTableClient
Caching	Microsoft.ApplicationServer.Caching.DataCache
Service Bus Queue	Microsoft.ServiceBus.Messaging.QueueClient
Service Bus Subscription	Microsoft.ServiceBus.Messaging.SubscriptionClient
Service Bus Topic	Microsoft.ServiceBus.Messaging.TopicClient
SQL Azure	System.Data.SqlClient.SqlConnection

The Service Bus Queues and Topics API exposes a .NET API using QueueClient, SubscriptionClient and TopicClient. Service Bus Queues can also be used through a WCF binding for service bus messaging that allows queues to be used for disconnected access to a service contract. In addition to the standard technique of using the methods exposed in ServiceReferences.g.cs it is also possible to access the service contract using the WCF  binding for a Service Bus Queue. For example, a service can use a Service Bus Queue referenced service (SendToQueueImport) to invoke a service contract (IService1) exposed in another service by retrieving a proxy as follows:

IService1 proxy = Service.ExecutingService.ResolveImport<IService1>(“SendToQueueImport”);

This proxy can be used to invoke methods exposed by the contract, with the communication going through a Service Bus Queue. If IService1 contains a contract for a method named Approve() then it could be invoked through:

proxy.Approve(loan)

Development Environment

The AppFabric Applications SDK adds Visual Studio tooling to support the visual composition of applications. As services are added to the application, the tooling ensures that the appropriate projects are created and the relevant assembly references added to them. When a service reference is added to a service, the tooling adds the relevant generated file and assembly references to the project for the service.

When an AppFabric Application solution is created in Visual Studio it adds an Application project to the solution. The app.cs file in this project contains the definition of the application and all the services and artifacts used by it. Double clicking on app.cs brings up a list view showing either the Design View or the Deployment View. Right clicking on it allows the View Diagram menu item to be selected, which displays the application design in the form of a diagram. This is very useful when the application design is complex. (The app.designer.cs file contains the really gory details of the application composition.)

In the Design View of app.cs in Visual Studio, the services and referenced services in the application are grouped by service type. In the Deployment View, they are grouped by container (or service group). The scaleout count and the trace source level are container-level properties that can be changed in the Deployment View. They will be modifiable on the AppFabric Labs Portal, but the current CTP does not support this capability.

Applications can be instrumented using System.Diagnostics.Trace. The TraceSourceLevel can be set at the container (service group) level in the deployment view of the application in Visual Studio

When an application is deployed in the local environment, Visual Studio launches the Windows Azure Compute Emulator and the Windows Azure Storage Emulator. It then deploys a ContainerService with three roles:

• ContainerGatewayWorkerRole (1 instance)
• ContainerStatefulWorkerRole (2 instances)
• ContainerStatelessWorkerRole (2 instances)

Application services in AppFabric Containers and Stateful AppFabric Containers are then injected into these instances. Application services in a Web Container are injected into a second deployment which adds a web role instance. Note that the first deployment remains running after the application has been terminated, and is reused by subsequent deployments. However, I have run into an issue where an application containing no Web Container is not deleted after I exit the service. I have had to manually delete the deployment from the c:\af  directory.

A basic application with an ASP.NET service consequently requires 6 instances running in the Compute Emulator. This puts significant memory pressure on the system that can leads to a delay in the deployment. Following deployment, the first few attempts to access a web page in an ASP.NET service frequently seem to fail. A few refreshes and a little patience usually brings success (assuming the code is fine). (On the VM on which I tried out AppFabric Applications, things went better after I pushed more memory and disk into it – a little patience was not sufficient to cure the out of disk space errors I received during deployment.)

Following a deployment in the development environment, the application assemblies are located in the c:\af directory. The development environment stores various log files temporarily in files under this directory and c:\AFSdk. The latter contains directories – GW0, SF0, SF1, SL0 and SL1 – corresponding to the instances of the ContainerService deployment. Once the application terminates, these logs are persisted into AppFabric Application Container-specific blobs in Storage Emulator containers named similarly to wad-appfabric-tracing-container-36eenedmci4e3bdcpnknlhezmi, where the final string represents the specific deployment.

An issue I came across was that the June CTP requires SQL Server Express. I have configured the Windows Azure Storage Emulator to use SQL Server 2008 R2. Consequently, both SQL Server Express and SQL Server 2008 R2 must be running when an application is deployed to the Compute Emulator. This is not an issue when the Storage Emulator uses SQL Server Express, which is the default for the Windows Azure SDK.

Production Environment

The AppFabric Application Manager displays informational information about the current lifecycle state of the application, such as uploaded or started. It supports the management of that lifecycle – including the uploading of application packages, and the subsequent deployment and starting of the application.

The AppFabric Manager also supports the display of application logs containing various metrics from containers, services and referenced services. For containers, these include metrics like CPU usage and network usage. The metrics include information such as ASP.NET requests and WCF call latency for services. The client-side monitoring of referenced services captures information such as SQL client execution time and Cache client get latency. The application logs can be downloaded and viewed in a trace viewer. This is all a huge improvement over the diagnostic capability exposed in the portal for classic Windows Azure.

The deployment and startup of an application with three trivial Code services distributed across two containers took less than 2 minutes. The deployment and startup of the GroceryList sample application with a web site, a stateless WCF service and a SQL Azure database took 8 minutes. This speedup, over the deployment of an instance of a worker or web role in classic Windows Azure, comes from the multi-tenant nature of AppFabric Applications which deploys services into an already running instance.

Summary

I am a great advocate of the PaaS model of cloud computing. I believe that AppFabric Applications represents the future of PaaS for use cases involving the composition of services that can benefit from the cost savings of running in a multi-tenanted environment. AppFabric Applications reduces the need to understand the service hosting environment allowing the focus to remain on the services. That is what PaaS is all about.