基本介紹
- 中文名：松耦合
- 外文名：coupling; loose coupling
- 定義：通常是基於訊息的系統
- 特點：降低客戶端和遠程服務之間的依賴
- 學科：一級學科、二級學科
- 關鍵字：松耦合、緊耦合
簡介,對比,物理級別,通信方式級別,類型系統級別,互動模式的影響,測試,
簡介
造成這個趨勢的主要技術原因是：使用UDDI(Universal Description, Discovery and Integration，通用描述、發現和集成)等標準，Web服務可以動態地發現和綁定到其他服務。
而主要業務原因是：企業越來越需要靈活地處理業務流程的更改以及與合作夥伴的互動方式。松耦合系統的優點在於更新一個模組不會引起其它模組的改變。
傳統上，業務流程是在企業範圍，甚至在企業的不同業務單元內開發。這些活動在詳細的實時信息的幫助下進行管理。跨多個業務單元或跨企業的流程必須更加靈活，以應對各種各樣的需求。在這種情況下，可能出現更多的不確定性：參與者及其角色不斷變化，所需的互動類型也不斷變化。
在運營狀況起伏不定的環境下，必須有一個松耦合架構，以降低整體複雜性和依賴性。松耦合使應用程式環境更敏捷，能更快地適應更改，並且降低了風險。除此之外，系統維護也更方便。在B2B領域，由於要求業務實體之間獨立互動，因此松耦合顯得尤為重要。
業務合作夥伴之間的關係變化莫測，聯合關係時而建立，時而又斷絕，還需要在商業合作夥伴之間建立業務流程以滿足市場的要求。兩家公司在某一市場是合作夥伴，而在另一市場卻可能是競爭對手。底層IT基礎結構要適應這樣的靈活性和獨立性要求。
理想情況下，業務關係應當互不影響：在建立新型業務關係時，不對已有的業務關係造成影響。為一個業務合作夥伴提供的功能或許不應當供給另一個合作夥伴；與一個業務合作夥伴相關的更改不應對其他合作夥伴造成影響。一個商業合作夥伴不應為了等待一個同步回響，而阻塞另一個合作夥伴。IT系統的可用性也不應依賴於業務合作夥伴IT系統的技術可用性。
對比
所謂“耦合”，指將兩個元素像鏈子一樣連線在一起。
在軟體領域，“耦合”一般指軟體組件之間的依賴程度。那么，什麼是依賴？各種依賴對耦合度和鬆散度有多大影響？軟體耦合可以發生在許多級別。必須區分生成時(編譯時)依賴和運行時依賴。在分布環境中，為了確定系統的耦合程度，必須分析各個級別。表3-1簡要介紹了這些級別，以及這些級別與緊耦合-松耦合的關係。
表3-1 緊耦合與松耦合
級 別 | 緊 耦 合 | 松 耦 合 |
物理耦合 | 需要直接的物理連結 | 物理中介 |
通信方式 | 同步 | 異步 |
類型系統 | 強類型系統（例如接口語義） | 弱類型系統（例如載荷語義） |
互動模式 | 以OO方式導航複雜對象樹 | 以數據為中心，獨立訊息 |
過程邏輯的控制 | 集中控制處理邏輯 | 分散式邏輯組件 |
服務發現和綁定 | 靜態綁定服務 | 動態綁定服務 |
平台依賴性 | 對作業系統和程式語言的依賴性高 | 獨立於作業系統和程式語言 |
下面將詳細分析表3-1中的各項。
在研究分布系統的“耦合”問題時，與遠程組件的連線方式可能是最重要的技術因素。
物理級別
在物理級別上，物理中介支持松耦合。MOM系統鬆散耦合，訊息佇列扮演中介角色，解耦合訊息的傳送者和接收者。而RPC形式的應用程式緊密耦合，因為客戶端和伺服器直接互動，客戶端要求伺服器可用、可訪問，以達到互動目的。
通信方式級別
如前所述，在“通信方式”級別上，同步和異步通信對耦合級別的影響經常與分散式組件的物理連結密切相關。異步通信通常與松耦合相關。不過，這要求底層中間件能以松耦合方式支持異步通信。以單向RPC為例：雖然客戶端不等待伺服器的應答，但單向RPC仍然緊耦合，因為只有當客戶端直接連線到伺服器，而且伺服器正在工作和運行時，客戶端才能傳送單向請求。這是說明各種耦合度的極好例子：在適當MOM基礎上建立的異步通信比異步單向RPC調用的耦合程度更低。
類型系統級別
再來研究分散式應用程式的“類型系統”級別的“耦合性”。可以看到，類型系統越強，系統不同組件的依賴程度也越高。無論在應用程式開發階段，還是在更改和重新配置運行的系統時，都是如此。前面分析過“接口語義”和“載荷語義”的差別。接口語義提供了顯式的接口名、操作名和強類型參數。
因此，組件在這個級別上達到緊耦合的程度，因為每次更改接口時，需要考慮依賴的組件，影響會波及到整個應用程式。這樣做的好處是：可以在編譯時發現受影響的應用程式部分，使其適應和反映更改，避免不兼容的訊息格式引起運行時異常。載荷語義的訊息格式通常更靈活，故能降低組件的耦合級別。
有些情況下，可套用訊息格式驗證，如XML Schema驗證。但是，這要求參與者之間有效管理的最新模式定義。注意，使用載荷語義並不能消除更改訊息格式的問題：開發人員必須了解受更改影響的系統部分，確保在採用新格式時，這些部分能正常運行。很多情況下，這往往意味著問題從生成時轉移到運行時。
互動模式的影響
以基於ORB的系統為例，該系統通常採用面向對象的方式在複雜對象樹中導航。客戶端不僅需要了解各個對象的邏輯，還必須了解如何在對象間導航，從而導致了高耦合性。RPC形式接口不支持這類複雜導航，但與分布對象系統相比，耦合程度降低了。基於MOM的系統一般採用更簡單的互動模型，單個佇列通常已足以作為客戶端的輸入點，伺服器端事務的所有輸入在單個訊息中提供。
在談到這個問題時，需要考慮系統是基於RPC形式服務構建，還是基於佇列和主題而構建。一般而言，主題和佇列更靈活些，通過調整佇列配置及關聯方式，允許在運行時更方便地更改系統。大多數MOM系統強大的配置管理極大地降低了系統組件之間的耦合程度。
另一個重要因素是處理邏輯的所有權或控制。如果集中管理過程，則不同子過程和事務之間將緊密耦合。例如，資料庫機制可用於確保不同子過程所擁有數據的參考完整性和總體一致性。在大型單片式系統(如ERP)中，經常能看到這種情況。如果業務流程高度分布(例如在B2B環境)，則不同子過程和事務通常更獨立，耦合程度更低。這時，必須接受一個現實：不存在全局定義的統一過程狀態。同樣，不同參與者擁有的數據可能不一致：一個系統已刪除了一封訂單，而另一個系統仍保存著清單。
在制定架構決策時，必須認真分析耦合級別的優缺點。一般而言，大企業使用的OLTP(online transaction processing），線上事務處理)應用程式對松耦合的要求不高，這些應用程式在本質上是緊耦合的。若超出一個企業或一個業務單元的範圍，例如在B2B環境中，松耦合可能是惟一可選的解決方案。大多數情況下，利用松耦合來增加靈活性都會引來相應的代價：增加系統複雜度。為了運用更高級松耦合系統概念，開發工作會更繁重，對開發人員的技術要求也更高，還必須購買價格不菲的佇列系統產品。但從長遠看，如果經常調整耦合系統，則松耦合投資會引來豐厚回報。
測試
鑒於松耦合是SOA的基礎，我覺得對於雲計算也是這樣，也許對於將松耦合分解成為很多基礎模式，這會是個不錯的主意，這些基礎模式包括：位置獨立性、通信獨立性、安全獨立性和實例獨立性。
位置獨立性引用了不管服務在哪裡的概念，需要利用這個服務的其餘組件在目錄中發現它，並通過後期綁定流程利用它。當你利用服務持續地改變物理和邏輯位置時，遲早會用到，尤其是服務在組織外部，你可能還沒有已交付的雲資源。你的風險評估服務可能只是在周一提議上存在，而在周二在雲端，這對你來說沒什麼不同。
動態探索是這個概念的關鍵所在，意味著調用組件可以按需定位服務新，不必緊密綁定服務。通常這些服務是私有的、共享的或者他們享有目錄內的公共服務。
通信獨立性意味著所有組件可以互相通信，不管他們在接口或者協定層怎樣通信。因此，我們利用授權標準，像Web服務，調解協定和接口區別。
安全獨立性引入了調節安全模型之間和組件之間的不同的概念。這種方式實現起來有點困難，但是對於任何SOA是必須的。為了實現這種模式，你必須利用聯合安全系統，該系統能夠創建組件之間的信任，無論什麼對於組件的是安全模型。這是若干聯合安全標準背後的主要驅動力，這些標準的出現為了支持松耦合模型和web服務。
實例獨立性意味著架構應該支持組件到組建的通信，這種通信使用同步和異步模型，在收到希求或者訊息之前不需要其他組件在任何特定狀態。因此，如果正確執行，所有服務應該能夠異步地服務於任何請求組件，無論順序是怎樣的，也能夠記住訊息狀態。
