[WCF-Discovery]如何利用”发现代理”实现可用服务的实时维护?
2011-10-26 09:12
1161 查看
上面的内容大部分是围绕着Ad-Hoc模式展开介绍的。Managed模式和Ad-Hoc不同之处在于可用服务的终结点通过发现代理来统一管理。客户端在进行可用目标服务探测和解析的时候不再需要发送广播请求,而是直接向发现代理进行探测和解析请求就可以了。[源代码从这里下载]
在Ad-Hoc模式下,我们采用UdpAnnouncementEndpoint实现了广播式的通知,而在Managed模式则直接使用AnnouncementEndpoint终结点进行单播式的通知。该终结点的地址就是发现代理的地址。同理,在Ad-Hoc模式下我们进行广播式服务探测和解析是通过UdpDiscoveryEndpoint终结点来进行的,在Managed模式下我们可以直接使用DiscoveryEndpoint终结点实现客户端向发现代理单方面的可用服务的探测和解析请求。
发现代理部仅仅局限于Managed模式,同样可以使用在Ad-Hoc模式下。在Ad-Hoc模式下,发现代理可以像目标服务一样监听来自客户端发出的广播式的Probe/Resolve请求,也可以像客户端一样监听来自服务端发出的广播式的Helle/Bye通知。所以UdpDiscoveryEndpoint和UdpAnnouncementEndpoint同样可以应用在发现代理上。
发现代理本质上就是一个服务,它的核心功能就是接收客户端发送的针对可用服务探测和解析的Probe/Resolve请求,并回复以相应的PM和RM消息。至于上面提到的对目标服务上/下线通知监听能力只是具体实现对可用服务维护的一种方式而已。
所以说要自己从头到尾去定义这么一个发现代理服务并不是一件容易的事情。为了使开发人员可以无需关注具体的消息交换的细节,帮助他们容易的定义发现代理,WCF提供了一个抽象类DiscoveryProxy。我们只需要将我们自定义的发现代理服务类型继承该类并且重写相应的方法就可以了。
下面的代码给出了DiscoveryProxy的核心方法的定义。正如我们上面的分析,作为一个完备的发现代理服务应该实现DiscoveryEndpoint和AnnouncementEndpoint终结点所实现的所有服务契约,在这里得到了证实。DiscoveryProxy定义了4组抽象的OnBegingXxx/OnEndXxx方法,分别针四个基本的服务发现操作(消息交换):服务探测(Probe/PM)、服务解析(Resolve/RM)、上线通知(Hello)和离线通知(Bye)。作为继承自DiscoveryProxy的自定义发现代理服务,只需要重写这些抽象方法既可。
[/code]
[/code]
我们来创建我们自定义如下一个发现代理服务DiscoveryProxyService,我们通过在类型上应用ServiceBehaviorAttribute特性将DiscoveryProxyService定义成一个单例服务,并且支持并发。
[/code]
DiscoveryProxyService具有个IDictionary<EndpointAddress, EndpointDiscoveryMetadata>类型的属性Endpoints表述可用的目标服务列表。在处理服务上线通知的OnBeginOnlineAnnouncemen/OnEndOnlineAnnouncement方法中讲代表上线服务的EndpointDiscoveryMetadata添加到Endpoints列表中。而在处理服务离线通知的OnBeginOfflineAnnouncement/OnEndOfflineAnnouncement方法中则将代表离线服务的EndpointDiscoveryMetadata从Endpoints列表中移除。
而处理客户端服务探测请求的OnBeginFind/OnEndFind方法中,从传入的FindRequestContext中获得代表匹配条件的FindCriteria对象,并通过它从Endpoints列表中找到匹配的EndpointDiscoveryMetadata,最终通过调用的AddMatchingEndpoint方法将它们添加到FindRequestContext之中。至于用于处理服务解析请求的OnBeginResolve/ OnEndResolve则只需要从Endpoints列表中将与给定的终结点地址一致的EndpointDiscoveryMetadata返回就可以了。
[/code]
首先,一个包含ServiceDiscoveryBehavior的默认服务行为被定义,它将会自动应用到寄宿的两个服务上。对于发现代理服务DiscoveryProxyService,它具有两个采用NetTcpBinding绑定的标准终结点。其中一个地址为“net.tcp://127.0.0.1:8888/discoveryproxy/probe”,isSystemEndpoint属性被设置成False(这个设置是必需的)的DiscoveryEndpoint终结点。另一个则是地址为“net.tcp://127.0.0.1:9999/discoveryproxy/announcement”的AnnouncementEndpoint终结点。
至于目标服务CalculatorService,应用了一个名称为serviceAnnoucement的服务行为。通过这个服务行为为它添加了一个AnnouncementEndpoint终结点。该终结点采用NetTcpBinding,而地址则是发现代理服务AnnouncementEndpoint终结点的地址“net.tcp://127.0.0.1:9999/discoveryproxy/announcement”。
然后我们通过如下一段简单的代码来同时寄宿发现代理服务DiscoveryProxyService和目标服务CalculatorService。由于目标服务CalculatorService是在发现代理服务之后开启,所以在它开启之后会自动向发现服务发送一个上线的通知,而发现代理在接收到通知之后会将目标服务的EndpointDiscoveryMetadata添加到Endpoints列表中。
[/code]
[/code]
而真正服务调用的代码和调用普通服务没有两样。完成所有的配置和编码工作之后,先后启动服务和客户端程序,你会发现客户端控制台具有如下的输出结果,表示服务调用成功完成。
[/code]
输出结果:
[/code]
目录
一、发现代理与Managed发现模式
二、通过继承DiscoveryProxy创建发现代理
三、实例演示:自定义发现代理服务
步骤一、创建自定义发现代理服务
步骤二、寄宿发现代理服务和目标服务
步骤三、服务的动态调用
一、发现代理与Managed发现模式
二、通过继承DiscoveryProxy创建发现代理
三、实例演示:自定义发现代理服务
步骤一、创建自定义发现代理服务
步骤二、寄宿发现代理服务和目标服务
步骤三、服务的动态调用
一、发现代理与Managed发现模式
至于发现服务如何进行可用服务的实时维护,则是具体实现上的选择问题。不过WS-Discovery通过目标服务的通知机制来解决发现代理维护的服务的实时可用性。具体来说就是赋予了发现代理监听服务上下线通知的能力,并根据接收到的通知来进行可用服务的动态注册和注销。不过与Ad-Hoc模式下采用广播模式的通知不同,在Managed模式下,目标服务只需要专门针对发现代理发送通知就可以了。在Ad-Hoc模式下,我们采用UdpAnnouncementEndpoint实现了广播式的通知,而在Managed模式则直接使用AnnouncementEndpoint终结点进行单播式的通知。该终结点的地址就是发现代理的地址。同理,在Ad-Hoc模式下我们进行广播式服务探测和解析是通过UdpDiscoveryEndpoint终结点来进行的,在Managed模式下我们可以直接使用DiscoveryEndpoint终结点实现客户端向发现代理单方面的可用服务的探测和解析请求。
发现代理部仅仅局限于Managed模式,同样可以使用在Ad-Hoc模式下。在Ad-Hoc模式下,发现代理可以像目标服务一样监听来自客户端发出的广播式的Probe/Resolve请求,也可以像客户端一样监听来自服务端发出的广播式的Helle/Bye通知。所以UdpDiscoveryEndpoint和UdpAnnouncementEndpoint同样可以应用在发现代理上。
发现代理本质上就是一个服务,它的核心功能就是接收客户端发送的针对可用服务探测和解析的Probe/Resolve请求,并回复以相应的PM和RM消息。至于上面提到的对目标服务上/下线通知监听能力只是具体实现对可用服务维护的一种方式而已。
二、通过继承DiscoveryProxy创建发现代理
发现服务本质上就是一个WCF服务,并且这个服务实现的服务契约定义的操作应该基于定义在WS-Discovery中的几种基本的消息交换:Probe/PM、Resolve/RM和Hello/Bye。交换的消息在针对不同版本的WS-Discovery(WSDiscoveryApril2005、WSDiscovery11和WSDiscoveryCD1)又具有不同的要求。即使针对某个具体版本的WS-Discovery,Probe/PM和Resolve/RM的消息也会因采用Ad-Hoc或者Managed模式又有所不同。如果你需要创建一个同时支持不同版本WS-Discovery的发现代理服务,就应该实现DiscoveryEndpoint和AnnouncementEndpoint终结点所实现的所有服务契约。所以说要自己从头到尾去定义这么一个发现代理服务并不是一件容易的事情。为了使开发人员可以无需关注具体的消息交换的细节,帮助他们容易的定义发现代理,WCF提供了一个抽象类DiscoveryProxy。我们只需要将我们自定义的发现代理服务类型继承该类并且重写相应的方法就可以了。
下面的代码给出了DiscoveryProxy的核心方法的定义。正如我们上面的分析,作为一个完备的发现代理服务应该实现DiscoveryEndpoint和AnnouncementEndpoint终结点所实现的所有服务契约,在这里得到了证实。DiscoveryProxy定义了4组抽象的OnBegingXxx/OnEndXxx方法,分别针四个基本的服务发现操作(消息交换):服务探测(Probe/PM)、服务解析(Resolve/RM)、上线通知(Hello)和离线通知(Bye)。作为继承自DiscoveryProxy的自定义发现代理服务,只需要重写这些抽象方法既可。
[code] public abstract class DiscoveryProxy : IAnnouncementContractApril2005, IAnnouncementContract11, IAnnouncementContractCD1, IDiscoveryContractAdhocApril2005, IDiscoveryContractManagedApril2005, IDiscoveryContractApril2005, IDiscoveryContractAdhoc11, IDiscoveryContractManaged11, IDiscoveryContractAdhocCD1, IDiscoveryContractManagedCD1, ... { //Find(Probe) protected abstract IAsyncResult OnBeginFind(FindRequestContext findRequestContext, AsyncCallback callback, object state); protected abstract void OnEndFind(IAsyncResult result); //Resolve protected abstract IAsyncResult OnBeginResolve(ResolveCriteria resolveCriteria, AsyncCallback callback, object state); protected abstract EndpointDiscoveryMetadata OnEndResolve(IAsyncResult result); //Online Announcement(Hello) protected abstract IAsyncResult OnBeginOnlineAnnouncement(DiscoveryMessageSequence messageSequence, EndpointDiscoveryMetadata endpointDiscoveryMetadata, AsyncCallback callback, object state); protected abstract void OnEndOnlineAnnouncement(IAsyncResult result); //Offline Announcement(Bye) protected abstract IAsyncResult OnBeginOfflineAnnouncement(DiscoveryMessageSequence messageSequence, EndpointDiscoveryMetadata endpointDiscoveryMetadata, AsyncCallback callback, object state); protected abstract void OnEndOfflineAnnouncement(IAsyncResult result); //其他成员 }
[/code]
三、实例演示:自定义发现代理服务
接下来我们将通过一个简单的实例演示如何自定义发现代理服务,以及如何利用这个发现代理构建一个基于Managed模式的服务发现环境以实现服务的自动注册和服务的动态调用。实例解决方法依然采用之前的结构,并且直接使用定义好的CalculatorService作为目标服务。步骤一、创建自定义发现代理服务
我们首先通过继承DiscoveryProxy创建一个自定义的发现代理服务,我们将它起名为DiscoveryProxyService。由于我们要重写的方法都是异步模式的,OnBeginXxx的输出和OnEndXxx的输入都是一个IAsyncResult类型的对象,所以我们先要定义一个实现IAsyncResult接口的类型。为了简单起见,我们在Servie项目中定义的如下一个最为简单的DiscoveryAsyncResult(其实它根本起不到异步执行的目的)。[code] using System; using System.ServiceModel.Discovery; using System.Threading; namespace Artech.WcfServices.Service { public class DiscoveryAsyncResult : IAsyncResult { public object AsyncState { get; private set; } public WaitHandle AsyncWaitHandle { get; private set; } public bool CompletedSynchronously { get; private set; } public bool IsCompleted { get; private set; } public EndpointDiscoveryMetadata Endpoint { get; private set; } public DiscoveryAsyncResult(AsyncCallback callback, object asyncState) { this.AsyncState = asyncState; this.AsyncWaitHandle = new ManualResetEvent(true); this.CompletedSynchronously = this.IsCompleted = true; if (callback != null) { callback(this); } } public DiscoveryAsyncResult(AsyncCallback callback, object asyncState, EndpointDiscoveryMetadata Endpoint) : this(callback, asyncState) { this.Endpoint = Endpoint; } } }
[/code]
我们来创建我们自定义如下一个发现代理服务DiscoveryProxyService,我们通过在类型上应用ServiceBehaviorAttribute特性将DiscoveryProxyService定义成一个单例服务,并且支持并发。
[code] using System; using System.Collections.Generic; using System.Linq; using System.ServiceModel; using System.ServiceModel.Discovery; namespace Artech.WcfServices.Service { [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,ConcurrencyMode = ConcurrencyMode.Multiple)] public class DiscoveryProxyService : DiscoveryProxy { public IDictionary<EndpointAddress, EndpointDiscoveryMetadata> Endpoints { get; private set; } public DiscoveryProxyService() { this.Endpoints = new Dictionary<EndpointAddress, EndpointDiscoveryMetadata>(); } //Find(Probe) protected override IAsyncResult OnBeginFind(FindRequestContext findRequestContext, AsyncCallback callback, object state) { var endpoints = from item in this.Endpoints where findRequestContext.Criteria.IsMatch(item.Value) select item.Value; foreach (var endppint in endpoints) { findRequestContext.AddMatchingEndpoint(endppint); } return new DiscoveryAsyncResult(callback, state); } protected override void OnEndFind(IAsyncResult result) {} //Resolve protected override IAsyncResult OnBeginResolve(ResolveCriteria resolveCriteria, AsyncCallback callback, object state) { EndpointDiscoveryMetadata endpoint = null; if (this.Endpoints.ContainsKey(resolveCriteria.Address)) { endpoint = this.Endpoints[resolveCriteria.Address]; } return new DiscoveryAsyncResult(callback, endpoint); } protected override EndpointDiscoveryMetadata OnEndResolve(IAsyncResult result) { return ((DiscoveryAsyncResult)result).Endpoint; } //OnlineAnnouncement protected override IAsyncResult OnBeginOnlineAnnouncement(DiscoveryMessageSequence messageSequence, EndpointDiscoveryMetadata endpointDiscoveryMetadata, AsyncCallback callback, object state) { this.Endpoints[endpointDiscoveryMetadata.Address] = endpointDiscoveryMetadata; return new DiscoveryAsyncResult(callback, state); } protected override void OnEndOnlineAnnouncement(IAsyncResult result) {} //OfflineAnnouncement protected override IAsyncResult OnBeginOfflineAnnouncement(DiscoveryMessageSequence messageSequence, EndpointDiscoveryMetadata endpointDiscoveryMetadata, AsyncCallback callback, object state) { if (this.Endpoints.ContainsKey(endpointDiscoveryMetadata.Address)) { this.Endpoints.Remove(endpointDiscoveryMetadata.Address); } return new DiscoveryAsyncResult(callback, state); } protected override void OnEndOfflineAnnouncement(IAsyncResult result) {} } }
[/code]
DiscoveryProxyService具有个IDictionary<EndpointAddress, EndpointDiscoveryMetadata>类型的属性Endpoints表述可用的目标服务列表。在处理服务上线通知的OnBeginOnlineAnnouncemen/OnEndOnlineAnnouncement方法中讲代表上线服务的EndpointDiscoveryMetadata添加到Endpoints列表中。而在处理服务离线通知的OnBeginOfflineAnnouncement/OnEndOfflineAnnouncement方法中则将代表离线服务的EndpointDiscoveryMetadata从Endpoints列表中移除。
而处理客户端服务探测请求的OnBeginFind/OnEndFind方法中,从传入的FindRequestContext中获得代表匹配条件的FindCriteria对象,并通过它从Endpoints列表中找到匹配的EndpointDiscoveryMetadata,最终通过调用的AddMatchingEndpoint方法将它们添加到FindRequestContext之中。至于用于处理服务解析请求的OnBeginResolve/ OnEndResolve则只需要从Endpoints列表中将与给定的终结点地址一致的EndpointDiscoveryMetadata返回就可以了。
步骤二、寄宿发现代理服务和目标服务
现在我们需要寄宿上面创建的自定义发现代理服务DiscoveryProxyService和代表目标服务的CalculatorService,我们把所有的设置都定义在如下的配置中。[code] <configuration> <system.serviceModel> <services> <service name="Artech.WcfServices.Service.DiscoveryProxyService"> <endpoint address="net.tcp://127.0.0.1:8888/discoveryproxy/probe" binding="netTcpBinding" kind="discoveryEndpoint" isSystemEndpoint="false" /> <endpoint address="net.tcp://127.0.0.1:9999/discoveryproxy/announcement" binding="netTcpBinding" kind="announcementEndpoint"/> </service> <service name="Artech.WcfServices.Service.CalculatorService" behaviorConfiguration="serviceAnnoucement"> <endpoint address="http://127.0.0.1:3721/calculatorservice" binding="ws2007HttpBinding" contract="Artech.WcfServices.Service.Interface.ICalculator" /> </service> </services> <behaviors> <serviceBehaviors> <behavior> <serviceDiscovery/> </behavior> <behavior name="serviceAnnoucement"> <serviceDiscovery> <announcementEndpoints> <endpoint kind="announcementEndpoint" address="net.tcp://127.0.0.1:9999/discoveryproxy/announcement" binding="netTcpBinding"/> </announcementEndpoints> </serviceDiscovery> </behavior> </serviceBehaviors> </behaviors> </system.serviceModel> </configuration>
[/code]
首先,一个包含ServiceDiscoveryBehavior的默认服务行为被定义,它将会自动应用到寄宿的两个服务上。对于发现代理服务DiscoveryProxyService,它具有两个采用NetTcpBinding绑定的标准终结点。其中一个地址为“net.tcp://127.0.0.1:8888/discoveryproxy/probe”,isSystemEndpoint属性被设置成False(这个设置是必需的)的DiscoveryEndpoint终结点。另一个则是地址为“net.tcp://127.0.0.1:9999/discoveryproxy/announcement”的AnnouncementEndpoint终结点。
至于目标服务CalculatorService,应用了一个名称为serviceAnnoucement的服务行为。通过这个服务行为为它添加了一个AnnouncementEndpoint终结点。该终结点采用NetTcpBinding,而地址则是发现代理服务AnnouncementEndpoint终结点的地址“net.tcp://127.0.0.1:9999/discoveryproxy/announcement”。
然后我们通过如下一段简单的代码来同时寄宿发现代理服务DiscoveryProxyService和目标服务CalculatorService。由于目标服务CalculatorService是在发现代理服务之后开启,所以在它开启之后会自动向发现服务发送一个上线的通知,而发现代理在接收到通知之后会将目标服务的EndpointDiscoveryMetadata添加到Endpoints列表中。
[code] using System; using System.ServiceModel; namespace Artech.WcfServices.Service { class Program { static void Main(string[] args) { using(ServiceHost discoveryProxyService = new ServiceHost(typeof(DiscoveryProxyService))) using (ServiceHost calculatorService = new ServiceHost(typeof(CalculatorService))) { discoveryProxyService.Open(); calculatorService.Open(); Console.Read(); } } } }
[/code]
步骤三、服务的动态调用
现在我们需要让客户端在不知道目标服务终结点地址的情况下进行服务的动态调用。我们直接使用DynamicEndpoint标准终结点。下面的XML片断代表客户端程序的配置,在这段配置中定义了唯一一个用于调用CalclatorService的DynamicEndpoint终结点。为了让这个DynamicEndpoint终结点通过请求我们寄宿的发现代理服务进行了可用服务的探测,我们为它添加了一个采用NetTcpBindg的DiscoveryEndpoint终结点,该终结点的地址为“net.tcp://127.0.0.1:8888/discoveryproxy/probe”。[code] <configuration> <system.serviceModel> <client> <endpoint name="calculatorService" kind="dynamicEndpoint" endpointConfiguration="unicastEndpoint" binding="ws2007HttpBinding" contract="Artech.WcfServices.Service.Interface.ICalculator"/> </client> <standardEndpoints> <dynamicEndpoint> <standardEndpoint name="unicastEndpoint"> <discoveryClientSettings> <endpoint kind="discoveryEndpoint" address="net.tcp://127.0.0.1:8888/discoveryproxy/probe" binding="netTcpBinding"/> </discoveryClientSettings> </standardEndpoint> </dynamicEndpoint> </standardEndpoints> </system.serviceModel> </configuration>
[/code]
而真正服务调用的代码和调用普通服务没有两样。完成所有的配置和编码工作之后,先后启动服务和客户端程序,你会发现客户端控制台具有如下的输出结果,表示服务调用成功完成。
[code] using System; using System.ServiceModel; using Artech.WcfServices.Service.Interface; namespace Artech.WcfServices.Client { class Program { static void Main(string[] args) { using (ChannelFactory<ICalculator> channelFactory = new ChannelFactory<ICalculator>("calculatorService")) { ICalculator calculator = channelFactory.CreateChannel(); Console.WriteLine("x + y = {2} when x = {0} and y = {1}", 1, 2, calculator.Add(1, 2)); } Console.Read(); } } }
[/code]
输出结果:
[code] x + y = 3 when x = 1 and y = 2
[/code]
相关文章推荐
- [WCF-Discovery] 实例演示:如何利用服务发现机制实现服务的“动态”调用?
- 【远程调用框架】如何实现一个简单的RPC框架(三)优化一:利用动态代理改变用户服务调用方式
- [WCF-Discovery]服务如何能被”发现”
- [WCF-Discovery] 客户端如何能够“探测”到可用的服务?
- 跨集群服务——如何利用Kubernetes 1.3实现跨区高可用
- dubbo的服务发现和注册如何实现
- 我的WCF之旅(5):面向服务架构(SOA)和面向对象编程(OOP)的结合——如何实现Service Contract的重载(Overloading)
- 我的WCF之旅(7):面向服务架构(SOA)和面向对象编程(OOP)的结合——如何实现Service Contract的继承
- [原创]我的WCF之旅(7):面向服务架构(SOA)和面向对象编程(OOP)的结合——如何实现Service Contract的继承
- 利用WCF实现上传下载文件服务
- WCF技术剖析之二十六:如何导出WCF服务的元数据(Metadata)[实现篇]
- Kubernetes(k8s)如何使用kube-dns实现服务发现
- Mysql DBA 高级运维学习笔记-Heartbeat实现web服务的高可用案例及维护要点
- WCF技术剖析之二十六:如何导出WCF服务的元数据(Metadata)[实现篇]
- 利用WCF实现上传下载文件服务
- WCF技术剖析之二十七: 如何将一个服务发布成WSDL[基于WS-MEX的实现](提供模拟程序)
- 我的WCF之旅(7):面向服务架构(SOA)和面向对象编程(OOP)的结合——如何实现Service Contract的继承
- 三十、【C#.Net开发框架】WCFHosting服务主机的利用WCF服务通讯和实现思路
- Nginx反向代理Tomcat实现现负载均衡(高可用)以及利用redis+Session同步会话共享配置详解
- WCF 4.0中的动态发现服务WS-Discovery