在WCF中，我們可以利用它特定的功能來(lái)幫助我們?cè)陂_(kāi)發(fā)的過(guò)程中創(chuàng)建一個(gè)跨平臺(tái)的企業(yè)級(jí)互聯(lián)解決方案。那么如何才能正確的理解這樣一款功能強(qiáng)大的工具呢？首先讓我們先從WCF面向服務(wù)開(kāi)始看起吧。#t#

目前為止，我們已經(jīng)了解過(guò)了面向服務(wù)的概念，看過(guò)了面向服務(wù)的消息結(jié)構(gòu)，檢查了消息地址的需求，并且討論了消息地址的工業(yè)標(biāo)準(zhǔn)。如果你理解SO消息里標(biāo)準(zhǔn)地址結(jié)構(gòu)的動(dòng)機(jī)，那么明白面向服務(wù)的原則就不會(huì)困難。每個(gè)面向服務(wù)的設(shè)計(jì)都遵循以下4個(gè)院子（經(jīng)常被稱(chēng)為4原則）。

WCF面向服務(wù)之邊界清晰

在面向服務(wù)里，服務(wù)可以與每個(gè)其它的服務(wù)通過(guò)消息交互。換句話說(shuō)，服務(wù)可以穿越邊界發(fā)送消息給其它服務(wù)。服務(wù)可以發(fā)送和接收消息，并且能被發(fā)送和接受的消息形狀定義了服務(wù)的邊界。這些邊界被良好地定義，清晰地表示，并且是唯一的服務(wù)功能訪問(wèn)點(diǎn)。更實(shí)際點(diǎn)，如果服務(wù)1要和服務(wù)2交互，服務(wù)1必須發(fā)送消息給服務(wù)2.相反，一個(gè)面向?qū)ο蠡蛘呙嫦蚪M件的世界里，要求服務(wù)1應(yīng)該創(chuàng)建一個(gè)服務(wù)2的實(shí)例（或者一個(gè)服務(wù)2的代理）。這個(gè)例子里，這些服務(wù)間的邊界變得模糊了，因?yàn)榉?wù)1為了所有的目的，被服務(wù)2所控制。

如果服務(wù)1發(fā)送消息給服務(wù)2，服務(wù)2的位置有問(wèn)題嗎？答案是否，只要服務(wù)1允許發(fā)送消息給服務(wù)2.有人會(huì)猜測(cè)發(fā)送消息穿過(guò)邊界會(huì)帶來(lái)成本。當(dāng)構(gòu)建服務(wù)的時(shí)候這個(gè)成本應(yīng)該被考慮進(jìn)來(lái)。尤其是，我們的服務(wù)應(yīng)該盡可能少的穿越邊界。高效服務(wù)的對(duì)面就是“羅嗦”（這里比喻穿越服務(wù)邊界反復(fù)發(fā)送不必要的消息，從而帶來(lái)不必要的成文消耗）。

WCF面向服務(wù)之服務(wù)自治（一定程度）

我的觀點(diǎn)是，面向服務(wù)的系統(tǒng)應(yīng)該努力成為有幾分自治的服務(wù)，因?yàn)榧冏灾问遣豢赡艿摹Ｕ嬲姆?wù)自治意味著服務(wù)除了自己不依賴(lài)任何東西。在現(xiàn)實(shí)世界里，這種類(lèi)型的實(shí)體是不存在的，我懷疑我們?cè)诜植际接?jì)算的世界里將會(huì)看到許多純自治的服務(wù)。一個(gè)真正的服務(wù)自治服務(wù)是動(dòng)態(tài)建立通道、動(dòng)態(tài)地協(xié)商安全策略、動(dòng)態(tài)地詢(xún)問(wèn)消息Schema、動(dòng)態(tài)地與其它服務(wù)交換消息。一個(gè)純自治的服務(wù)意味著一個(gè)遲綁定的架構(gòu)。我們已經(jīng)看到這種系統(tǒng)，無(wú)論是在IUnknown接口還是在反射的濫用里。底線就是開(kāi)發(fā)者和架構(gòu)師一次又一次的證明這些類(lèi)型的架構(gòu)不起作用（盡管書(shū)上說(shuō)的很棒）。我必須修改這些評(píng)論，承認(rèn)面向服務(wù)領(lǐng)域里的舞步精彩的有些令人眼花繚亂。僅僅5年以前，面向服務(wù)的應(yīng)用系統(tǒng)非常少見(jiàn)，現(xiàn)在卻很平常。這個(gè)動(dòng)力也許會(huì)帶我們到通往純自治服務(wù)的路上，但是現(xiàn)在我認(rèn)為沒(méi)有必要過(guò)于強(qiáng)調(diào)太多自治的問(wèn)題。

