本文是Windows Azure AppFabric入门教学的第七篇文章。我们知道,AppFabirc由Service Bus 和 Access Control Service组成,为了提高大家学习的热情,我们以一款使用了Service Bus的命令行多人聊天示例程序为案例来进行讲解。
最终效果如下:
前置条件
为了使后续的教程能够顺利进行,请确保如下软件或组件已被安装:
请确保您以拥有一定的WCF编程经验,若没有,请浏览这里以快速的初步了解WCF。
最后请确保已创建了一个AppFabric项目和一个服务命名空间。请参考这里。
原理:
我们首先了解一下该多人聊天程序的运作原理。
为了实现多播通信模式,Service Bus提供了名为netEventRelayBinding的绑定(binding)方法。该绑定在WCF上实现了一个发布/订阅(publish/subscribe)通信模式,其允许多个应用程序来订阅发送至某端点的信息。发送给该端点的任何信息都会被所有应用程序接受到。
netEventRelayBinding允许多个监听者(listener)将自己注册到由第一个发送者(sender)指定的URI上,对于每一个服务宿主(service host),如果其拥有一个监听着相同URI的端点,其便会隐式的成为一个订阅者(subscriber)。如果某客户端向URI发送消息,该消息便会被当前所有订阅的端点接收到。
代码:
在了解了通信原理之后,我们来看看具体代码是如何编写的。
在Windows Azure Platform Training Kit - June Update 安装目录下,Labs/IntroServiceBus/Source/Ex03-MulticastSample/begin/CS目录下,打开MulticastSample.sln工程。
1.1打开App.config,将下图2处红框内语句删除。(注意,此举只为简化示例工程,我们会在后续的教程中讲解App.config配置文件的细节。)
1.2将下图2处红框内改为binding="netEventRelayBinding"。这是为了利用netEventRelayBinding的多播功能。
1.3将下图三处红框内文字替换为您在Windows Azure platform AppFabric portal处所注册得到的信息。
Service Namespace Domain,Issuer Name 和Issuer Key的具体位置请参照下图。
2.打开IMulticastContract.cs, 添加如下蓝框内代码。
public interface IMulticastContract
{
[OperationContract(IsOneWay = true)]
void Hello(string nickname);
[OperationContract(IsOneWay = true)]
void Chat(string nickname, string text);
[OperationContract(IsOneWay = true)]
void Bye(string nickname);
}
熟悉WCF编程的朋友们一定对此非常熟悉,如果无WCF编程经验,请花数分钟时间转至这里 迅速的了解一下WCF。值得注意的是,netEventRelayBinding要求WCF的接口协定只能暴露单向(one way)的操作,所以所有的操作需要被标记为 "IsOneWay=true",来表明该操作只有单一的输入信息,没有对应的输出信息。我们经常会碰到此类场景:某个操作,没有任何返回值,并且客户端并不关心调用成功与否,此时我们便可以将接口协定标记为one-way。当然,此类接口协定不能返回任何参数(返回值需声明为void),任何在服务端抛出的异常也不会返回至客户端。具体请参考这里。
3打开MulticastService.cs,添加如下蓝框内代码。
public class MulticastService : IMulticastContract
{
void IMulticastContract.Hello(string nickname)
{
Console.WriteLine("[" + nickname + "] joins");
}
void IMulticastContract.Chat(string nickname, string text)
{
Console.WriteLine("[" + nickname + "] says: " + text);
}
void IMulticastContract.Bye(string nickname)
{
Console.WriteLine("[" + nickname + "] leaves");
}
}
这些都是常规的WCF程序编写的固定套路。
4.打开Program.cs,添加如下蓝框内代码
public static void Main()
{
...
Console.WriteLine("Press [Enter] to exit");
Console.WriteLine();
channel.Hello(nickname);
string input = Console.ReadLine();
while (!string.IsNullOrEmpty(input))
{
channel.Chat(nickname, input);
input = Console.ReadLine();
}
channel.Bye(nickname);
channel.Close();
channelFactory.Close();
host.Close();
}
验证:
至此,代码已经创建完毕,我们已经可以进行调试了。
右击项目,Debug->Start new Instance
输入会话名,例如:team1,之后输入用户名,例如:nicolas。
再次以Start new Instance 启动另一调试实例,同样输入与之前相同的会话名,例如:team1,输入与之前不同的用户名,例如leola。
最终效果如图:
探析:
大家是否为此感到兴奋呢?究竟其内部原理如何呢?接下来我会为大家一探究竟!
打开Program.cs文件,如下图。
程序分为2部分,44行之前,程序以Server的角色运行,之后便成为Client角色。
我们会看到在server部分,代码会将Multicast服务托管至URI "sb://[yourServiceNamespace].servicebus.windows.net/[chatSessionName]/MulticastService/" 上。
此时,如果有另一个程序实例,运行,以同样的服务命名空间(ServiceNamespace)和会话名(SessionName),并试图监听同一个URI时会如何呢?
我们在之前提到过,在netEventRelayBinding 的binding模式下,如果端点监听的URI相同的话,其便会隐式的成为该URI的一个订阅者(subscriber)。
而在client部分,相信熟悉WCF的朋友都了然于胸了。当调用channel.Chat(nickname, input)时,由于netEventRelayBinding 特殊的通信模式,会将信息在订阅者之间进行组播。(注意,发送者也会被接收到信息)
不知道大家是否注意到,托管于Service Bus上的解决方案都只需通过URI便能向其发送或监听信息,这便会带来安全问题,我们可以通过ACS的帮助来确保其安全性,如果需要了解更多ACS方面的内容,敬请关注本博客。
好了,大家赶快动手试一下,进入奇妙的AppFabric世界吧!