A Web role is a web site or web service that can run in an IIS 7 environment. Most commonly, it will be an ASP.NET web application or a Windows Communications Foundation (WCF) service with HTTP and/or HTTPS endpoints.

The Web role also supports FastCGI extension module to IIS 7.0. This allows developers to develop web applications in interpreted languages like PHP and native languages like C++. Windows Azure supports Full Trust execution that enables you to run FastCGI web applications in Windows Azure Web role. To run FastCGI applications, you have to set the enableNativeCodeExecution attribute of the Web role to true in the ServiceDefinition.csdef file. In support of FastCGI in the Web role, Windows Azure also introduces a new configuration file called Web.roleconfig. This file should exist in the root of the web project and should contain a reference to the FastCGI hosting application, like php.exe. In the interest of keeping this book conceptual, I will not be covering FastCGI applications. For more information on enabling FastCGI applications in Windows Azure, please visit the Windows Azure SDK site at http://msdn.microsoft.com/en-us/library/dd573345.aspx.

The Worker role gives you the ability to run a continuous background process in the cloud. The Worker role can expose internal and external endpoints and also call external interfaces. A Worker role can also communicate with the queue, blob, and table Windows Azure storage services. A Worker role instance runs independently of the Web role instance, even though both of them may be part of the same service. A Worker role runs on a totally different virtual machine than the Web role in the same service. In some Windows Azure services, you may require communication between a Web role and a Worker role. Even though the Web and Worker role expose endpoints for communication among roles, the recommended mode of reliable communication is Windows Azure queues. Web and Worker roles both can access Windows Azure queues for communicating runtime messages. I will cover Windows Azure queues in the next chapter.

A Worker role class must inherit from the Microsoft.WindowsAzure.ServiceRuntime.RoleEntryPoint class. RoleEntryPoint is an abstract class that defines functions for initializing, starting and stopping the Worker role service. A Worker role can stop either when it is redeployed to another server, or you have executed the Stop action from the Windows Azure developer portal. Figure 3-4 illustrates the sequence diagram for the life cycle of a Worker role.

Figure 3.4. Sequence diagram for a Worker role service

In Figure 3-4, there are three objects: Fabric Controller, RoleEntryPoint, and a Worker role implementation of your code. Fabric Controller is a conceptual object; it represents the calls that the Windows Azure Fabric Controller makes to a Worker role application. The Fabric Controller calls the Initialize() method on the RoleEntryPoint object. RoleEntryPoint is an abstract class so it does not have its own instance; it is inherited by the Worker role instance to receive calls. The OnStart() method is a virtual method, so it does not need to be implemented in the Worker role class. Typically, you would write initialization code like starting diagnostics service or subscribing to role events in this method. The Worker role starts its application logic in the Run() method. The Run() method should have an continuous loop for continuous operation. If the Run() method returns, the role is restarted by the OnStart() method. If the role is able to start successfully, the OnStart() method returns True to the Fabric Controller; otherwise, it returns False. The Fabric Controller calls the Stop() method to shut down the role when the role is redeployed to another server or you have executed a Stop action from the Windows Azure developer portal.

The Windows Azure Tools for Visual Studio creates a project type named Cloud Service containing project templates for Web role and Worker role. After you install Windows Azure Tools for Visual Studio, open Visual Studio and create a new Project by selecting File

Figure 3.5. New Project

The Windows Azure Cloud Service template defines the cloud service project. Click OK to choose from the available roles (see Figure 3-6).

Figure 3.6. Cloud Service roles

The available cloud service roles are as follows:

Choose the roles you want, as shown in Figure 3-7. I have selected a Web role, a WCF Web role, and a Worker role.

Figure 3.7. Selected roles

Click OK to create the cloud service project, as shown in Figure 3-8.

Figure 3.8. Empty cloud service project

In Figure 3-8, the HelloAzueCloud cloud service project holds references in the Roles subfolder to all the role projects in the solution. The cloud service project also contains ServiceDefinition.csdef and ServiceConfiguration.cscfg files that define the configuration settings for all the roles in the cloud service.

The WCF service Web role project includes a sample service and its associated configuration in the we.config file. The WebRole.cs file implements the start and configuration changing events fired by the Windows Azure platform. This file is created for all the roles with default start and configuration changing event handlers. You can handle additional events like StatusCheck and Stopping depending on your application needs. The WebRole class inherits the RoleEntryPoint class from the Microsoft.WindowsAzure.ServiceRuntime namespace. The WebRole.cs file is analogous to the Global.asax file in a traditional ASP.NET application.

The ASP.NET Web role project consists of a Default.aspx file and its associated code-behind and web.config file.

Finally, the Worker role project consists of WorkerRole.cs file and its associated app.config file. In addition to inheriting the RoleEntryPoint class, it also overrides the Run() method in which you add your continuous processing logic. Because a Worker role is not designed to have any external interface by default, it does not contain any ASP.NET or WCF files.

In summary, the cloud service defined in this project consists of a WCF service, an ASP.NET web application, and a Worker role service. The entire package constitutes a Windows Azure cloud service.

In the cloud service project, you can configure each role's settings by double-clicking the role reference in the Roles subdirectory of the cloud service project. Figure 3-9 shows the role settings page in Visual Studio.

Figure 3.9. Role settings (the default is Configuration)

The role settings page has five tabs: Configuration, Settings, Endpoints, Local Storage, and Certificates.

The Configuration tab is selected by default and displays the following configuration options:

The VM size option gives you the ability to choose from a list of virtual machines preconfigured in the Windows Azure virtual machine pool. You can choose from the following list of predefined virtual machines depending on your deployment needs:

The Web roles have a startup action that defines the endpoint on which the browser should launch. This setting is not a cloud service setting but a project setting for launching the Web role in the development fabric.

The Settings tab, shown in Figure 3-10, defines any custom settings you can add to the role configuration.

Figure 3.10. Settings

These custom name-value pairs are analogous to the name-value appSettings in an app.config or web.config file. You can retrieve the values of these settings in your code by calling the RoleEnvironment.GetConfigurationSettingValue. By default there is a DiagnosticsConnectionString setting present which is used for logging from your roles. Do not remove this setting.

The Endpoints tab contains endpoints your role will create when it is deployed. Figure 3-11 shows the Endpoints tab for a Web role and a Worker role respectively.

