在與許多客戶的接觸中，我發(fā)現(xiàn)有必要建立一套SOA的基本原則。下面的部分將介紹SOA中應(yīng)有的基本原則。這些并非絕對(duì)真理，它們更像一個(gè)用于SOA相關(guān)討論的參考框架。你會(huì)發(fā)現(xiàn)：前四項(xiàng)衍生自Don Box提出的四項(xiàng)原則，盡管隨著時(shí)間的流逝，這四項(xiàng)原則的描述可能已經(jīng)有了些變化。
相關(guān)廠商內(nèi)容

1. 明確邊界:服務(wù)被調(diào)用時(shí)，與實(shí)現(xiàn)其功能相關(guān)的內(nèi)容都應(yīng)被傳遞過(guò)來(lái)。對(duì)服務(wù)的所有訪問(wèn)都應(yīng)該通過(guò)公共接口進(jìn)行。調(diào)用服務(wù)時(shí)，非隱含的假設(shè)是必須的。“服務(wù)與消息緊密聯(lián)系，因?yàn)閰?shù)進(jìn)出服務(wù)的唯一方式是通過(guò)消息進(jìn)行的”。作為通用的模式，服務(wù)調(diào)用不應(yīng)依賴于共享的上下文，而應(yīng)被作為無(wú)狀態(tài)的模塊。契約描述了服務(wù)的功能性與非功能性的能力和特點(diǎn)，管理著服務(wù)提供的接口。服務(wù)調(diào)用是一個(gè)具有業(yè)務(wù)邏輯效果的行為，可能有大量的資源開(kāi)銷，并且導(dǎo)致一系列不同于本地方法調(diào)用和遠(yuǎn)程過(guò)程調(diào)用的錯(cuò)誤。服務(wù)的調(diào)用絕非遠(yuǎn)程過(guò)程調(diào)用。

服務(wù)的使用和提供應(yīng)該盡可能地簡(jiǎn)單，因此與服務(wù)間的交互沒(méi)必要被隱藏得太多。在SOA中，服務(wù)發(fā)送和接收的消息、服務(wù)契約以及服務(wù)本身都應(yīng)當(dāng)是最好的構(gòu)件。這就意味著，例如，被用到的編程模型和工具至少應(yīng)該提供一個(gè)API，這個(gè)API會(huì)幫助服務(wù)的編程人員了解上述概念。總的來(lái)說(shuō)，一個(gè)明確的接口會(huì)封裝服務(wù)的內(nèi)在實(shí)現(xiàn)，而服務(wù)通過(guò)該接口發(fā)布自己的功能；與服務(wù)交互是一個(gè)具體的行為，它依賴于服務(wù)使用者和提供者之間消息的傳遞。

2. 共享契約和架構(gòu)，而不是類:基于一份服務(wù)描述（一份契約），服務(wù)使用者和服務(wù)提供者都可以獲得使用或提供服務(wù)的全部所需。根據(jù)松耦合原則，服務(wù)提供者不能依靠服務(wù)使用者來(lái)重用那些依賴于使用者環(huán)境的代碼。畢竟，服務(wù)使用者可能使用不同的開(kāi)發(fā)環(huán)境和運(yùn)行環(huán)境。這條原則給SOA體系中所能交換的數(shù)據(jù)加上了嚴(yán)格的限制。理想的情況是，數(shù)據(jù)以符合一種或多種模式的XML文檔形式被交換，因?yàn)檫@種方式可應(yīng)用于任何你能想到的編程環(huán)境。因此，因?yàn)檫@條原則在基于DCOM和基于RMI的環(huán)境中是不可能被遵守的，所以這兩種環(huán)境基本上無(wú)法成為SOA的可用選項(xiàng)。

3. 策略驅(qū)動(dòng):為了與服務(wù)交互，必須滿足以下兩組不同的要求：

• 提供者提供的功能、語(yǔ)法和語(yǔ)義必須適應(yīng)使用者的需求；
• 技術(shù)能力與需要必須匹配。

例如，一個(gè)服務(wù)提供者提供了能夠精確滿足用戶需求的服務(wù)，但該服務(wù)是基于JMS的，可使用者只能使用HTTP方式（比如，服務(wù)被應(yīng)用于.NET平臺(tái)）。服務(wù)提供者可能要求消息級(jí)別的加密采用XML加密標(biāo)準(zhǔn)，而使用者只支持采用SSL技術(shù)來(lái)保障傳輸層上的安全。即使在那些交互雙方都擁有足夠能力的案例中，它們的這些能力仍舊需要被“啟用”。例如，提供者可能根據(jù)不同的使用者需求，對(duì)響應(yīng)的消息使用不同的算法進(jìn)行加密。

