Deploying WCF services on Windows Azure

This article will guide you through the first feature: Deploying Services on Windows Azure. Subsequent articles will introduce another two features. In fact, in the Windows Azure Introductory teaching series (I): Creating the first Webrole program, you've tried deploying one of the simplest services: a asp.net web site. Yes, ASP. NET Web site can also be called a service. Now, your ASP.net program is no longer running on your own server, it's running in the clouds. However, Windows Azure not only supports regular web sites, but we can also deploy those services that are not user interface-related (headless service) to the cloud. For example, WCF services, WF workflows, and so on. And it is these headless services that have turned our web site into a Web API that allows users to use any size screen, access our services on any occasion, using their favorite clients. This article will teach you how to deploy a WCF service on Windows Azure, and as an introductory instruction, we will use the simplest SOAP services.

If you do not know WCF, please start learning from http://msdn.microsoft.com/en-us/netframework/aa663324.aspx. This article assumes you already know the basics of WCF.

Pre-preparation

To use WCF in a load-balanced environment such as Windows Azure, you must first download a hotfix. This hotfix is already installed on the cloud server, but if you are testing locally, you will need to manually load the machine. This hotfix solves some of the WCF bugs that might occur in load-balancing situations.

Create and observe projects

Create a new cloud service project. Choose to add a WCF Service Web role.

In this introductory lesson, we will use the most basic, default generated code. The following are the default generated operationcontracts:

[OperationContract]

string GetData (int value);

[OperationContract]

Compositetype getdatausingdatacontract (Compositetype composite);

Open Web.config, note that the default generated configuration uses BasicHttpBinding. However, if you use the generic WCF Service project template, you will get wshttpbinding. Note Wshttpbinding defaults to using Windows Authentication, Windows authentication is not supported in Windows Azure, so if you use a generic WCF Service project template, Please remember to modify the Wshttpbinding security configuration, or change to use BasicHttpBinding.

Problems caused by load balancing

Now, run the project and you will see the standard WCF information page

Note that the WSDL file's address is not correct and our service should be running on port 81, but the page does report that the WSDL file is on port 5100. If you click on the link above, you will get a bad request error. Even if you force the input of http://127.0.0.1:81/Service1.svc?wsdl in the browser, you will find that although you do see the WSDL file, the generated WSDL file is incorrect and contains a series of links such as this one. If you try to add a service reference to a client program, you will get a mistake.

Above, it is the problem that WCF default behavior can cause in load balancing situations. In fact, the first instance of our service (at least in the local simulation environment) does run on port 5100, and if your Web role has multiple instances, the second instance is likely to run on port 5101. But the externally exposed port of the load balancer is always the port you specify in the Csdef file (of course, because 80 ports are already occupied by IIS and have to use 81 ports). WCF does not know the load balancer by default, so it still believes that the client must access port 5100.