Figure 3.11. Endpoints tab for Web and Worker roles

The Web role can have InputEndpoints and an internal endpoint. InputEndpoints are HTTP or HTTPS endpoints exposed externally. The port number defines the port your will use while accessing the default web page or service in this Web role. In case of an HTTPS endpoint, you can upload the X.509 certificate for accessing the web page or service using an HTTPS encrypted connection.

The internal endpoint is the endpoint accessible to other roles within the cloud service. For example, a Worker role can get a reference to the internal endpoint of a Web role in the same cloud service for making web service method calls to it.

A Worker role has no defined endpoints like a Web role because it is intended to be used as a background process. To define an endpoint, you have to add one to the list and select its type (input or internal), protocol (tcp, http, https), port, and optionally, an SSL certificate name.

Note that a Web role can have only HTTP or HTTPS endpoints, but a Worker role can have an HTTP, HTTPS, or TCP endpoint.

The LocalStorage tab defines local directories that will be created on the server machine of the role for storing files locally. Figure 3-12 shows the settings on the LocalStorage tab.

Figure 3.12. Local storage

The name of the local storage will be the names of directories created on the server. The size column defines the maximum size of the folder contents and the "Clean on Role Recycle" column defines whether you want the contents of the directory cleaned up when a role recycles. You can use this option for creating sticky storage for maintaining state of the role across reboots and failures. Local storage can be effectively used for temporary caching and session management applications.

The Certificate tab is used for referencing the certificates in your role. At the time of this writing, you still had to use the Windows Azure developer portal or the service management API for uploading the certificate to the server and then reference the certificate in the settings as shown in Figure 3-13.

Figure 3.13. Certificate configuration

Once you have created a Windows Azure cloud service project, you can work with the cloud service roles, work with storage services or work on the debug and deployment of the cloud service.

Working with Cloud Service Roles

You can associate an existing Web role or a Worker role from a solution to the cloud service project, or create a new role by right-clicking on the Roles subdirectory and selecting Add, as shown in Figure 3-14.

Figure 3.14. Adding associate roles to cloud service

By selecting New Web Role or New Worker Role project, you can create a new Web role project in the solution that is associated with the cloud service project. By selecting a Web role or Worker role project in the solution, you can associate an existing project in the solution to the cloud service project. Figure 3-15 shows option for adding a new role to the existing cloud service.

Figure 3.15. Adding new roles

Working with Storage Services

The Windows Azure development fabric includes a local storage environment that resembles the cloud storage service. It has development-specific blob, queue, and table services that simulate the ones in the Windows Azure cloud. These services depend on SQL Server 2005 or 2008 database. So, you need to have SQL Server 2005 or 2008 installed on your machine to work with storage services development environment (also called Development Storage).

To start the development storage:

• Select Start

  

Figure 3.16. Development Storage

When you debug your service within Visual Studio, it starts the development storage, which you can access by right-clicking the Windows Azure system tray icon and selecting Show Development Storage UI. Figures 3-17 and 3-18 illustrate the system tray options and the development storage user interface.

Figure 3.17. Windows Azure System Tray Options

Figure 3.18. Developer Storage User Interface

In the Windows Azure Cloud environment, no direct debugging is available. Your only option is logging. But in the development fabric, you can debug by adding breakpoints in the code and by viewing the logging information in the development fabric user interface. Like any typical .NET application, Visual Studio .NET attaches the debugger to the application when run in debug mode in the development fabric. The debugger will break to the breakpoint set in the Web and Worker role projects. In the Windows Azure cloud, Visual Studio debugging environment is not available, so the best option is to log. I will discuss diagnostics and logging later in this chapter. Figure 3-19 illustrates the Development Fabric UI used for logging.

Figure 3.19. Development Fabric Logging

To enable native code debugging in a Web role project, right-click the Web role project, select Properties, go to the Web tab, and select the "Native code" check box in the Debuggers section, as shown in Figure 3-20.

Figure 3.20. Web role unmanaged code debugging

To enable native code debugging in a Worker role project, right-click the Worker role project, select Properties, go to the Debug tab, and select the "Enable unmanaged code debugging" check box, as shown in Figure 3-21.

Figure 3.21. Worker role unmanaged code debugging

To deploy the Windows Azure cloud service in the cloud, you have to package it into a .cspkg file containing all the assemblies and components, and upload the package to Windows Azure developer portal. To package a service, right-click the cloud service project, and select Publish, as shown in Figure 3-22.

Figure 3.22. Packaging a Windows Azure service

When you select Publish, Visual Studio .NET creates two files: [Service Name].cspkg and ServiceConfiguration.cscfg. It also opens Internet Explorer and takes you to the LiveID sign-in screen to sign into the Windows Azure developer portal. The [Service Name].cspkg is the service package containing all the service components required by Windows Azure to run the service in the cloud. The .cspkg file is a zip archive, and you can explore its contents by renaming it to .zip and extracting it. The ServiceConfiguration.cscfg file is the configuration file for the service instances. It is a copy if the ServiceConfiguration.cscfg file from the cloud service project.

The ServiceDefinition.csdef files defines the overall structure of the service. It defines the roles available to the service and the service input endpoints. It also defines the configuration settings for the service. The values of these configuration parameters are set in the ServiceConfiguration.cscfg configuration file. Listing 3-1 shows the contents of a ServiceDefinition.csdef file.

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

</ConfigurationSettings>
  </WebRole>
  <WebRole name="WCFServiceWebRole1">
    <InputEndpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="8080" />
    </InputEndpoints>
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString" />
    </ConfigurationSettings>
    <LocalResources>
     <LocalStorage name="L1" cleanOnRoleRecycle="false" sizeInMB="10" />
    </LocalResources>
    <Certificates>
     <Certificate name="C1" storeLocation="LocalMachine" storeName="My" />
    </Certificates>
<InternalEndpoint name="InternalHttpIn" protocol="http" />
  </WebRole>
  <WorkerRole name="WorkerRole1" enableNativeCodeExecution="true">
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString" />
    </ConfigurationSettings>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="tcp" port="10000" />
      <InternalEndpoint name="Endpoint2" protocol="tcp" />
    </Endpoints>
    <Certificates>
      <Certificate name="C1" storeLocation="LocalMachine" storeName="My" />
    </Certificates>
  </WorkerRole>
