【IT168 技术文档】首先还是在Web Role中定义一个临时的文件系统，然后再由Web Role提供一个WCF的服务，让Worker Role来调用，从而达到对这个临时文件系统的共享和写入。
第一篇：Azure Service探索:存储之本地存储
第二篇：Azure Service探索:存储之队列存储
第四篇：Azure Services探索:存储之表(Table)存储
其实变换一下，就是要解决如何在Azure 服务中提供一个 WCF服务，然后这个WCF如何被配置，以及被其他角色（Worker Role，其它的Web role）或另外一个Azure服务调用。
基本的界面设计如下，唉没创意，还是用之前的那个例子进行修改
前台的Web Role 界面没有变化，还是向一个LocalStorage中写入消息，但同时也提供一个WCF的服务，也可以向这个LocalStorage写入消息，而后台的Worker Role就定期的调用这个WCF服务，写入Ping信息。
流程确定之后，就可以开始操作了。
首先还是创建一个Web Role + Worker Role的项目
接着在服务定义文件中定义文件存储，然后再Web Role中复制之前的代码。F5 运行，没有问题，然后我们开始增加WCF服务
点击Web Role项目，选择增加一个新的选项(Add New Item)，如下图，
之后定义一个WCF的ServiceContract
2:
3: {
4:
5: [ServiceContract]
6:
7: public interface IMessageLogger
8:
9: {
10:
11: [OperationContract]
12:
13: void LogMessage(string message);
14:
15: }
16:
17: }
18:
然后在myMessageLogger.svc.cs中实现这个Interface，具体的实现非常简单，就是向文件存储中写消息。
之后我们需要检查和确认WCF的配置文件，并做一个的改动，将WSHttpBinding 修改成 BasicHttpBinding ，如下图：
关于BasicHttpBinding和WSHttpBinding的差异，可以参见文章最后一些链接。除了性能，对WS-*的协议支持，Session/事务等支持的不同，Security Mode and the Client Credential Type in WCF文章中给出了不错的建议： If broad reach across platforms is your goal, there's no better choice today than using the WS-I basic profile over SSL which of course would also mean using basicHttpBinding instead of wsHttpBinding. It's important to note that this particular binding doesn't provide CIA by default.
之后可以F5 启动我们的Azure 服务，然后访问WCF的地址http://localhost/myMessageLogger.svc，测试一下WCF服务是否能够正确地运行。
然后我在我的开发环境就出现了下面这个错误页面：
从这个界面可以发现一些有趣的现象，第一 , Azure 使用了另外一个端口 127.0.0.1:5100，第二，证明BasicHttpBinding的确默认没有带安全标示。
看到左边的Detail Error Information感觉.svc 文件好像根本没有进程来Handler，感觉IIS7 用一个静态文件的进程在处理，思考了两分钟，头脑中闪现了WAS，然后去控制面板检查，发现果然WAS (Windows Process Activation Service)没有安装.
然后退出Visual Studio 转为系统安装，我是运行在Windows Server 2008上，安装WAS的界面如下：
安装之后，都不用重新启动，继续F5 运行，这下WCF服务可以访问了
根据之前的设计，目前的任务已经完成了一半了，我们已经成功在一个Web Role中发布了一个记录消息的WCF服务，剩下的工作是要在Worker Role中调用这个WCF服务。
现在可以点击Worker Role项目，然后选择添加服务引用（Add Service Reference）
这里有个小小的技巧，因为现在在开发调试环境，WCF服务并没有运行，这时你可以先在地址框输入http://localhost/myMessageLogger.svc 然后点击Discover 按钮，然后地址框中的端口号自动变了，这时是本机的ASP.NET Web Development Server启动了产生的新的端口号，我们现在只是要增加一个引用，1030端口不是Azure运行WCF的端口，如果有端口应该是我们刚刚在错误页面看到的5100。增加好WCF服务引用之后，要记得修改Worker role 的app.config配置文件，去掉<Endpoint address>中地址的端口号，保持http://localhost/myMessageLogger.svc 的配置。
之后可以编写Worker Role的代码，通过WCF Proxy往Web Role的文件存储中增加消息了。
2:
3: {
4:
5: // This is a sample worker implementation. Replace with your logic.
6:
7: RoleManager.WriteToLog("Information", "Worker Process entry point called");
8:
9: string wcf_url = "http://localhost/myMessageLogger.svc";
10:
11: while (true)
12:
13: {
14:
15: Thread.Sleep(10000);
16:
17: BasicHttpBinding bind = new BasicHttpBinding();
18:
19: EndpointAddress endpoint = new EndpointAddress(wcf_url);
20:
21: HostingWCFServices.MessageLoggerClient client = new HostingWCFServices_WorkerRole.HostingWCFServices.MessageLoggerClient(bind, endpoint); 22:
23: client.LogMessage("Ping from WorkerRole");
24:
25: RoleManager.WriteToLog("Information", "Ping from WorkerRole-WCF MessageLoggerClient");
26:
27: if (client.State == CommunicationState.Faulted)
28:
29: client.Abort();
30:
31: else
32:
33: client.Close();
34:
35: }
36:
37: }
38:
这样后台Worker Role的代码也完成了，然后F5 运行。运行界面如下：
通过在Web Role中Hosting WCF Services可以让我们找到另外一个共享Azure能力或服务的途径，共享和暴露出来的WCF可以给Azure Services的其他角色使用，也可以提供给云端之外的应用和客户端使用，这也是Windows Azure平台提供应用组合的一个强有力的工具和途径。
另外最后的体验中，我们也尝试了使用Worker Role调用和消费这个WCF服务，同样这也向我们指明了另外一个应用整合的途径，我们的Azure Services本身也可以消费来自其他Windows Azure平台或Internet上的服务和能力。而Azure Services的WebRole和Worker Role的体系架构也让看到云端应用的特色和优美之处。