為了使盡可能多的形形色色的使用者能對(duì)服務(wù)進(jìn)行訪問(wèn)，一種策略機(jī)制已經(jīng)被作為SOA工具集的一部分引入了。在服務(wù)接口對(duì)功能進(jìn)行描述的同時(shí)，策略對(duì)不同的，非功能性的能力和需求進(jìn)行了指定。（譯者注：策略指定的是服務(wù)之外的補(bǔ)充信息，是對(duì)服務(wù)使用者提出的特征要求）。

4. 自治：與明確邊界原則相關(guān)，服務(wù)自治意味著，接口成為服務(wù)與外界聯(lián)系的唯一方式，至少?gòu)腟OA的角度來(lái)看是這樣的。需要注意的是，服務(wù)的運(yùn)行環(huán)境一定是可變的。例如，在絲毫不影響使用者的情況下，就可以從輕量級(jí)的原型實(shí)現(xiàn)轉(zhuǎn)換到成熟的、基于應(yīng)用服務(wù)器的協(xié)同組件集。服務(wù)能夠被彼此獨(dú)立的修改、部署、發(fā)布新版本和管理。服務(wù)提供者不能寄希望于服務(wù)使用者，期望它們依靠自己的能力迅速適應(yīng)新版本的服務(wù)，有的使用者可能甚至沒(méi)這個(gè)能力或者根本不愿去適應(yīng)新版本的服務(wù)接口（尤其是當(dāng)這些服務(wù)接口超出了服務(wù)提供者控制范圍的時(shí)候）。

5. 采用可傳輸?shù)膮f(xié)議格式，而非API：服務(wù)通常采用協(xié)議格式來(lái)發(fā)布，協(xié)議格式應(yīng)該是明確的、可傳輸?shù)牟⑶冶环?wù)所支持的。這一點(diǎn)與前兩條原則非常相關(guān)，但卻帶來(lái)了新的見(jiàn)解：為保證一個(gè)服務(wù)最大程度的可訪問(wèn)性（及長(zhǎng)期的可用性），只要交互過(guò)程遵守為該服務(wù)定義的策略，那么由任何依照服務(wù)接口進(jìn)行消息交換的平臺(tái)都可以訪問(wèn)該服務(wù)。例如，通過(guò)以這一原則來(lái)測(cè)試主流的動(dòng)態(tài)編程語(yǔ)言（如Perl、Python或Ruby），我們可以去考慮該語(yǔ)言能否使用或提供一個(gè)特定的服務(wù)。雖然，在現(xiàn)有的技術(shù)實(shí)現(xiàn)里，這條原則可能還沒(méi)有發(fā)揮作用，但這個(gè)思路可以作為下列準(zhǔn)則的試金石：

• 使用開(kāi)放的標(biāo)準(zhǔn)或者可閱讀的描述來(lái)描述所有消息格式。
• 不需要特定的資源就可以創(chuàng)造出符合這些合理的模式的消息。
• 成功通信所必需的附加信息，例如包含安全性或可靠性約束的頭信息，它們的語(yǔ)義和語(yǔ)法要遵循公開(kāi)的規(guī)范和標(biāo)準(zhǔn)。
• 服務(wù)交互時(shí)所使用的傳輸（或傳遞）協(xié)議中至少有一個(gè)是標(biāo)準(zhǔn)的網(wǎng)絡(luò)協(xié)議，或它可以通過(guò)標(biāo)準(zhǔn)的網(wǎng)絡(luò)協(xié)議來(lái)訪問(wèn)。

6. 面向文檔：服務(wù)交互時(shí)，數(shù)據(jù)是以文檔的形式來(lái)傳遞的。文檔是一個(gè)被明確模塊化的，有層次結(jié)構(gòu)的數(shù)據(jù)容器。面向文檔的一個(gè)重要特征就是自描述。最理想的情況下，文檔是對(duì)現(xiàn)實(shí)世界中的文件（如訂單、發(fā)票或帳單）的建模。文檔應(yīng)該被設(shè)計(jì)來(lái)確保它在問(wèn)題域的上下文中發(fā)揮作用，這意味著它們可能應(yīng)用于一個(gè)或更多的服務(wù)。

