WCF-Discovery的协议基础：WS-Disvovery(客户端驱动探测服务)

最新推荐文章于 2022-10-17 10:33:52 发布

小艾的01

最新推荐文章于 2022-10-17 10:33:52 发布

阅读量917

点赞数

分类专栏： onvif

onvif 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

声明：本文章转自http://www.cnblogs.com/artech/archive/2011/10/07/WS-Discovery.html，非原创

我们传统的服务调用的模式都是这样的：客户端在设计的时候预先知道目标服务的地址，并基于这个地址创建终结点对服务进行调用。而我们即将介绍的新特性是你在预先不知道目标服务的情况下，可以动态的探测可用的服务并调用之。就像我们的无线网卡可以动态的获取周围可用的Wifi网络一样。

服务发现接触了客户端和服务端之间的依赖。允许服务的提供者可用动态的改变它的地址，也是新德服务可以很容易的被注册并为人所用。关键一点的事，服务发现并不是微软在.NET平台下的闭门造车，而是基于一个开发的标准，即我们接下来着重介绍的WS-Discovery.也就是说，如果Java平台的Web服务也是基于相同的WS-Discovery标准，那么他们也可以被wcf客户端“发现”。

一、WS-Discovery

WS-Discovery(全程为Web Services Dynamic Discovery),是由结构化信息标准组织制定。WS-Discovery1.0第一个正式版本发布于2005年，2009年OASIS发布了WS-Discovery1.1,到目前来看这是最新的版本。

WS-Discovery定义了两种基本的实现服务发现机制操作模式，即Ad-Hoc和Managed。在Ad-Hoc模式下，客户端在一定的网络范围内以广播的形式发送探测（probe）消息以搜寻目标服务。在该探测消息中，包含相应的搜寻条件。服务该条件的目标服务在接受探测消息之后将自身的相关的信息（包括地址）回复给作为广播消息发送源的客户端。客户端获取得到服务信息，选择合适的服务进行调用。

对于采用广播形式的ad-Hoc服务发现模式，可用的目标服务的范围往往只局限于一个较小的网络。比如对于基于UDP的广播的服务探测，能够被探测只能维护本地子网中。为了解决这个问题，我们可以采用Managed模式。在Manged模式下，一个维护所有可用的目标服务的中心发现代理(Discover Rroxy)被建立起来，客户端只需要将被探测信息发送代理就可以得到相应的目标服务信息。由于在Ad-Hoc模式下的广播探测机制在Managed模式下被转变成单播模式，带来的好处就是极大的减轻了网络的负载（Net work Traffic）.

实际上发现代理不仅仅使用在Managed模式下，在Ad-Hoc模式下也可以使用到它，除了上述的这种客户端驱动（客户端主动探测可用的目标服务）模式之外，还可以采用目标服务驱动的模式。在该模式下，客户端开启一个监听程序用于监听上线和离线的服务，而且目标服务在上线和离线的时候向监听者发送相应的通知。

要了解Ad-Hoc和Mangaged模式下的服务发现机制时如何实现的，就需要了解在整个服务模型中各个角色（客户端、目标服务和发现代理）之间是如何协作的。接下来，我们就从信息交互的角度谈谈服务发现模型中各个角色的交互协作问题。

二、Ad-Hoc模式

下面所示的序列图揭示了在Ad-Hoc模式下，客户端和目标服务之间的信息交换。目标服务在上线和离线的时候以广播的形式分别发送一个Hello和Bye消息，而客户端自然是该消息的其中一个接受者。

如果客户端需要通过获取当前可用的目标服务，需要以广播的形式发送一个Probe消息，该消息包含用以探测的目标服务所满足的条件。对于接受该广播的目标服务，如果自身满足包含Probe消息中的条件，则可以单播的形式回复给客户端一个Probe Mtach(简称PM)消息。

如果客户端从PM消息中获取的关于目标服务的相关的信息足以对其进行调用，则不需要进行后续的信息交换。否则（比如获取的PM消息中没有包含目标服务的地址）还需要进行一次旨在实现最终服务调用的服务解析（Resolution）的信息交换。具体来说，客户端以广播的形式发送Resolve请求（4），该请求中包含某个目标服务相关的信息，Resolve和Probe广播具有相同的范围。真正的目标服务（包含在Resolve消息中用以解析的服务）将包含自身地址在内的信息以Resolve Match(简称PM)消息的形式回复给客户端（5）。

在上面我们说过，Managed模式需要一个发现代理对目标进行统一的管理，但是发现代理本身就可以用在Managed模式，可以用Ad-Hoc模式。在Ad-Hoc模式下，发现代理对于客户端来说扮演者目标服务的角色，而对真正的目标服务来说，则扮演者客户端的角色。相当于一个信息的中介者，下图揭示了在发现代理存在的Ad-Hoc模式下，客户端，目标服务器和发现代理之间进行的信息交互。

在发现代理存在的情况下，客户端和目标服务之间还是按照上面介绍的方式进行消息交换。比如Hello/Bye（4）、Probe/PM和Resolve/RM（5和7）。而发现代理上线和下线的时候，会像真正的目标服务一样发出Hello/Bye（1）广播。当接收到客户端发出的Probe/Resolve广播的时候（2），它会像真正的目标服务一样回复以PM/RM消息（3），该回复消息中包含它自身维护的与Probe/Resolve请求匹配的目标服务。发现代理同样会接收到真正的目标上下线发出的Hello/Bye广播（4），它可以借此来更新维护的可用目标服务列表。

对于发现代理参与下的Ad-Hoc模式，发现代理还提供了一种转换成Managed模式的机制。具体的实现是这样的：当发现代理接收到客户端发出的Probe/Resolve广播后（5），会回复给客户端一个Hello消息，表明发现代理的存在并可以从Ad-Hoc模式转换到Managed模式。客户端在接收到该Hello消息后（6），就会将原来以广播的形式发送的Probe/Resolve请求转换成指向发现代理的单播形式发送。

三、Managed模式

在Managed模式下，由于可用的服务都注册到发现代理中，客户端只需要和发现代理交互就可以进行可用服务的探测和解析，而目标服务只需要和直接和发现代理交换就能实现自身的注册。在Managed模式下，发现代理真正的核心。而且所有的消息交互的方式都是以单播的方式进行的。这样的好处是：1、可以解除广播对网络的限制，扩大可用服务的范围，而来可以避免广播引起的网络的拥堵。

在Managed模式下，客户端、发现代理和目标服务之间进行的消息交互，目标服务上/下线的时候只需要向代理服务发送Hello/bye通知。而客户端可以进行的服务探测和服务解析发送的probe、Resolve也只需要单独发送给发现代理。作为回复，发现代理将PM返回给客户端。