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

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

　　一、WS-Discovery

　　WS-Discovery（全称为Web Services Dynamic Discovery），是由我们在本书中频繁提到的是由结构化信息标准促进组织（OASIS：Organization for the Advancement of Structured Information Standards）制定。WS-Discovery 1.0第一个正式的版本发布于2005年4月，在2009年7月份OASIS发布了WS-Discovery 1.1，到目前来看这是最新的版本。

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

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

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

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

　　二、Ad-Hoc模式

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

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

　　如果客户端从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模式下，发现代理是真正的核心，而且所有消息交换的方式都是以单播的方式进行的。这样的好处是：一来可以解除广播对网络的限制，扩大可用服务的范围；二来也可以避免广播引起对网络的拥堵。

　　下图揭示了在Managed模式下，客户端、发现代理和目标服务之间进行的消息交换。目标服务上/下线的时候只需要向代理服务发送Hello（1）/Bye（6）通知。而客户端用以进行的服务探测和服务解析发送的Probe（2）/Resolve（4）也只需要单独发送给发现代理。作为回复，发现代理将PM(3)/RM(5)返回给客户端。