Worker Role Communication in Windows Azure, Part 1

In an earlier post we talked about the “Asynchronous Web/Worker Role Pattern” in Windows Azure. In this pattern the web roles are “client facing” and expose an http endpoint. In Azure a web role is essentially a virtual machine running IIS while a worker role is a background process that is usually not visible to the outside world. The web roles communicate with the worker roles via asynchronous messages passed through a queue. Even though it is relatively simple this basic architecture is at the heart of many highly scalable Azure applications.

There are, however, other ways in which roles can communicate internally or externally. This allows for considerable flexibility when implementing Azure based solutions. A worker role, for example, could be directly exposed to the outside world (through a load balancer, of course!) and communicate over tcp (or other) protocol. This might be useful in a solution which required, for some reason, a highly customized application server exposed over the Internet. It is also possible for worker roles to communicate directly with other worker roles internally. Often the internal communication is done over tcp but other protocols can be used internally as well.

In the first of this two part series we will explore the basics of exposing an external (i.e. available over the Internet) endpoint to a worker role over tcp. We will use this to implement a simple client/server version of a “math service”. Note that this is not something you would ever necessarily want to do in practice! It is used here simply as an example of how to enable the communication. In the real world the “math service” could be replaced by whatever custom application service was required.

As usual to get started, we use Visual Studio 2010 to create a Cloud Service project. We add a single worker role into that project. We can then define an “InputEndpoint” (which is Microsoft’s term for an endpoint that is visible to the external world). An InputEndpoint has a name, a protocol and a port number.

This definition is done in the ServiceDefinition.csdef file (some details omitted for clarity):

<?xml version=“1.0” encoding=“utf-8”?>
<ServiceDefinition … >
  <WorkerRole name=“Square.Service”>
      <Setting … />
      <InputEndpoint name=“SquareEndpoint” protocol=“tcp” port=“2345” />

Note that the port number (in this case I have arbitrarily chosen 2345) is the port number that the Load Balancer is listening on. You need to make an API call to get the actual internal to Azure endpoint as follows:


Hopefully a demo will make this clearer:
Note that this demo is very minimal and does not necessarily demonstrate good design or programming practice. The sole purpose is to show how an Azure worker role can communicate with the external world over tcp.

By opening up role communication in this way Microsoft has given us lots of options to implement a wide variety of design architectures in Azure. In a future post we will examine how roles can also directly communicate with other roles internally.

Kevin Kell

As cloud computing continues to make information technology headlines, vendors are aggressively promoting the many benefits it can provide organizations.  Our White Paper, Cloud Computing Promises: Fact of Fiction, addresses the claims and questions that are often raised in relation to cloud computing and provides a clear view of what the cloud can—and can’t—deliver in reality.

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.