面向服務的4個原則
目前為止，我們已經了解過了面向服務的概念，看過了面向服務的消息結構 ，檢查了消息地址的需求，並且討論了消息地址的工業標准。如果你理解SO消息 裡標准地址結構的動機，那麼明白面向服務的原則就不會困難。每個面向服務的 設計都遵循以下4個院子（經常被稱為4原則）。
邊界清晰
在面向服務裡，服務可以與每個其它的服務通過消息交互。換句話說，服務 可以穿越邊界發送消息給其它服務。服務可以發送和接收消息，並且能被發送和 接受的消息形狀定義了服務的邊界。這些邊界被良好地定義，清晰地表示，並且 是唯一的服務功能訪問點。更實際點，如果服務1要和服務2交互，服務1必須發 送消息給服務2.相反，一個面向對象或者面向組件的世界裡，要求服務1應該創 建一個服務2的實例（或者一個服務2的代理）。這個例子裡，這些服務間的邊界 變得模糊了，因為服務1為了所有的目的，被服務2所控制。
如果服務1發送消息給服務2，服務2的位置有問題嗎？答案是否，只要服務1 允許發送消息給服務2.有人會猜測發送消息穿過邊界會帶來成本。當構建服務的 時候這個成本應該被考慮進來。尤其是，我們的服務應該盡可能少的穿越邊界。 高效服務的對面就是“羅嗦”（這裡比喻穿越服務邊界反復發送不必要的消息， 從而帶來不必要的成文消耗）。
服務自治（一定程度）
我的觀點是，面向服務的系統應該努力成為有幾分自治的服務，因為純自治 是不可能的。真正的服務自治意味著服務除了自己不依賴任何東西。在現實世界 裡，這種類型的實體是不存在的，我懷疑我們在分布式計算的世界裡將會看到許 多純自治的服務。一個真正的服務自治服務是動態建立通道、動態地協商安全策 略、動態地詢問消息Schema、動態地與其它服務交換消息。一個純自治的服務意 味著一個遲綁定的架構。我們已經看到這種系統，無論是在IUnknown接口還是在 反射的濫用裡。底線就是開發者和架構師一次又一次的證明這些類型的架構不起 作用（盡管書上說的很棒）。我必須修改這些評論，承認面向服務領域裡的舞步 精彩的有些令人眼花缭亂。僅僅5年以前，面向服務的應用系統非常少見，現在 卻很平常。這個動力也許會帶我們到通往純自治服務的路上，但是現在我認為沒 有必要過於強調太多自治的問題。
實踐上，自治意味著什麼？從實際角度出發，它意味著服務是可以控制生命 周期的、控制可用性和控制另外服務的邊界。這個行為的反面例子可以用SQL 2000數據庫和代理說明，兩個服務都是作為Windows服務裡托管的，但是代理服 務有一個內置的數據庫服務依賴。停止數據庫服務意味著代理服務也會停止。這 個服務間的緊耦合意味著它們不可能分開，或者獨立的版本控制。緊耦合降低了 買個服務的靈活性和在企業裡的應用。
契約共享
因為面向服務關注在參與者之間傳遞的消息上，必須有一個方式可以描述這 些消息和成功的消息交換需要什麼。廣義上，這些描述被稱作契約（contract） 。契約不是新的編程概念。在Windows平台上，契約產生在COM和DCOM裡。一個 COM組件只能被發布和共享的契約訪問。實際上，契約就是接口（Interface）， 用接口描述語言（IDL）來表示。這個契約使得調用者不知道實現細節。只要契 約不被破壞，調用者可以包容COM組件的軟件升級和更新。
面向服務的系統概念上擴展了COM IDL契約。面向服務的系統用更廣泛理解的 語言XSD和WSDL來表述契約。更明確點，Schema被用來描述消息結構，WSDL用來 描述消息終結點。總之，這些基於XML的契約表示發送和接受的消息結構、終結 點地址、網絡協議、安全需求等等。XML的自然屬性允許發送者和最終接受者與 COM相比可以更容易地運行於任何平台。在這些東裡裡，發送者必須知道接受者 的消息結構和格式，這些契約都會給出定義。本質上，一個消息發送者需要依賴 於契約而不是服務本身。
基於策略的兼容性
服務必須能夠描述其它服務與之交互的底層環境。例如，一些服務需要需要 初始發送者擁有一個有效的AD賬號（Active Directory）或者X509證書。這種情 況下，服務必須在一個基於XML的策略裡表達這些需求。寫本書時，WS-Policy是 表達這些需求的標准語法。在被狂熱追求的面向服務的世界裡，消息發送者需要 先詢問元數據而不是發送消息，更進一步解耦服務發送者和消息接收者。與前面 提到的原因一樣，服務策略更可能在設計時詢問而不是運行時。
【地址】：http://www.cnblogs.com/frank_xl/
