我們傳統的服務調用的模式都是這樣的：客戶端在設計時就預先知道目標服務的地址，并基于這個地址創建客戶端終結點對服務進行調用。而我們即將介紹的新特性則是你在預先不知道目標服務的地址的情況下，可以動態地探測可用的服務并調用之。就像我們的無線網卡可以同態地獲取周圍可用的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)返回給客戶端。