與現(xiàn)實(shí)世界的紙制文檔相似，和服務(wù)交換信息的文檔將包含冗余的信息。例如，文檔中可能同時(shí)包含了客戶ID和客戶地址信息（盡管客戶ID可能已經(jīng)足夠了）。這種冗余是可以接受的，因?yàn)樗鼘⒎?wù)使用者和提供者雙方的服務(wù)接口和隱含數(shù)據(jù)模型隔離開(kāi)來(lái)。應(yīng)用面向文檔的模式的同時(shí)，服務(wù)調(diào)用成為有意義的業(yè)務(wù)邏輯消息的交換，而非上下文無(wú)關(guān)的RPC調(diào)用。雖然通常可以認(rèn)為XML將被作為服務(wù)文檔的格式和語(yǔ)法，但它還沒(méi)有成為標(biāo)準(zhǔn)。

在一個(gè)SOA連接中，參與者之間的消息流轉(zhuǎn)于不同的系統(tǒng)，使得各個(gè)系統(tǒng)之間彼此獨(dú)立。松耦合原則要求參與者對(duì)共知的依賴越少越好。當(dāng)消息在分布式對(duì)象或RPC基礎(chǔ)架構(gòu)中發(fā)送時(shí)，客戶端和服務(wù)器端使用由同一個(gè)接口描述文檔生成的代理類(stub和skeleton）。如果不是這種情況的話，當(dāng)契約不支持雙方的交互時(shí)，通訊就會(huì)停止。因?yàn)檫@個(gè)原因，RPC風(fēng)格的基礎(chǔ)架構(gòu)要求客戶端和服務(wù)器端程序代碼的同步運(yùn)行。

7. 松耦合：多數(shù)SOA的倡導(dǎo)者都認(rèn)為松耦合是一個(gè)很重要的概念。不幸的是，對(duì)于究竟哪些特征造成一個(gè)系統(tǒng)松耦合，有許多不同的看法。一個(gè)系統(tǒng)可以在多個(gè)維度表現(xiàn)為松耦合或緊耦合，它依賴于具體的要求和上下文，系統(tǒng)可能會(huì)在一些維度是松耦合的，在另一些維度是緊耦合的。這些維度包括：

• 時(shí)間：當(dāng)參與者在時(shí)間上是松耦合時(shí)，它們不需要在同一時(shí)間啟動(dòng)并進(jìn)行通訊。這要求兩者之間采用某種緩沖或隊(duì)列機(jī)制，盡管這種機(jī)制與松耦合無(wú)關(guān)。當(dāng)參與的一方向另一方發(fā)送消息時(shí)，交互的繼續(xù)不依賴于邏輯上或物理上能否立即返回應(yīng)答消息。
• 位置：如果一方參與者查詢與之通信的另一方參與者的地址，另一方的地址可以透明地進(jìn)行變更，不需要重新編程、重新配置或者甚至不需要通信伙伴的重新啟動(dòng)。這意味著查找（lookup）過(guò)程采用某種目錄或地址來(lái)存儲(chǔ)服務(wù)終端的地址。（對(duì)應(yīng)SOA提供的目錄服務(wù)）
• 類型：同靜態(tài)與動(dòng)態(tài)，弱類型與強(qiáng)類型這些編程的概念類似，參與者既可以全部依賴也可以部分依賴文檔結(jié)構(gòu)來(lái)實(shí)現(xiàn)它的功能。
• 版本：參與者可以依賴服務(wù)接口的特定版本，也可以兼容某個(gè)范圍內(nèi)的版本。所需匹配的版本越確切，參與者在這個(gè)方面上的松耦合性就越差。一個(gè)好的原則是遵循Postel法則（譯者注：Postel’s Law——“Be liberal in what you accept, and conservative in what you send.”）：服務(wù)提供者應(yīng)盡可能兼容許多不同的版本，這將使它更加健壯（可能甚至需要容錯(cuò)），服務(wù)使用者應(yīng)盡可能遵循精確的語(yǔ)法和文檔類型。這將增加整個(gè)系統(tǒng)的穩(wěn)定性和靈活性。
• 基數(shù)：服務(wù)消費(fèi)者和提供者可能是1對(duì)1的關(guān)系，尤其是在請(qǐng)求或響應(yīng)交互發(fā)生時(shí)，或隊(duì)列被明確使用的情況下。在別的情況下，服務(wù)使用者（在這種情況下，稱作“消息發(fā)送者”或“事件源”更為合理）可能既不知道也不關(guān)心有多少人接受了消息。
• 查找（Lookup）：參與者打算調(diào)用服務(wù)時(shí)，既可以依賴服務(wù)提供者的物理名或邏輯名，也可以先通過(guò)一組功能描述來(lái)執(zhí)行查找（lookup）操作。這意味著存在一個(gè)注冊(cè)表和（或）倉(cāng)庫(kù)，對(duì)存儲(chǔ)其中的使用者需求和提供者能力進(jìn)行直接或間接的匹配。
• 接口：參與者可能要綁定到一個(gè)特定的服務(wù)接口或是支持一個(gè)通用的接口。如果使用通用接口，所有該接口的使用者都能與所有該接口的提供者進(jìn)行交互。盡管可能乍看起來(lái)這有些笨拙，但單一通用（統(tǒng)一）接口的原則就是WWW架構(gòu)的核心。

