SOA十大原則

作者 Stefan Tilkov譯者 戴強斌 發(fā)布于 2007年4月10日 上午4時(shí)27分

社區

SOA

主題

架構

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

1. 明確邊界

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

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

2. 共享契約和架構，而不是類(lèi)

基于一份服務(wù)描述（一份契約），服務(wù)使用者和服務(wù)提供者都可以獲得使用或提供服務(wù)的全部所需。根據松耦合原則，服務(wù)提供者不能依靠服務(wù)使用者來(lái)重用那些依賴(lài)于使用者環(huán)境的代碼。畢竟，服務(wù)使用者可能使用不同的開(kāi)發(fā)環(huán)境和運行環(huán)境。這條原則給SOA體系中所能交換的數據加上了嚴格的限制。理想的情況是，數據以符合一種或多種模式的XML文檔形式被交換，因為這種方式可應用于任何你能想到的編程環(huán)境。

因此，因為這條原則在基于DCOM和基于RMI的環(huán)境中是不可能被遵守的，所以這兩種環(huán)境基本上無(wú)法成為SOA的可用選項。

3. 策略驅動(dòng)

為了與服務(wù)交互，必須滿(mǎn)足以下兩組不同的要求：

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

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

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

4. 自治

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

5. 采用可傳輸的協(xié)議格式，而非API

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

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

6. 面向文檔

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

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

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

下面將通過(guò)比較來(lái)說(shuō)明這個(gè)問(wèn)題。請仔細思考下面的消息:

2006-03-1347113

與之相比：

   2006-03-13
4711
   3

顯然，第二種選擇更具有可讀性，第一種則不然。還值得注意的是，在第二種情況下，使用諸如Xpath技術(shù)訪(fǎng)問(wèn)信息的參與者，與采用固定的語(yǔ)法的參與者相比，將會(huì )更好的遠離更小的，非破壞性的變化。反之，如果在使用諸如stub和skeleton之類(lèi)的RPC模式的同時(shí)，采用如XML這樣的自描述性消息格式，就只會(huì )使XML落得揮霍帶寬的惡名。如果使用XML，就應當發(fā)揮它的優(yōu)點(diǎn)（參見(jiàn)這篇文章，文中深入剖析了現有許多Web服務(wù)技術(shù)簇在XML應用的測試中失敗的原因）。

7. 松耦合

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

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

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

8. 遵循標準

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

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

9. 獨立于軟件供應商

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

10. 元數據驅動(dòng)

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