Carlos首先引用了Bertrand Meyer的模塊性原理的原文：
- 模塊可分解性（Modular Decomposability）——如果一種軟件構造方法能有助於把一個軟件問題分解爲若干較簡單的子問題、並用一個簡單的結構將這些子問題連接起來、而且能夠獨立地對各個子問題作進一步分解，那麼該方法就滿足模塊可分解性。
- 模塊可組合性（Modular Composability）——如果一種方法，由它生產出的軟件元素，未來可在不同於最初被開發的環境中通過彼此自由組合的方式來產生新的系統，那麼該方法就滿足模塊可組合性。
- 模塊可理解性（Modular Understandability）——如果一種方法，由它生產出的軟件，人類讀者無需瞭解其他模塊（或最多隻需研究少許其他模塊）便可理解每一個模塊，那麼該方法就有利於模塊可理解性。
- 模塊連續性（Modular Continuity）——如果一種方法，在由它得到的軟件架構中，功能規格上的微小改動只會引起一個（或少量）模塊的變化，那麼該方法就滿足模塊連續性。
- 模塊保護性（Modular Protection）——如果一種方法，在由它得到的架構中，一個模塊在運行時出現異常條件不會影響到該模塊之外（或最多隻蔓延到少數週邊模塊），那麼該方法就滿足模塊保護性。
接着，他考察並評論了該領域的各個思想領袖（如Thomas Erl、Don Box、Stefan Tilkov和David Orchard等）所表達的面向服務原則。
……Thomas Erl的原則是一組糟糕的原則，因爲它們把關注點混攪起來了。
……David Orchard的原則體現了較好的平衡，當然我必須要質疑爲何把WS-*也加進來。
然後，他根據自己的服務定義，概括了以下面向服務的原則，
- 可分解性（Decomposability）——如果一種方法能有助於把一個軟件問題分解爲若干較簡單的子問題、並用一個簡單的結構將這些子問題連接起來、而且能夠獨立地對各個子問題作進一步分解，那麼該方法就滿足可分解性。
- 可組合性（Composability）——如果一種方法，由它生產出的軟件元素，未來可在不同於最初被開發的環境中通過彼此自由組合的方式來產生新的系統，那麼該方法就滿足可組合性。
- 可理解性（Understandability）——如果一種方法，由它生產出的軟件，人類讀者無需瞭解其他模塊（或最多隻需研究少許其他模塊）便可理解每一個模塊，那麼該方法就有利於可理解性。
- 連續性（Continuity）——如果一種方法，在由它得到的軟件架構中，功能規格上的微小改動只會引起一個（或少量）模塊的變化，那麼該方法就滿足連續性。
- 保護性（Protection）——如果一種方法，在由它得到的架構中，一個模塊在運行時出現異常條件不會影響到該模塊之外（或最多隻蔓延到少數週邊模塊），那麼該方法就滿足保護性。
- 自查性（Introspection）——如果一個方法，由它得到的架構提供了“允許在運行時查詢並檢查模塊結構及模塊間通信結構”的機制，那麼該方法就滿足自查性。
- 遠程性（Remoteability）——如果一個方法，由它得到的架構提供了“允許託管於不同物理環境下的不同模塊與之進行模塊通信”的機制，那麼該方法就滿足遠程性。
- 異步性（Asynchronicity）——如果一個方法，由它得到的架構不假定模塊調用將被立即響應，那麼該方法就滿足異步性。換言之，它假定網絡或被調用模塊有延遲。
- 面向文檔（Document Orientedness）——如果一個方法，在由它得到的架構中，內部模塊間的通信消息均是明確定義且互相知道的、而且各次調用之間不存在隱式的狀態共享，那麼該方法就是面向文檔的。
- 標準化的協議信封（Standardized Protocol Envelope）——如果一個方法，由它得到的架構要求所有模塊通信都共用一種通用信封消息格式，那麼該方法就滿足標準協議信封。
- 分散式管理（Decentralized Administration）——如果一個方法，由它得到的架構不需要對所有模塊進行集中管理，那麼該方法就符合分散式管理。
最後他說“至於那個無所不包的‘松耦合’；只要你願意，上述特性中的許多都可以得到！總之，SOA就只是松耦合的API。”
你覺得呢？Bertrand Meyer的軟件質量原則有多少能用在面向服務領域？你一定得看看Carlos Perez的原文。
查看英文原文：Loose Coupling in SOA Defined 注：以上內容來自網絡，本人不承擔任何連帶責任 文章轉自：http://www.infoq.com/cn/news/2008/06/loose-coupling-soa