</ServiceDefinition>

Listing 3-1 is the service definition for the CloudService1: it has two Web role instances with names WebRole1 and WCFServiceWebRole1, and a Worker role instance with the name WorkerRole1. They also define endpoints, local storage, and certificates. WCFServiceWebRole1 has a <LocalStorage> element that defines the local storage space for the service role. The <ConfigurationSettings> element defines a DiagnosticsConnectionString configuration setting for the service role. The value for the DiagnosticsConnectionString setting is set in ServiceConfiguration.cscfg.

Endpoints

Windows Azure roles can have two types of endpoints: internal and input. The internal endpoints are used for interrole communications within the same cloud service, whereas the input endpoints can be accessed from anywhere. Figure 3-23 illustrates some internal endpoints of Web and Worker roles.

Figure 3.23. Internal endpoints for interrole communication

In Figure 3-23, there are two Web roles with one instance each and two instances of a Worker role. The Worker role exposes an endpoint that is consumed by both the Web roles. Note that each Web role can communicate with the exact instance of the Worker role. The Web role also exposes an HTTP endpoint that can be consumed by any of the roles in the cloud service. The endpoint only publishes the IP address and port of the instance; you still have to write TCP or HTTP code to send and receive requests. You can get a reference to the internal endpoint of an instance as follows:

IPEndPoint internale = RoleEnvironment.Roles["HelloWorkerRole"].Instances[0]
.InstanceEndpoints["MyInternalEndpoint"].IPEndpoint;

where HelloWorkerRole is the name of the Worker role and MyInternalEndpoint is the name of the endpoint. You can get the IP address of an internal instance end point in the following manner:

string ipaddress =  RoleEnvironment.Roles["HelloWorkerRole"].Instances[0]
.InstanceEndpoints["MyInternalEndpoint"].IPEndpoint.ToString();

Figure 3-24 illustrates the input endpoints of a Web role and a Worker role.

Figure 3.24. Input endpoints for external communication

The Web role instances have default HTTP input endpoints for accepting Internet requests. Windows Azure also allows Worker roles to have HTTP and TCP input endpoints for accepting connections over the Internet. Like the internal endpoint, the access to input endpoint is not limited within the cloud service; any external application can communicate with the input endpoint of the role. In Figure 3-24, Web Role 1 and Worker Role 1 have input endpoints available for communication. Any application can now communicate with endpoints of these roles over the Internet. Because the input endpoints are exposed externally, they are automatically load balanced by Windows Azure between instances. In some documentation, input endpoints are also referred to as external endpoints. You can get a reference to the input endpoint of an instance as follows:

IPEndPoint inpute = RoleEnvironment.Roles["HelloWorkerRole"].Instances[0]
.InstanceEndpoints["MyInputEndpoint"].IPEndpoint;

where HelloWorkerRole is the name of the Worker role and MyInputEndpoint is the name of the endpoint. Once you have the IPEndPoint object, you can get the IP address and port number of the endpoint to initiate communications.

<WebRole name="<role name>" enableNativeCodeExecution="true|false">

In Windows Azure, you can use certificates not only for encrypting the HTTPS endpoints of your web and Worker roles but also for custom message level encryption. You can upload X.509 certificated to your Windows Azure service either from the Windows Azure portal or using the service management API. You can upload any number of certificates for the service and these certificates will be installed in the Windows certificate stores of the role instances.

Once a certificate is uploaded to the service, it can be referenced in the ServiceDefinition.csdef and ServiceConfiguration.cscfg. The ServiceDefinition.csdef defines the name, store location, and store name of the certificate on the instance as shown here:

<Certificate name="C1" storeLocation="LocalMachine" storeName="My" />

The ServiceConfiguration.cscfg file defines the thumbprint and the thumbprint algorithm of the certificate as shown here.

<Certificate name="Certificate1" thumbprint="
5CA27AF00E1759396Cxxxxxxxxxxxxxx" thumbprintAlgorithm="sha1" />

The ServiceConfiguration.cscfg file contains the values for the configuration parameters that apply to one or more instance of the service. You can have one configuration file per instance of the service or multiple instances can share the same configuration file. Listing 3-2 shows the contents of the ServiceConfiguration.cscfg file corresponding to the ServiceDefinition.csdef file from Listing 3-1.

<?xml version="1.0"?>
<ServiceConfiguration serviceName="HelloAzureCloud" xmlns="
http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
  <Role name="WebRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString"
        value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>
  </Role>
  <Role name="WCFServiceWebRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString"
        value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="C1" thumbprint="xxxx"
        thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
  <Role name="WorkerRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString"
       value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="C1"
        thumbprint="xxxx" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
</ServiceConfiguration>

In Listing 3-2, there are three roles defined, two Web roles and a Worker role. Each role one has only one instance.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name=" MyCloudService " xmlns="http://
schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole">
    <ConfigurationSettings>
      <Setting name="AccountName"/>
      <Setting name="AccountSharedKey"/>
      <Setting name="BlobStorageEndpoint"/>
      <Setting name="QueueStorageEndpoint"/>
      <Setting name="TableStorageEndpoint"/>
      <Setting name="ContainerName"/>
    </ConfigurationSettings>
    <InputEndpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
    </InputEndpoints>
  </WebRole>
</ServiceDefinition>

<?xml version="1.0"?>
<ServiceConfiguration serviceName="MyCloudService" xmlns="http://
schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
  <Role name="WebRole">
    <Instances count="1"/>
    <ConfigurationSettings>
      <Setting name="AccountName" value="devstoreaccount1" />

<Setting name="AccountSharedKey" value="Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzF" />
      <Setting name="BlobStorageEndpoint" value="http://127.0.0.1:10000"/>
      <Setting name="QueueStorageEndpoint" value="http://127.0.0.1:10001"/>
      <Setting name="TableStorageEndpoint" value="http://127.0.0.1:10002/" />
      <Setting name="ContainerName" value="XXXgallery"/>
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

When you create a new role using the role templates template in Visual Studio.NET, the app.config and web.config files get created automatically in the role project and it consists of a trace listener provider, as shown in Listing 3-5.

<system.diagnostics>
<trace>
 <listeners>
   <add type=
"Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener,
 Microsoft.WindowsAzure.Diagnostics, Version=1.0.0.0, Culture=neutral,
 PublicKeyToken=31bf3856ad364e35"
name="AzureDiagnostics">
<filter type="" />
      </add>
  </listeners>
 </trace>
</system.diagnostics>

The DiagnosticMonitorTraceListener enables you to use the .NET Tracing API for logging within the code. You can use the Write() and WriteLine() methods of the System.Diagnostics.Trace class for logging from your code as shown here:

Trace.WriteLine("INFORMATION LOG", "Information");
Trace.WriteLine("CRITICAL LOG", "Critical");

In the ServiceDefinition.csdef and ServiceConfiguration.cscfg files, you have to define the diagnostics connection string pointing to the storage location of your choice (development storage or cloud storage). Visual Studio automatically generates this configuration for you as shown in Listing 3-6.

For development storage:
<ConfigurationSettings>
 <Setting name="DiagnosticsConnectionString" value = "UseDevelopmentStorage=true"/>
</ConfigurationSettings>
For cloud storage:
<ConfigurationSettings>
 <Setting name="DiagnosticsConnectionString" value=
"DefaultEndpointsProtocol=https;AccountName=proazurestorage;AccountKey=[YOURKEY]"/>
</ConfigurationSettings>

Next, you have to start the diagnostics service in your role by passing in the connection string name you defined in step 2. If you create a role using the Visual Studio role templates, the WebRole.cs/WorkerRole.cs files contain the code for starting the diagnostics service in the OnStart() method, DiagnosticMonitor.Start("DiagnosticsConnectionString");.

Once started, the diagnostics monitoring service can start collecting the logged data. You can also choose to further configure the diagnostics service through the DiagnosticMonitorConfiguration class, as shown in Listing 3-7.

//Get the default configuration
DiagnosticMonitorConfiguration dmc = DiagnosticMonitor.GetDefault
InitialConfiguration();
//Set the schedule to transfer logs every 10 mins to the storage
dmc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(10);
//Start Diagnostics Monitor with the storage account configuration
DiagnosticMonitor.Start("DiagnosticsConnectionString",dmc);

In Listing 3-7, the diagnostics monitor is started with the configuration option to transfer logs to the defined storage every 10 minutes automatically.

The ServiceDefinition.csdef and ServiceConfiguration.cscfg file define the service model and configuration values for the service. Listing 3-8 shows the ServiceDefinition.csdef for the HelloAzureCloud service.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="HelloAzureCloud" xmlns="http://schemas.
microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="HelloWebRole" enableNativeCodeExecution="true">

<LocalResources>
    <LocalStorage name="HelloAzureWorldLocalCache" sizeInMB="10" />
  </LocalResources>
    <InputEndpoints>
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
    </InputEndpoints>
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString" />
      <!--This is the current logging level of the service -->
      <Setting name="LogLevel" />
      <Setting name="ThrowExceptions" />
      <Setting name="EnableOnScreenLogging" />
    </ConfigurationSettings>
  </WebRole>
  <WorkerRole name="HelloWorkerRole" enableNativeCodeExecution="true">
    <Endpoints>
      <!-- Defines an internal endpoint for inter-role communication
that can be used to communicate between worker or Web role instances -->
      <InternalEndpoint name="MyInternalEndpoint" protocol="tcp" />
      <!-- This is an external endpoint that allows a role to listen
 on external communication, this could be TCP, HTTP or HTTPS -->
      <InputEndpoint name="MyExternalEndpoint" port="9001" protocol="tcp" />
    </Endpoints>
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString" />
    </ConfigurationSettings>
  </WorkerRole>
</ServiceDefinition>

The service model defines an external HTTP endpoint (input endpoint) for the HelloWebRole listening on port 80 and an internal as well as external endpoints for the HelloWorkerRole. HelloWebRole also defines a local storage named HelloAzureWorldLocalCache with maximum size of 10MB. Both the roles define a configuration setting named DiagnosticsConnectionString for diagnostics. Listing 3-9 shows the ServiceConfiguration.cscfg file for the HelloAzureCloud service.

<?xml version="1.0"?>
<ServiceConfiguration serviceName="HelloAzureCloud" xmlns="http://
schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
  <Role name="HelloWebRole">
    <Instances count="2" />
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString" value="Default
EndpointsProtocol=https;AccountName=proazurestorage;AccountKey=Ry " />
      <!--This is the current logging level of the service -->
      <!--Supported Values are Critical,
      Error,Warning,Information,Verbose-->
      <Setting name="LogLevel" value="Information" />
      <Setting name="ThrowExceptions" value="true" />

<Setting name="EnableOnScreenLogging" value="true" />
    </ConfigurationSettings>
  </Role>
  <Role name="HelloWorkerRole">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString" value="Default
EndpointsProtocol=https;AccountName=proazurestorage;AccountKey=Ry " />
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

The ServiceConfiguration.cscfg file defines the values for the model you defined in ServiceDefinition.csdef. In addition, it also allow you to define the number of instances for you role in the instances element. In Listing 3-9, two instances of the Web role and one instance of the Worker role are running. Also note that the diagnostics is pointing to a cloud storage account named proazurestorage. You must replace this with your own storage account or simple set its value to UseDevelopmentStorage=true to use the development storage.

HelloWorkerRole implements two methods, OnStart() and Run(). In the OnStart() method, it also subscribes to the role changing event to catch any configuration changes.

Listing 3-10 shows the code for the HelloWorkerRole class.

public override void Run()
{
  Trace.WriteLine("HelloWorkerRole entry point called", "Information");
  var internalEndpoint =   RoleEnvironment.CurrentRoleInstance.Instance
Endpoints["MyInternalEndpoint"];
  var wcfAddress = new Uri(String.Format("net.tcp://{0}",internal
Endpoint.IPEndpoint.ToString()));
  Trace.WriteLine(wcfAddress.ToString());
  var wcfHost = new ServiceHost(typeof(HelloServiceImpl), wcfAddress);
  var binding = new NetTcpBinding(SecurityMode.None);
  wcfHost.AddServiceEndpoint(typeof(IHelloService), binding, "helloservice");

try
  {
    wcfHost.Open();
    while (true)
    {
      Thread.Sleep(10000);
      Trace.WriteLine("Working", "Information");
    }
  }
  finally
  {
    wcfHost.Close();

  }
}

