本文将引导大家达成第一种功能：在Windows Azure上部署服务。后续文章将会介绍另两种功能。事实上，在Windows Azure入门教学系列 (一): 创建第一个WebRole程序里，大家已经尝试过部署一个最简单的服务：一个ASP.NET网站。是的，ASP.NET网站也可以称作一种服务。现在，你的ASP.NET程序不再是运行在你自己的服务器上，而是运行在云端了。但是，Windows Azure不仅仅支持常规网站，我们也完全可以把那些和用户界面无关的服务(headless services)部署至云端。例如，WCF服务，WF工作流，等等。而也正是这些headless services，使我们的web site摇身一变成为了Web API，让用户可以使用任意大小的屏幕，在任意场合，使用他们喜欢的客户端，访问我们的服务。本文将会教导大家如何在Windows Azure上部署一个WCF服务，作为入门教学，我们将使用最简单的SOAP Service。
如果你并不了解WCF，请自http://msdn.microsoft.com/en-us/netframework/aa663324.aspx开始学习。本文假设你已经了解了WCF的基础知识。
前期准备
想要在Windows Azure这样的负载平衡环境中使用WCF，首先必须下载一个hotfix。这个hotfix已经预装在云端的服务器上，但是如果你要在本地测试，还需要手工装到本机。这个hotfix解决了WCF的一些在负载平衡场合下可能出现的bug。
创建并观察项目
创建一个新的Cloud Service项目。选择添加一个WCF Service Web Role。
在这个入门教学中，我们将使用最基本的，默认生成的代码。以下是默认生成的OperationContracts：
[OperationContract]
string GetData(int value);
[OperationContract]
CompositeType GetDataUsingDataContract(CompositeType composite);
打开web.config，请注意默认生成的配置使用的便是basicHttpBinding。可是如果使用普通的WCF Service项目模板，你将会得到wsHttpBinding。注意wsHttpBinding默认使用Windows Authentication，在Windows Azure中Windows Authentication是不支持的，所以如果你使用普通的WCF Service项目模板，请记得修改wsHttpBinding的安全配置，或者改成使用basicHttpBinding。
负载平衡带来的问题
现在，运行项目，你会看到标准的WCF信息页面
请注意WSDL文件的地址并不正确，我们的服务应该是运行在81端口上，但是该页面确报告WSDL文件位于端口5100。假设你点击上述链接，将会得到一个400 Bad Request错误。即使你强制在浏览器中输入http://127.0.0.1:81/Service1.svc?wsdl，你会发现虽然的确可以看到WSDL文件，但是生成的WSDL文件并不正确，包含一系列诸如 这样的链接。如果你尝试在一个客户端程序中add service reference，就会遇上错误了。
以上，正是WCF默认的行为在负载平衡场合下会引发的问题。事实上，我们的服务的第一个实例(至少在本地模拟环境中)确实运行在端口5100上，如果你的Web Role有多个实例，第二个实例很可能会运行在端口5101上。但是负载平衡器对外暴露的端口永远是你在csdef文件中指定的端口(当然在本地因为80端口已经被IIS占用，不得不使用81端口)。WCF默认并不知道负载平衡器，所以它还是认为客户端必须访问端口5100。