「完全解耦是極其困難和昂貴的，否則就是不可能的，」ron schmelzer如是說到，他是zapthink的高階soa分析師。一般人們都認為：系統要麼是松耦合的，要麼不是。在這篇最近的帖子中，schmelzer炮轟了這個信仰。儘管松耦合的重要性得到認識已經有些時日了，但是圍繞這個帖子展開的對話卻收集了一些有趣的討論。
schmelzer如此描述松耦合的7個維度：
實現服務契約
服務策略
過程資料模式
基礎設施
語義級別
這個報告是這樣說明松耦合實現級別的：
所有soa的實現必須在實現級別是松耦合的，但是顯然這並不足以保證達到業務期望的那種完全的松耦合。
服務契約提到了使用服務描述框架的好處：
服務描述框架（sdf）……是一種技術中立的服務契約模板。以那種方式，新的服務契約並不是簡單地替代舊的契約。除非給服務消費者提供乙個轉換路徑，否則舊契約就永遠不會被棄用。
延遲繫結的問題也被提了出來：
在這個舞台上[可能]的最佳實踐就是使用一種延遲繫結的方法，該方法利用了執行時註冊和基於契約的繫結，這樣抽象了特定於服務消費者的繫結，並使服務契約變更照成的影響不致於蔓延開來。
anil john就這一觀點表示懷疑：
直到我們解決跨web的無縫互操作問題之前（主要是xml到物件資料繫結引起的問題），由涉及產生和實現動態客戶端**的消費者來把執行時繫結到服務只不過就是一次視覺探索（visionquest）！在當前那些確實「利用執行時註冊和基於契約的繫結」的環境中，唯一可行的執行時辦法只限於動態繫結到不同的soap端點（它能在註冊中使用乙個執行時的查詢得到），當且僅當已經在潛在的生產者和消費者之間的web**中完成了上述的互操作測試。
報告將服務策略與服務契約這樣聯絡起來：
公司指望服務可變性在處理策略變更的方法與它們處理服務契約變更的方式一樣：延遲繫結、啟用服務仲裁、基於註冊和治理。
業務過程的處理是類似的：
通過在元資料中定義過程並使用服務契約暴露這些過程（作為服務暴露，服務組合時採用遞迴方式），可以把過程實現從服務消費者中抽象出來。
第一次提到對資料模式進行不同的處理：
模式是服務資料互操作能力的關鍵。但是，當模式發生變化時情況會怎樣呢？解決問題的乙個關鍵就在於將資訊和模式按照服務元資料相同的管理方式進行管理。資料模式被視為元資料的一種形式，並且異常管理、轉換、服務仲裁和資料服務全部都是資料結構松耦合的關鍵。
現在，再一次回頭看看服務契約中說的——「模式和服務契約沒有什麼不同」。
報告認為，儘管從基礎設施觀點來看，松耦合可能很容易定義，但是極少有廠商提供這種靈活性：
[這]意味著在任何時間，公司都可以改變他們的基礎設施，而無需重新構建所有的服務消費者和提供者。
最後的解決方案是在語義級別描述的——動態服務定義，其中「服務介面的定義必須基於服務請求者的上下文改變。結果是，服務可以在呼叫之間改變它們的契約」。這種寬鬆的語法看起來會和rest模型一起工作得很好，但是與ws標準結合的效果在現階段是未知的。
nicholas gall在他的分析中增加了松耦合的另乙個方面：
這個列表遺漏了松耦合最重要的乙個方面：普遍性。如果我和唯一的另一合作夥伴採用了世界上最動態的可重新配置的中介軟體架構，那麼他和我就緊密的彼此聯絡到一起了。試想我們兩人設計出了ws-*的自家變種，姑且稱之為ws-silo。那麼，我們之間可以在一端進行隨意的變更，而不會破壞另一端。但是，我們不能和其他的任何人進行互操作。
儘管在怎樣達到松耦合上並沒有獲得乙個廣泛認同，但是在眾多人的意見中，它的目標是一致的——通過將系統變得彼此來降低改變它們的成本。
SOA松耦合的依賴關係
1 什麼叫耦合 coupling 耦合是相互互動的系統彼此間的依賴。依賴分為真依賴 real dependency 和假依賴 artifical dependency 真依賴是系統從其他系統消費的特徵 feature 和服務的集合。真依賴總是存在，只要系統間存在互動，無法簡化。假依賴是系統為獲得其他...
授權的7個級別。
在 幸福領導力 一書中，和 專案與人員管理 一書中，同樣給出了7個授權級別，大家的說法都差不多，因此筆記整理之。概括 原地待命，奉命行事 完全無授權。2 推銷 你替他人做出決定，但你會嘗試說服他們接受你做出了正確的決定，並讓他們感覺也有參與其中。概括 看看這個，告訴我你的看法。然後我來決定。3 諮詢...
Linux的7個執行級別
0 關機 1 單使用者 找回丟失密碼 此模式下所有使用者不需要密碼即可登入，可用於重置密碼 2 多使用者狀態沒有網路服務 3 多使用者狀態有網路服務 4 系統未使用保留給使用者 5 圖形介面 6 系統重啟 常用執行級別是3和5 修改預設的執行級別 修改 etc inittab的id 5 initde...