public override bool OnStart()
{
  //Get the default configuration
DiagnosticMonitorConfiguration dmc = DiagnosticMonitor.GetDefault
InitialConfiguration();
//Set the schedule to transfer logs every 10 mins to the storage
dmc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(10);
//Start Diagnostics Monitor with the storage account configuration
DiagnosticMonitor.Start("DiagnosticsConnectionString",dmc);

  RoleEnvironment.Changing += RoleEnvironmentChanging;
  return base.OnStart();
}

private void RoleEnvironmentChanging(object sender,
RoleEnvironmentChangingEventArgs e)
{
  if (e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange))
  e.Cancel = true;
}

The OnStart() method starts the diagnostics service with a scheduled log transfer to the storage and also subscribes to the Changing event of the Windows Azure runtime to detect any changes to the configuration. You can use the RoleEnvironmentChanging event to capture the following changes:

In addition, you can remove a role instance from the load-balancer after the service has started by subscribing the RoleEnvironment.StatucCheck event and calling SetBusy() method on the RoleInstanceStatusCheckEventArgs. You can also request a recycle of the role instance on-demand by calling the RoleEnvironment.RequestRecycle() method. For more information on runtime API, please see the Microsoft.WindowsAzure.ServiceRuntime namespace in the Windows Azure SDK class documentation.

Because the diagnostics service is configured to save all the logs to the Windows Azure storage, all the Trace.WriteLine() statements will be sent to the storage periodically. The Run() method gets a reference to the internal endpoint named MyInternalEndpoint from the service definition and retrieves its IP address and creates a WCF service host for the HelloServiceImpl. Once the WCF host is opened on the internal IP address and port, any role in the service can make WCF method calls. Listing 3-11 shows the code for IHelloService and HelloServiceImpl.

[ServiceContract (Namespace="http://proazure/helloservice")]
    interface IHelloService
    {
        [OperationContract]
        string GetMyIp();
        [OperationContract]
        string GetHostName();


    }
    [ServiceBehavior(AddressFilterMode=AddressFilterMode.Any)]
    public class HelloServiceImpl : IHelloService
    {


        #region IHelloService Members

        public string GetMyIp()
        {
            IPAddress[] ips = null;

            ips = Dns.GetHostAddresses(Dns.GetHostName());

            if (ips != null)
            {
                foreach (IPAddress i in ips)
                {
                    if(i.AddressFamily ==
System.Net.Sockets.AddressFamily.InterNetwork)
                     return i.ToString(); ;
                }

            }

            return "";
        }

        #endregion

public string GetHostName()
        {
            return Dns.GetHostName();
        }

    }

The IHelloService interface defines only two methods to retrieve the IP address and the domain name of the machine on which the Worker role is running. HelloServiceImpl class implements these two methods.

The user interface for the Web role is in Default.aspx. The user interface is designed to do a few operations when you click the Get Machine Info button. Figure 3-29 illustrates the user interface design of Default.aspx page.

Figure 3.29. Default.aspx User Interface Design

When you click the Get Machine Info button, it retrieves the machine name, host address, and local storage and calls the HelloWorkerRole service through an internal endpoint. You can also upload a file to the local storage using the upload file button. All the functions use traditional .NET APIs for retrieving local file and network information of the machine. If you are developing the service from scratch, you will have to add reference to the HelloWorkRole WCF service. In the HelloWebRole project, the reference has already been added for you in the ClientProxy.cs file. Listing 3-12 shows the code for calling the HelloWorkerRole WCF service

string wrIp =  RoleEnvironment.Roles["HelloWorkerRole"].Instances[0].
InstanceEndpoints["MyInternalEndpoint"].IPEndpoint.ToString();
lblWREndpointAddress.Text = wrIp;
var serviceAddress = new Uri(String.Format("net.tcp://{0}/{1}", wrIp,
 "helloservice"));
var endpointAddress = new EndpointAddress(serviceAddress);
var binding = new NetTcpBinding(SecurityMode.None);
var client = new ClientProxy(binding, endpointAddress);
lblWRHostName.Text = client.GetHostName();
lblWRIp.Text = client.GetMyIp();

In Listing 3-12, the Web role gets reference to the internal endpoint of a Worker role instance and instantiates the ClientProxy object to call the IHelloService methods GetHostName() and GetMyIp().

The ProAzureCommonLib project is a class library project containing two main files relevant to this example—WindowsAzureSystemHelper.cs and SystemMessageExchange.xsd. WindowsAzureSystemHelper.cs consists of a class WindowsAzureSystemHelper with all static helper methods. SystemMessageExchange.xsd is the dataset that defines the contract between the role instances and the WCF service. It was discussed previously in the "System Information Message" section. WindowsAzureSystemHelper class has four main sections of helper methods for logging, configuration, local storage, and system information.

public static void LogError(string message)
{
Trace.WriteLine(String.Format("{0} on machine {1}", message,
Environment.MachineName), "Error");

}
public static void LogInfo(string message)
{
Trace.WriteLine(String.Format("{0} on machine {1}", message,
Environment.MachineName), "Information");
}

