Deploying services on Windows Azure Platform

Introduction
Before, we introduced the three main features of Windows Azure in the Windows Azure platform Introduction. That's computing, storage, and management. So far, through the previous teaching articles, you have become familiar with the storage capabilities of Windows Azure. Of course, storage is just one of the most basic functions. To give full play to the power of cloud computing, we have to learn how to "compute".

Also in the Windows Azure platform profile, we've covered three main computing features of Windows Azure:

As a deployment service platform
As a software distribution platform
As a general distributed computing platform
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 while you do see the WSDL file, the generated WSDL file is incorrect and contains a series of such things as <soap: addresslocation= "Http://lanxing-pc.fareast.corp.microsoft.com:5100/Service1.svc"/> Such links. 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.

Solve the problems caused by load balancing
Previously, we mentioned that the WCF team has developed a hotfix to solve the problems caused by load balancing. But in order to play the hotfix effect, a little configuration must be done.

First, find the service behavior in Web.config and add a behavior named Userequestheadersformetadataaddress. This behavior is installed through hotfix.

<behavior name= "Wcfservicewebrole1.service1behavior" >

<!--to avoid disclosing metadata information, set the value below to false and remove the metadata endpoint the adjective Deployment-->

<servicemetadata httpgetenabled= "true"/>

<!--to receive exception details in faults for debugging purposes and set the value below to true. Set to false unreported deployment to avoid disclosing exception information

<servicedebug includeexceptiondetailinfaults= "false"/>

<!--enable hotfix to troubleshoot port problems caused by load balancing. -->

<useRequestHeadersForMetadataAddress>

<defaultPorts>

<add scheme= "http" port= "/>"

<add scheme= "https" port= "443"/>

</defaultPorts>

</useRequestHeadersForMetadataAddress>

</behavior>

Again, in load balancing situations, the addresses the client requests are often different from the real addresses deployed by the service. So we recommend that you set Addressfiltermode to any so that you no longer check for address matching.

[ServiceBehavior (Addressfiltermode = addressfiltermode.any)]

public class Service1:iservice1

Now, run the program again, and you will see that port 81 has been successfully identified.

Deploy Web role to cloud
Please refer to Http://blogs.msdn.com/azchina/archive/2010/02/18/webrole.aspx to deploy the Web role to the cloud, which is exactly the same process. Whether you use ASP.net, use WCF, or use other techniques. This article is not repeated.

Now you can try to build a client program locally to access the service you just published, but this article will not detail how to access the service. In the next article, we'll distribute a piece of software from the cloud and let that software interact with our services and work together.

Summary
You can deploy any service on Windows Azure, and in order to give full play to the power of cloud computing, we often need not only to use web site such as ASP.net, but also to use a web API such as WCF to really pass through the cloud, Connect all kinds of clients.

Using WCF in Windows Azure is very similar to using WCF in general, but we have to be aware of the possible problems with load balancing and do our best to deal with it.

This article from Csdn Blog, reproduced please indicate the source: http://blog.csdn.net/azurechina/archive/2010/05/16/5597658.aspx