創(chuàng)造一個(gè)滿足以上所有維度的松耦合系統(tǒng)，既不可行，也沒(méi)必要。不同類型的服務(wù)要做不同的取舍。Carlos Perez的經(jīng)典之作中(如這里和這里)有更多的關(guān)于松耦合各個(gè)維度的討論。

8. 遵循標(biāo)準(zhǔn):一個(gè)SOA應(yīng)用中應(yīng)遵循的一個(gè)關(guān)鍵原則是，信賴標(biāo)準(zhǔn)而非專有的API和格式。標(biāo)準(zhǔn)存在于技術(shù)方面，如數(shù)據(jù)格式、元數(shù)據(jù)、傳輸協(xié)議；也存在于業(yè)務(wù)層面，如文檔的類型。（例如，UBL中所提到的那些）（譯者注：UBL定義了業(yè)務(wù)文檔的通用XML庫(kù)，UBL的文檔類型包括訂單、發(fā)票等）

很顯然，一些人認(rèn)為專有的解決方案，如一些EAI或消息服務(wù)提供商提供的方案，都遵循SOA原則。這個(gè)原則不遺余力地強(qiáng)調(diào)標(biāo)準(zhǔn)的重要性。當(dāng)然，由于有太多可供選擇的標(biāo)準(zhǔn)，什么情況用何種標(biāo)準(zhǔn)成了頗具爭(zhēng)議的問(wèn)題。標(biāo)準(zhǔn)的一個(gè)重要方面是它的可接受性（在Web服務(wù)的標(biāo)準(zhǔn)中，基本上可以認(rèn)為“Microsoft肯定要插上一腳”）。

9. 獨(dú)立于軟件供應(yīng)商:任何架構(gòu)性的原則都不應(yīng)依賴特定供應(yīng)商的產(chǎn)品。將抽象的概念轉(zhuǎn)化為具體的，可運(yùn)行的系統(tǒng)的過(guò)程中，不可避免的要決定使用何種具體的產(chǎn)品，包括商業(yè)的或者免費(fèi)開(kāi)源的軟件。這些決定都不應(yīng)影響架構(gòu)層。這就意味著要盡可能的依賴互操作性和可移植性的標(biāo)準(zhǔn)。因此，要應(yīng)用支持適當(dāng)標(biāo)準(zhǔn)的技術(shù)來(lái)構(gòu)建服務(wù)提供者和使用者，不要受限于任何軟件供應(yīng)商的技術(shù)路線。

10. 元數(shù)據(jù)驅(qū)動(dòng):SOA中所有的元數(shù)據(jù)對(duì)象都需要被按照一種方式儲(chǔ)存起來(lái)，這種方式將確保元數(shù)據(jù)對(duì)象能夠在設(shè)計(jì)和運(yùn)行時(shí)被發(fā)現(xiàn)、檢索和解釋。元數(shù)據(jù)對(duì)象包括對(duì)服務(wù)接口、參與者、端點(diǎn)和綁定信息、組織單元和職責(zé)、文檔類型或模式、使用者或提供者關(guān)系等的描述。這些對(duì)象的用途應(yīng)當(dāng)是被代碼自動(dòng)生成或者解釋，成為服務(wù)和參與者生命周期的一部分。

以上是我的原則列表。 即使你不完全同意——而坦率地講，我也不希望你完全同意， 至少不是全部都同意——我希望你能帶著它們來(lái)引發(fā)一些討論!