實(shí)踐上，自治意味著什么？從實(shí)際角度出發(fā)，它意味著服務(wù)是可以控制生命周期的、控制可用性和控制另外服務(wù)的邊界。這個(gè)行為的反面例子可以用SQL 2000數(shù)據(jù)庫(kù)和代理說(shuō)明，兩個(gè)服務(wù)都是作為Windows服務(wù)里托管的，但是代理服務(wù)有一個(gè)內(nèi)置的數(shù)據(jù)庫(kù)服務(wù)依賴(lài)。停止數(shù)據(jù)庫(kù)服務(wù)意味著代理服務(wù)也會(huì)停止。這個(gè)服務(wù)間的緊耦合意味著它們不可能分開(kāi)，或者獨(dú)立的版本控制。緊耦合降低了買(mǎi)個(gè)服務(wù)的靈活性和在企業(yè)里的應(yīng)用。

WCF面向服務(wù)之契約共享

因?yàn)槊嫦蚍?wù)關(guān)注在參與者之間傳遞的消息上，必須有一個(gè)方式可以描述這些消息和成功的消息交換需要什么。廣義上，這些描述被稱(chēng)作契約（contract）。契約不是新的編程概念。在Windows平臺(tái)上，契約產(chǎn)生在COM和DCOM里。一個(gè)COM組件只能被發(fā)布和共享的契約訪問(wèn)。實(shí)際上，契約就是接口（Interface），用接口描述語(yǔ)言（IDL）來(lái)表示。這個(gè)契約使得調(diào)用者不知道實(shí)現(xiàn)細(xì)節(jié)。只要契約不被破壞，調(diào)用者可以包容COM組件的軟件升級(jí)和更新。

面向服務(wù)的系統(tǒng)概念上擴(kuò)展了COM IDL契約。面向服務(wù)的系統(tǒng)用更廣泛理解的語(yǔ)言XSD和WSDL來(lái)表述契約。更明確點(diǎn)，Schema被用來(lái)描述消息結(jié)構(gòu)，WSDL用來(lái)描述消息終結(jié)點(diǎn)?？傊?，這些基于XML的契約表示發(fā)送和接受的消息結(jié)構(gòu)、終結(jié)點(diǎn)地址、網(wǎng)絡(luò)協(xié)議、安全需求等等。XML的自然屬性允許發(fā)送者和最終接受者與COM相比可以更容易地運(yùn)行于任何平臺(tái)。在這些東里里，發(fā)送者必須知道接受者的消息結(jié)構(gòu)和格式，這些契約都會(huì)給出定義。本質(zhì)上，一個(gè)消息發(fā)送者需要依賴(lài)于契約而不是服務(wù)本身。

WCF面向服務(wù)之基于策略的兼容性

服務(wù)必須能夠描述其它服務(wù)與之交互的底層環(huán)境。例如，一些服務(wù)需要需要初始發(fā)送者擁有一個(gè)有效的AD賬號(hào)（Active Directory）或者X509證書(shū)。這種情況下，服務(wù)必須在一個(gè)基于XML的策略里表達(dá)這些需求。寫(xiě)本書(shū)時(shí)，WS-Policy是表達(dá)這些需求的標(biāo)準(zhǔn)語(yǔ)法。在被狂熱追求的面向服務(wù)的世界里，消息發(fā)送者需要先詢(xún)問(wèn)元數(shù)據(jù)而不是發(fā)送消息，更進(jìn)一步解耦服務(wù)發(fā)送者和消息接收者。與前面提到的原因一樣，服務(wù)策略更可能在設(shè)計(jì)時(shí)詢(xún)問(wèn)而不是運(yùn)行時(shí)。