關鍵字：構架SOA 在與客戶的多次接觸中，我都需要建立一套基本的SOA原則。以下章節介紹了面向服務的架構（SOA）所需要遵循的基本準則。這些準則不是絕對正確的，只是一套針對SOA相關討論的框架性意見。你可能注意到前四條是基于Don Box的四項原則，只是我在經過了這么長時間后加上了點個人的想法（我之所以把它們列出來是因為有人要求我提供一個可供參考的版本；我沒有回顧過這幾條，可能現在我對其中某些的看法已有改變）
1）清晰的邊界
在調用一個服務來完成它提供的功能的時候，需要將服務所需的所有信息傳遞過去。所有對服務的訪問都應通過其對外公開的接口；不應當允許某個服務存在任何隱含的假設。：“服務不可避免地要依賴消息，因為所有進出服務的東西都是消息”。通常情況下，服務的調用應該不依賴共享的上下文，而應該設計成無狀態的。服務所暴露的接口通過契約規定了它的功能性和非功能性的作用和特征。服務的調用是一個有業務意義的動作，可能是十分消耗資源的，并引入一系列不同于本地調用或遠程過程的異常。服務調用是不同于普通遠程過程調用的。
提供和消費服務需要盡可能的容易，所以應當避免隱藏過多服務之間所發生的交互。服務發送和接受的消息、服務的契約以及服務本身是SOA中首先需要確立的。這里面所包含的意思，對于任何建模的語言和工具來說，就是起碼應該對編寫服務的程序員提供這幾個概念方面的API.總而言之，服務通過外部接口隱藏內部細節，暴露服務的功能；于服務的交互是一個顯式的行為，它依賴服務的提供者和消費者之間消息傳遞。
2）共享契約和Schema，而不是Class類
根據服務的描述（某種契約），服務的消費者和提供者應該擁有消費或提供服務所需要的所有東西。根據松耦合原則，服務的提供者不應該依賴消費者在它自己環境下所能提供的代碼重用能力；因為服務可能被用在不同的開發時和運行時環境中。該原則在很大程度上限制了可以在SOA中交換的數據類型。理想的數據格式是使用可以被一個或多個Schema所驗證的XML文檔，因為幾乎所有可以想象到的語言環境都支持XML.
3）策略驅動
要跟一個服務交互，必須滿足兩組正交的需求：
1）服務提供者的功能、語法和語義必須滿足服務消費者的需求，
2）技術能力和技術需求必須相符。
打個比方，一個服務提供者可以很好地滿足一個服務消費者的要求，但是它是通過JMS來提供服務的，而消費者卻只能使用HTTP(例如它是在.NET平臺上實現的)；提供者可能要求通過XML加密標準在消息層進行加密，而消費者只支持SSL的傳輸層加密。即便在那些雙方都具備所需要的能力的情況下，這些能力也需要被“激活”--例如，服務提供者可能會有必要根據不同的消費者對應答消息采用不同的加密算法。
為了支持各式各樣不同設備和不同能力的服務消費者來訪問服務，SOA工具集必須引入某種策略機制。服務的功能性特征是由它們的接口來描述，而這些非功能性能力和需求則是用策略文件來指定的。
4）自治
跟“清晰的邊界”相關的一條準則是，一個服務應該是自治的，即，它跟外界的唯一關系（至少從SOA的角度來看）是通過它的接口。在某些情況下，一個服務還必須能夠切換它的運行期環境，例如，從輕量級的原型實現切換到完善的基于應用服務器的互相協作的多個組件的實現，而不需要用戶做任何相應的改動。服務可以相互獨立地進行改變、部署和版本管理。服務的提供者應該能夠不依賴用戶能力而迅速切換服務到更新的版本；而一些用戶也無法或不愿意切換到新的服務接口（特別是那些服務提供者無法控制的用戶）。
5）用格式連接，而不是用程序API
服務都支持使用特定的連接格式。這條原則和“清晰的邊界”原則關系非常大，不過是引入了一個新的角度：盡最大可能讓服務可以被訪問（從而達到長期的可用性），即，只要遵循服務所定義的交互策略，應該可以從任何平臺上通過符合服務接口定義的消息的交互來訪問一個服務。比如，要測試某個服務是否符合這個準則，可以看看是否能使用某種非主流的動態編程語言，例如Perl，Python或Ruby來調用或提供這項服務。雖然這些語言在當下的技術藍圖中無足輕重，但可以作為試紙來評估服務是否滿足下列約束：
1）所有消息的格式使用公開標準，或人類可讀的描述；
2）不需要耗費很多工作就可以創建符合特定Schema的消息，也不需要依賴特定的程序庫；
3）正確通訊所需的額外信息（例如為了安全或可靠性所創建的頭部信息）的語義和語法應該依照公開規范或標準；
4）與服務交互相關的傳輸（或傳送）協議中至少有一個是標準的網絡協議（或可以通過標準網絡協議進行訪問的）；
6）面向文檔
文章來源于領測軟件測試網 http://www.kjueaiud.com/
