Schmelzer如此描述松耦合的7個維度：
實現
服務契約
服務策略
過程
數據模式
基礎設施
語義級別
這個報告是這樣說明松耦合實現級別的：
所有SOA的實現必須在實現級別是松耦合的，但是顯然這并不足以保證達到業務期望的那種完全的松耦合。
服務契約提到了使用服務描述框架的好處：
服務描述框架（SDF）……是一種技術中立的服務契約模板。以那種方式，新的服務契約并不是簡單地替代舊的契約。除非給服務消費者提供一個轉換路徑，否則舊契約就永遠不會被棄用。
延遲綁定的問題也被提了出來：
在這個舞臺上[可能]的最佳實踐就是使用一種延遲綁定的方法，該方法利用了運行時注冊和基于契約的綁定，這樣抽象了特定于服務消費者的綁定，并使服務契約變更照成的影響不致于蔓延開來。
Anil John就這一觀點表示懷疑：
直到我們解決跨Web的無縫互操作問題之前（主要是XML到對象數據綁定引起的問題），由涉及產生和實現動態客戶端代理的消費者來把運行時綁定到服務只不過就是一次視覺探索（VisionQuest）！在當前那些確實“利用運行時注冊和基于契約的綁定”的環境中，唯一可行的運行時辦法只限于動態綁定到不同的SOAP端點（它能在注冊中使用一個運行時的查找得到），當且僅當已經在潛在的生產者和消費者之間的Web代碼中完成了上述的互操作測試。
報告將服務策略與服務契約這樣聯系起來：
公司指望服務可變性在處理策略變更的方法與它們處理服務契約變更的方式一樣：延遲綁定、啟用服務仲裁、基于注冊和治理。
業務過程的處理是類似的：
通過在元數據中定義過程并使用服務契約暴露這些過程（作為服務暴露，服務組合時采用遞歸方式），可以把過程實現從服務消費者中抽象出來。
第一次提到對數據模式進行不同的處理：
模式是服務數據互操作能力的關鍵。但是，當模式發生變化時情況會怎樣呢？解決問題的一個關鍵就在于將信息和模式按照服務元數據相同的管理方式進行管理。數據模式被視為元數據的一種形式，并且異常管理、轉換、服務仲裁和數據服務全部都是數據結構松耦合的關鍵。
現在，再一次回頭看看服務契約中說的——“模式和服務契約沒有什么不同”。
報告認為，盡管從基礎設施觀點來看，松耦合可能很容易定義，但是極少有廠商提供這種靈活性：
[這]意味著在任何時間，公司都可以改變他們的基礎設施，而無需重新構建所有的服務消費者和提供者。
最后的解決方案是在語義級別描述的——動態服務定義，其中“服務接口的定義必須基于服務請求者的上下文改變。結果是，服務可以在調用之間改變它們的契約”。這種寬松的語法看起來會和REST模型一起工作得很好，但是與WS標準結合的效果在現階段是未知的。
Nicholas Gall在他的分析中增加了松耦合的另一個方面：
這個列表遺漏了松耦合最重要的一個方面：普遍性。如果我和唯一的另一合作伙伴采用了世界上最動態的可重新配置的中間件架構，那么他和我就緊密的彼此聯系到一起了。試想我們兩人設計出了WS-*的自家變種，姑且稱之為WS-Silo。那么，我們之間可以在一端進行隨意的變更，而不會破壞另一端。但是，我們不能和其他的任何人進行互操作。
盡管在怎樣達到松耦合上并沒有獲得一個廣泛認同，但是在眾多人的意見中，它的目標是一致的——通過將系統變得彼此來降低改變它們的成本。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