public static bool GetBooleanConfigurationValue(string configName)
{
       try
       {
              bool ret;
              if (bool.TryParse
              (RoleEnvironment.GetConfigurationSettingValue(configName), out ret))
              {
              return ret;
              }
              else
              {
              LogError(String.Format

("Could not parse value for configuration setting {0}", configName));

              throw new Exception
              (String.Format("Could not parse value for configuration
 setting {0}", configName));
              }
       }
       catch (Exception ex)
       {
       LogError(ex.Message);
       throw ex;
       }
}

The local storage section contains helper methods for accessing Windows Azure local storage. Local storage is a file system directory on the server on which a particular role instance is running on. The contents of the local storage are not persistent across instance failures and restarts because the role may be redeployed to another virtual machine due to a failure or a restart. Listing 3-15 shows two static helper methods used for accessing the local storage.

public static string GetLocalStorageRootPath(string localStorageName)
{
       try
       {
              LocalResource resource = RoleEnvironment.
              GetLocalResource(localStorageName);
              return resource.RootPath;
       }
       catch (Exception ex)
       {
       LogError(String.Format("Error in GetLocalStorageRootPath of {0}. {1}",
       "WindowsAzureSystemHelper", ex.Message));
       throw ex;
       }
}
public static bool CanAccessLocalStorage(string localStorageName)
{
       WindowsAzureSystemHelper.LogInfo("Can access Local Storage?");
       bool ret = false;
       try

{
       string fp = WindowsAzureSystemHelper.
       GetLocalStorageRootPath(localStorageName) + "proazure.txt";
       using (StreamWriter sw = File.CreateText(fp))
       {
              WindowsAzureSystemHelper.LogInfo("Created File " + fp);
              sw.WriteLine("This is a Pro Azure file.");
              WindowsAzureSystemHelper.LogInfo("Wrote in File " + fp);
       }//using
       string fpNew = WindowsAzureSystemHelper.
       GetLocalStorageRootPath(localStorageName) + "proazure2.txt";
       File.Copy(fp, fpNew);
       string fpNew2 = WindowsAzureSystemHelper.
       GetLocalStorageRootPath(localStorageName) + "proazure3.txt";
       File.Move(fp, fpNew2);
       WindowsAzureSystemHelper.LogInfo("Deleting File " + fpNew2);
       File.Delete(fpNew2);
       WindowsAzureSystemHelper.LogInfo("Deleted File " + fpNew2);
       WindowsAzureSystemHelper.LogInfo("Deleting File " + fpNew);
       File.Delete(fpNew);
       WindowsAzureSystemHelper.LogInfo("Deleted File " + fpNew);
       ret = true;
       }
       catch (Exception ex)
       {
       WindowsAzureSystemHelper.LogError("Error in CanAccessSystemDir " + ex.Message);
       }
       return ret;
}

There are two methods defined in Listing 3-12: GetLocalStorageRootPath() and CanAccessLocalStorage(). The GetLocalStorageRootPath() method calls the RoleEnvironment.GetLocalResource() method and returns the root path property of the local storage. The CanAccessLocalStorage() executes a test to check whether the role instance can access the local storage by creating, copying, moving and deleting files. The method returns true if all the tests pass, otherwise it returns false. Both the methods accept local storage name as the parameter defined in the ServiceDefinition.csdef file.

The other two methods in the local storage section are WriteLineToLocalStorage() and ReadAllLinesFromLocalStorage(). The WriteLineToLocalStorage() appends a line of text to the specified file in the local storage. It also creates the file if it does not exist. The writeDuplicateEntries parameter is to specify whether duplicate entries are allowed in the file. The ReadAllLinesfromLocalStorage() method reads all the lines of text from the specified file in the local storage and returns them as an IList<string> data structure. Listing 3-16 shows code for both the methods.

public static void WriteLineToLocalStorage
(string fileName, string localStorageName, string message,
bool writeDuplicateEntries)
{

LogInfo(message);
        string path = GetLocalStorageRootPath(localStorageName);
        path = Path.Combine(path, fileName);
        string entry = String.Format("{0}{1}", message, Environment.NewLine);
        bool write = true;
        if (!writeDuplicateEntries)
        {
        if (!File.Exists(path))
        {
                 using (StreamWriter sw = File.CreateText(path))
                 {
                 }
        }
        string[] lines = File.ReadAllLines(path, Encoding.UTF8);
        if (lines != null && lines.Length > 0)
        {
                 if (lines.Contains<string>(message))
                 {
                  write = false;
                 }
        }
        }
        if (write)
        {
         File.AppendAllText(path, entry, Encoding.UTF8);
        }
}

public static IList<string> ReadAllLinesFromLocalStorage
(string fileName, string localStorageName)
{
        List<string> messages = new List<string>();
        string path = Path.Combine(GetLocalStorageRootPath(local
StorageName), fileName);
        if (File.Exists(path))
        {
                 using (FileStream stream = File.Open
                 (path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
                 {
                         StreamReader reader = new StreamReader(stream
, Encoding.UTF8);

                         while (true)
                         {
                                 string line = reader.ReadLine();
                                 if (line == null) break;
                                 messages.Add(line);
                         }
                 }
        }
        return messages;
}

The system information section contains only one helper method GetSystemInfo() for retrieving the system information and returning the SystemMessageExchange dataset. Listing 3-17 shows the code for GetSystemInfo() method.

public static SystemMessageExchange GetSystemInfo
(string localStorageName, string role)
{
try
{
        SystemMessageExchange ds = new SystemMessageExchange();
        SystemMessageExchange.SystemInfoRow row =
        ds.SystemInfo.NewSystemInfoRow();
        row.CurrentDirectory = Environment.CurrentDirectory;
        try
        {
          row.LocalStoragePath = GetLocalStorageRootPath(localStorageName);
        }
        catch (Exception ex1)
        {
          LogError(ex1.Message);

        }
        row.MachineName = Environment.MachineName;
        row.OSVersion = Environment.OSVersion.VersionString;

        string dir;
        if (CanAccessSystemDir(out dir))
        {
          row.SystemDirectory = dir;

        }

        if (CanAccessWindowsDir(out dir))
        {
          row.WindowsDirectory = dir;
        }
        row.UserDomainName = Environment.UserDomainName;
        row.UserName = Environment.UserName;
        row.Role = role;
        row.Timestamp = DateTime.Now.ToString("s");
        ds.SystemInfo.AddSystemInfoRow(row);

        return ds;

}
catch (Exception ex)
{

LogError("GetSystemInfo " + ex.Message);
}

return null;
}

The GetSystemInfo() method accepts the local storage name and the role name of the instance as the parameters. It then creates an instance of the SystemMessageExchange dataset and adds a new row to the SystemInfo DataTable in the dataset. The data row is filled with appropriate system information values and added back to the SystemInfo DataTable using the AddSystemInfoRow() method. The dataset is then returned from the function. Note that this method can be called from either the Web or Worker role to retrieve the system information from the underlying operating system.

This is the cloud service project created using the Web and Worker Cloud Service project template in Visual Studio.NET. It contains the ServiceDefinition.csdef and ServiceConfiguration.cscfg files. The project also holds references to the Web and Worker role projects. The Roles folder in the project contains references to the Web role (WebWorkerExchange_WebRole ) and the Worker role (WebWorkerExchange_WorkerRole ) projects from the same solution.

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WebWorkerExchange" xmlns="http://schemas.
microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole" enableNativeCodeExecution="true">
    <LocalStorage name="SystemInfoWebLocalCache" sizeInMB="10"/>
    <InputEndpoints>
<!-- Must use port 80 for http and port 443 for https when running in the cloud -->
      <InputEndpoint name="HttpIn" protocol="http" port="80" />
    </InputEndpoints>
    <ConfigurationSettings>
     <Setting name="DiagnosticsConnectionString" />
      <!--This is the current logging level of the service -->
      <Setting name="LogLevel"/>
      <Setting name="ThrowExceptions"/>
      <Setting name="EnableOnScreenLogging"/>
    </ConfigurationSettings>
  </WebRole>
  <WorkerRole name="WorkerRole" enableNativeCodeExecution="true">
    <LocalStorage name="SystemInfoWorkerLocalCache" sizeInMB="10"/>

<ConfigurationSettings>
     <Setting name="DiagnosticsConnectionString" />
      <!--This is the current logging level of the service -->
      <Setting name="LogLevel"/>
      <Setting name="ThreadSleepTimeInMillis"/>
      <Setting name="SystemInfoServiceURL"/>
    </ConfigurationSettings>
  </WorkerRole>
</ServiceDefinition>

<?xml version="1.0"?>
<ServiceConfiguration serviceName="WebWorkerExchange" xmlns="
http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
  <Role name="WebRole">
    <Instances count="1"/>
    <ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value="UseDevelopmentStorage=true" />
      <!--Supported Values are Critical,
      Error,Warning,Information,Verbose-->
      <Setting name="LogLevel" value="Information"/>
      <Setting name="ThrowExceptions" value="true"/>
      <Setting name="EnableOnScreenLogging" value="true"/>
    </ConfigurationSettings>
  </Role>
  <Role name="WorkerRole">
    <Instances count="2"/>
    <ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value="UseDevelopmentStorage=true" />
      <!--Supported Values are Critical,
      Error,Warning,Information,Verbose-->
        <Setting name="LogLevel" value="Information"/>
      <Setting name="ThreadSleepTimeInMillis" value="5000"/>

<Setting name="SystemInfoServiceURL"
value="http://localhost:81/SystemInfo.svc"/>
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

This is the Web role project in the cloud service that defines the SystemInfo WCF service (SystemInfo.svc) and the ASP.NET Page (Default.aspx) for displaying the system information of role instances.

public const string LOCAL_STORAGE_NAME = "SystemInfoWebLocalCache";
public const string SYSTEM_INFO_MACHINE_NAMES = "machines.txt";
public const string SYS_INFO_CACHE_XML = "SystemInfoCache.xml";
public static readonly SystemMessageExchange sysDS = new SystemMessageExchange();

public void SendSystemInfo(SystemMessageExchange ds)
{
if (ds != null && ds.SystemInfo.Rows.Count > 0)
{
        string machineName = ds.SystemInfo[0].MachineName;
        string machineLocalStoragePath = ds.SystemInfo[0].LocalStoragePath;
        //Log the message
        WindowsAzureSystemHelper.LogInfo(machineName + ">" + ds.GetXml());

        //Add machine names
        WindowsAzureSystemHelper.WriteLineToLocalStorage
        (SYSTEM_INFO_MACHINE_NAMES,LOCAL_STORAGE_NAME, machineName, false);

        //Copy the file to LocalStorage
        string localStoragePath = WindowsAzureSystemHelper.GetLocalStorageRootPath
        (LOCAL_STORAGE_NAME);

try
        {
                string query = String.Format
                ("MachineName = '{0}' AND LocalStoragePath = '{1}'",
                machineName, machineLocalStoragePath);
                WindowsAzureSystemHelper.LogInfo("Query = " + query);
                System.Data.DataRow[] dRows = sysDS.SystemInfo.Select(query);

                if (dRows != null && dRows.Length > 0)
                {
                sysDS.SystemInfo.Rows.Remove(dRows[0]);
                }

                sysDS.SystemInfo.Merge(ds.SystemInfo);
                sysDS.AcceptChanges();
                sysDS.WriteXml(Path.Combine(localStoragePath, SYS_INFO_CACHE_XML));
                WindowsAzureSystemHelper.LogInfo("SystemInfoCache.
xml -- " + sysDS.GetXml());

        }
        catch (Exception ex)
        {
        WindowsAzureSystemHelper.LogError("SendSystemInfo():" + ex.Message);
        }
}
else
{
WindowsAzureSystemHelper.LogInfo("SendSystemInfo(): null message received");

}
}

<services>
<service behaviorConfiguration="WebWorkerExchange_WebRole.System
InfoBehavior" name="WebWorkerExchange_WebRole.SystemInfo">
<endpoint address="" binding="basicHttpBinding"
contract="WebWorkerExchange_WebRole.ISystemInfo">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>

Default.aspx

The Default.aspx file is the home page for the Web role application. On a periodic basis, the Default.aspx page reads the machines.txt file and the serialized system information dataset from the local storage and displays it to the end user. Figure 3-49 illustrates the design of Default.aspx.

Figure 3.49. Default.aspx

The Default.aspx page has three main controls: an ASP.NET ListBox, a GridView, and an ASP.NET Ajax Timer control. The ListBox is used to display the contents of the messages.txt file from the local storage stored by the SystemInfo WCF service. The GridView is used for displaying the content of the system information dataset file stored in the local storage by the SystemInfo WCF service. The ListBox and the GridView are both placed on an AJAX update panel. The Timer control refreshes the UpdatePanel every 10 seconds. Listing 3-22 shows the Tick event of the Timer control in Default.aspx.cs.

Example 3.22. Default.aspx.cs

protected void Timer1_Tick(object sender, EventArgs e)
{
       ExecuteExchange();
       ListMachines();
}
private void ListMachines()
{
       try
       {
                IList<string> messages =
                WindowsAzureSystemHelper.ReadAllLinesFromLocalStorage(
                SystemInfo.SYSTEM_INFO_MACHINE_NAMES,
 SystemInfo.LOCAL_STORAGE_NAME);
                lbMachines.Items.Clear();
                foreach (string message in messages)
                {
                        lbMachines.Items.Add(message);
                }
                string sysInfoPath =
                Path.Combine(WindowsAzureSystemHelper.GetLocalStorageRootPath
                (SystemInfo.LOCAL_STORAGE_NAME), SystemInfo.SYS_INFO_CACHE_XML);
                if (File.Exists(sysInfoPath))
                {
                        string sysInfoFileContents = File.ReadAllText(sysInfoPath);
                        if (!string.IsNullOrEmpty(sysInfoFileContents))
                        {
                                SystemMessageExchange ds =
 new SystemMessageExchange();
                                ds.ReadXml(new StringReader(sysInfoFileContents));
                                GridView1.DataSource = ds.SystemInfo;
                                GridView1.DataBind();
                        }
                }
       }
       catch (Exception ex)
       {
       WindowsAzureSystemHelper.LogError(ex.Message);
       }
}

In Listing 3-22, I am using the helper methods from the WindowsAzureSystemHelper class. The first method WindowsAzureSystemHelper.ReadAllLinesFromLocalStorage() reads the machine names from machines.txt from the local storage. All the retrieved machine names are then added to the list box. Similarly, the dataset method ds.ReadXml() deserializes the dataset from the local storage and adds it as a data source to the GridView. So, every 10 seconds you will see the timestamp refreshed on the Default.aspx page.

This is the Worker role project for sending continuous system information to the SystemInfo WCF service in the Web role. A Worker role in the Windows Azure cloud is analogous to the Windows Service on a Windows Server system. As discussed earlier in this chapter, the Worker role class must inherit from the RoleEntryPoint abstract class In this example, I have implemented the OnStart() and Run() methods.

public override void Run()
{
       Trace.WriteLine("WebWorkerExchange_WorkerRole entry point
 called", "Information");
       WindowsAzureSystemHelper.LogInfo("Worker Process entry point called");
       ThreadSleepInMillis = WindowsAzureSystemHelper.GetIntConfigur
ationValue("ThreadSleepTimeInMillis");
       while (true)
       {
       ExecuteExchange();
       Thread.Sleep(ThreadSleepInMillis);
       WindowsAzureSystemHelper.LogInfo("Working");

       }
}

In Listing 3-23, the Run() method has an continuous while loop that executes the WCF method by calling a local method ExecuteExchange() and then goes to sleep for a configured amount of milliseconds. The core logic of the application is in the ExecuteExchange() method shown in Listing 3-24.

private void ExecuteExchange()
{
       try
       {
       SystemMessageExchange ds =
       WindowsAzureSystemHelper.GetSystemInfo(LOCAL_STORAGE_NAME, "Worker");
               if (ds == null)
               {
                       WindowsAzureSystemHelper.LogError
                       ("ExecuteExchange():SystemMessageExchange DataSet is null");
               }
               else
               {
                       WindowsAzureSystemHelper.LogInfo(ds.GetXml());
                       string url = WindowsAzureSystemHelper.Get
StringConfigurationValue
                       ("SystemInfoServiceURL");

                       CallSystemInfoService(url, ds);

}
       }
       catch (Exception ex)
       {
       WindowsAzureSystemHelper.LogError("ExecuteExchange():" + ex.Message);
       }
}

In Listing 3-24, there are two main method calls—WindowsAzureSystemHelper.GetSystemInfo() and CallSystemInfoService(). WindowsAzureSystemHelper.GetSystemInfo() is a helper method that returns the SystemMessageExchage dataset, and CallSystemInfoService() is a private method that calls the SystemInfo WCF service in the Web role. Listing 3-25 shows the code for CallSystemInfoService() method.

private void CallSystemInfoService(string url, SystemMessageExchange ds)
{
       SystemInfoService.SystemInfoClient client = null;
       BasicHttpBinding bind = new BasicHttpBinding();
       try
       {
               EndpointAddress endpoint = new EndpointAddress(url);
               client = new SystemInfoService.SystemInfoClient(bind, endpoint);
               client.SendSystemInfo(ds);
               WindowsAzureSystemHelper.LogInfo(
               String.Format("Sent message to Service URL {0}", url));


       }
       catch (Exception ex)
       {
       WindowsAzureSystemHelper.LogError("CallSystemInfoService():" + ex.Message);
       }
       finally
       {
               if (client != null)
               {
                       if (client.State == CommunicationState.Faulted)
                       client.Abort();
                       else
                       client.Close();
               }
       }
}

In Listing 3-25, I initialize the BasicHttpBinding object and then initialize the EndpointAddress object and pass the URL from the ServiceConfiguration.cscfg passed as a parameter to the method. Next, I instantiate the SystemInfo WCF service proxy class SystemInfoClient and call the SendSystemInfo() method with the SystemMessageExchange dataset as the parameter. At this time, the WCF method is invoked and the dataset sent to the SystemInfo WCF service in the Web role.

To run the application in the development fabric, press F5 or right-click the WebWorkerExchange project and select Debug

When the web application starts, it stars the Web role as well as the Worker role instances. The Web role starts a new browser window and loads Default.aspx. The Web role also starts the SystemInfo WCF service. As per the ServiceConfiguration.cscfg, the development fabric starts two instances of the Worker role.

Open the development fabric UI from the system tray icon or by going to All Programs

Figure 3.50. WebWorkerExchange in development fabric

In Figure 3-50, there are two Worker role instances and one Web role instance. The logs for all the instances are displayed in their respective consoles. You can click one of the green instance nodes to enlarge the console of that instance for more detailed log viewing.

Figure 3-51 illustrates the Default.aspx page with the system information from all the service instances.

Figure 3.51. Default.aspx showing system information

If you observe Default.aspx, you will see the Timestamp values change 10 seconds. You will also find it interesting to see the different system properties displayed in the GridView. Next, let's deploy the WebWorkerExchange cloud service to the Windows Azure cloud. The steps for deploying WebWorkerExchange cloud service to Windows Azure are the same as those you say earlier in this chapter:

Figure 3.54. Default.aspx in the staging environment

In Figure 3-54, note that all the three instances of the service are provisioned on different underlying servers. Also note the different system information sent by each instance, including the local storage directory, user domain, and user name. The user names under which the instances are run are GUIDs, which makes sense in an automatically provisioned infrastructure. Once you have tested the service in the staging environment, you can swap the staging environment with the production environment for deploying the service in production. Figure 3-55 shows the production deployment of the WebWorkerExchange in Windows Azure.

Figure 3.55. WebWorkerExchange in production