Worker Role Communication

In this hands-on lab, you will explore internal and external endpoints by implementing a WCF chat service and host it in a Windows Azure worker role.

Overview

Web roles in Windows Azure provide support for HTTP and HTTPS protocols through their endpoints. For other TCP/IP protocols and ports, external endpoints allow worker roles to expose Internet-facing services over ports other than 80 and 443. These endpoints can be bound to any process and provide the means to communicate externally using a variety of TCP-based application protocols.

Similarly, for inter-role communications, internal endpoints provide a way for roles to communicate directly with each other without the need to go through queues, although queues remain the preferred method for reliable asynchronous message processing.

In this hands-on lab, you will explore internal and external endpoints by implementing a WCF chat service and host it in a Windows Azure worker role.

The AzureTalk Service

In the solution, a Windows Azure worker role hosts the WCF service, which listens on an external TCP endpoint that you configure for this role. The service implements a duplex contract over a TCP channel that allows clients to register, send and receive messages, and receive notifications from the service over the same channel.

A typical exchange between the client application and the worker role service involves the following operations:

1. The client application announces its presence at this chat endpoint by calling the Register operation.
2. The client calls the GetConnectedClients operation to retrieve a list of users currently online.
3. The client calls the SendMessage operation to send messages to other active users.
4. The service calls the UpdateClientList operation to notify the client whenever other users connect or disconnect.
5. The service calls the DeliverMessage operation to forward messages sent to a client by other users.

In order for the service to deliver notifications and messages from other users, the client application needs to implement a callback contract, which the service specifies in its own contract using the CallbackContract attribute.

The contract for the chat service indicates that it requires sessions through its SessionMode setting. In addition, because the contract marks the Register operation as being initiating by means of the IsInitiating attribute, whenever a client invokes this particular operation, the WCF infrastructure establishes a session with the client and assigns an identifier to this session. Thereafter, and as long as the client maintains the session open, WCF assigns the same session ID to every operation invoked by the client and makes it available in the operation context through its SessionId property. The chat service uses this identifier to correlate every exchange from a particular client.

In addition to the WCF session, the chat service also maintains its own notion of a session, which allows it to keep track of each connected client. The service assigns a SessionInformation object to each active client and uses it to register information about its session. To manage sessions, the service keeps an internal dictionary of SessionInformation objects and uses the session ID assigned by WCF as the key to access the sessions it contains.

When creating a new session during client registration, the service records the session ID, a user name for the client, and a callback channel to the client. The callback channel allows the service to invoke operations on the client application including forwarding messages from peers and alerting when other users connect or disconnect. Additionally, the session contains an ID for the worker role where the client session is active. This piece of information will become significant in Exercise 2, when you implement an inter-role communication mechanism that enables communication between clients connected to different worker roles.

Because multiple clients using the service can read and update sessions concurrently, the service uses a SessionManager class to control access to the session information dictionary in a thread-safe manner.

The code provided with the lab already contains the chat service contracts, an implementation for the Session Manager, and a client application that you can use to test the service. During the course of the lab, you will configure the internal and external endpoints of the worker role and implement the chat service.

Objectives

In this hands-on lab, you will learn how to:

• Expose non-HTTP services in Windows Azure from a worker role through external endpoints
• Use internal endpoints for inter-role communication

Prerequisites

The following is required to complete this hands-on lab:

• IIS 7 (with ASP.NET, WCF HTTP Activation)
• Microsoft .NET Framework 4.0
• Microsoft Visual Studio 2010
• Windows Azure Tools for Microsoft Visual Studio 1.6

Setup

In order to execute the exercises in this hands-on lab you need to set up your environment.

1. Open a Windows Explorer window and browse to the lab’s Source folder.
2. Double-click the Setup.cmd file in this folder to launch the setup process that will configure your environment and install the Visual Studio code snippets for this lab.
3. If the User Account Control dialog is shown, confirm the action to proceed.

Using the Code Snippets

Throughout the lab document, you will be instructed to insert code blocks. For your convenience, most of that code is provided as Visual Studio Code Snippets, which you can use from within Visual Studio 2010 to avoid having to add it manually.

If you are not familiar with the Visual Studio Code Snippets, and want to learn how to use them, you can refer to the Setup.docx document in the Assets folder of the training kit, which contains a section describing how to use them.

Exercises

This hands-on lab includes the following exercises:

1. Using Worker Role External Endpoints
2. Using Internal Endpoints for Inter-Role Communication

Estimated time to complete this lab: 60 minutes.