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