在WCF中，我們可以利用它特定的功能來幫助我們在開發的過程中創建一個跨平臺的企業級互聯解決方案。那么如何才能正確的理解這樣一款功能強大的工具呢？首先讓我們先從WCF面向服務開始看起吧。#t#

目前為止，我們已經了解過了面向服務的概念，看過了面向服務的消息結構，檢查了消息地址的需求，并且討論了消息地址的工業標準。如果你理解SO消息里標準地址結構的動機，那么明白面向服務的原則就不會困難。每個面向服務的設計都遵循以下4個院子（經常被稱為4原則）。

WCF面向服務之邊界清晰

在面向服務里，服務可以與每個其它的服務通過消息交互。換句話說，服務可以穿越邊界發送消息給其它服務。服務可以發送和接收消息，并且能被發送和接受的消息形狀定義了服務的邊界。這些邊界被良好地定義，清晰地表示，并且是唯一的服務功能訪問點。更實際點，如果服務1要和服務2交互，服務1必須發送消息給服務2.相反，一個面向對象或者面向組件的世界里，要求服務1應該創建一個服務2的實例（或者一個服務2的代理）。這個例子里，這些服務間的邊界變得模糊了，因為服務1為了所有的目的，被服務2所控制。

如果服務1發送消息給服務2，服務2的位置有問題嗎？答案是否，只要服務1允許發送消息給服務2.有人會猜測發送消息穿過邊界會帶來成本。當構建服務的時候這個成本應該被考慮進來。尤其是，我們的服務應該盡可能少的穿越邊界。高效服務的對面就是“羅嗦”（這里比喻穿越服務邊界反復發送不必要的消息，從而帶來不必要的成文消耗）。

WCF面向服務之服務自治（一定程度）

我的觀點是，面向服務的系統應該努力成為有幾分自治的服務，因為純自治是不可能的。真正的服務自治意味著服務除了自己不依賴任何東西。在現實世界里，這種類型的實體是不存在的，我懷疑我們在分布式計算的世界里將會看到許多純自治的服務。一個真正的服務自治服務是動態建立通道、動態地協商安全策略、動態地詢問消息Schema、動態地與其它服務交換消息。一個純自治的服務意味著一個遲綁定的架構。我們已經看到這種系統，無論是在IUnknown接口還是在反射的濫用里。底線就是開發者和架構師一次又一次的證明這些類型的架構不起作用（盡管書上說的很棒）。我必須修改這些評論，承認面向服務領域里的舞步精彩的有些令人眼花繚亂。僅僅5年以前，面向服務的應用系統非常少見，現在卻很平常。這個動力也許會帶我們到通往純自治服務的路上，但是現在我認為沒有必要過于強調太多自治的問題。

實踐上，自治意味著什么？從實際角度出發，它意味著服務是可以控制生命周期的、控制可用性和控制另外服務的邊界。這個行為的反面例子可以用SQL 2000數據庫和代理說明，兩個服務都是作為Windows服務里托管的，但是代理服務有一個內置的數據庫服務依賴。停止數據庫服務意味著代理服務也會停止。這個服務間的緊耦合意味著它們不可能分開，或者獨立的版本控制。緊耦合降低了買個服務的靈活性和在企業里的應用。

WCF面向服務之契約共享

因為面向服務關注在參與者之間傳遞的消息上，必須有一個方式可以描述這些消息和成功的消息交換需要什么。廣義上，這些描述被稱作契約（contract）。契約不是新的編程概念。在Windows平臺上，契約產生在COM和DCOM里。一個COM組件只能被發布和共享的契約訪問。實際上，契約就是接口（Interface），用接口描述語言（IDL）來表示。這個契約使得調用者不知道實現細節。只要契約不被破壞，調用者可以包容COM組件的軟件升級和更新。

面向服務的系統概念上擴展了COM IDL契約。面向服務的系統用更廣泛理解的語言XSD和WSDL來表述契約。更明確點，Schema被用來描述消息結構，WSDL用來描述消息終結點。總之，這些基于XML的契約表示發送和接受的消息結構、終結點地址、網絡協議、安全需求等等。XML的自然屬性允許發送者和最終接受者與COM相比可以更容易地運行于任何平臺。在這些東里里，發送者必須知道接受者的消息結構和格式，這些契約都會給出定義。本質上，一個消息發送者需要依賴于契約而不是服務本身。

WCF面向服務之基于策略的兼容性

服務必須能夠描述其它服務與之交互的底層環境。例如，一些服務需要需要初始發送者擁有一個有效的AD賬號（Active Directory）或者X509證書。這種情況下，服務必須在一個基于XML的策略里表達這些需求。寫本書時，WS-Policy是表達這些需求的標準語法。在被狂熱追求的面向服務的世界里，消息發送者需要先詢問元數據而不是發送消息，更進一步解耦服務發送者和消息接收者。與前面提到的原因一樣，服務策略更可能在設計時詢問而不是運行時。