松耦合

松耦合通訊機制提供了緊耦合機制所沒有的許多優點，並且它們有助於降低客户端和遠程服務之間的依賴性。但是，緊耦合性通常可以提供性能好處，便於在客户端和服務之間進行更為緊密的集成。

最近，人們越來越熱衷於比較應用程序交互的 ^[1]  松耦合方法和緊耦合方法。

造成這個趨勢的主要技術原因是：使用UDDI(Universal Description, Discovery and Integration，通用描述、發現和集成)等標準，Web服務可以動態地發現和綁定到其他服務。

而主要業務原因是：企業越來越需要靈活地處理業務流程的更改以及與合作伙伴的交互方式。松耦合系統的優點在於更新一個模塊不會引起其它模塊的改變。

傳統上，業務流程是在企業範圍，甚至在企業的不同業務單元內開發。這些活動在詳細的實時信息的幫助下進行管理。跨多個業務單元或跨企業的流程必須更加靈活，以應對各種各樣的需求。在這種情況下，可能出現更多的不確定性：參與者及其角色不斷變化，所需的交互類型也不斷變化。

在運營狀況起伏不定的環境下，必須有一個松耦合架構，以降低整體複雜性和依賴性。松耦合使應用程序環境更敏捷，能更快地適應更改，並且降低了風險。除此之外，系統維護也更方便。在B2B領域，由於要求業務實體之間獨立交互，因此松耦合顯得尤為重要。

業務合作伙伴之間的關係變化莫測，聯合關係時而建立，時而又斷絕，還需要在商業合作伙伴之間建立業務流程以滿足市場的要求。兩家公司在某一市場是合作伙伴，而在另一市場卻可能是競爭對手。底層IT基礎結構要適應這樣的靈活性和獨立性要求。

理想情況下，業務關係應當互不影響：在建立新型業務關係時，不對已有的業務關係造成影響。為一個業務合作伙伴提供的功能或許不應當供給另一個合作伙伴；與一個業務合作伙伴相關的更改不應對其他合作伙伴造成影響。一個商業合作伙伴不應為了等待一個同步響應，而阻塞另一個合作伙伴。IT系統的可用性也不應依賴於業務合作伙伴IT系統的技術可用性。

所謂“耦合”，指將兩個元素像鏈子一樣連接在一起。

在軟件領域，“耦合”一般指軟件組件之間的依賴程度。那麼，什麼是依賴？各種依賴對 ^[2]  耦合度和鬆散度有多大影響？軟件耦合可以發生在許多級別。必須區分生成時(編譯時)依賴和運行時依賴。在分佈環境中，為了確定系統的耦合程度，必須分析各個級別。表3-1簡要介紹了這些級別，以及這些級別與緊耦合-松耦合的關係。

表3-1 緊耦合與松耦合

下面將詳細分析表3-1中的各項。

在研究分佈系統的“耦合”問題時，與遠程組件的連接方式可能是最重要的技術因素。

在物理級別上，物理中介支持松耦合。MOM系統鬆散耦合，消息隊列扮演中介角色，解耦合消息的發送者和接收者。而RPC形式的應用程序緊密耦合，因為客户端和服務器直接交互，客户端要求服務器可用、可訪問，以達到交互目的。

如前所述，在“通信方式”級別上，同步和異步通信對耦合級別的影響經常與分佈式組件的物理鏈接密切相關。異步通信通常與松耦合相關。不過，這要求底層中間件能以松耦合方式支持異步通信。以單向RPC為例：雖然客户端不等待服務器的應答，但單向RPC仍然緊耦合，因為只有當客户端直接連接到服務器，而且服務器正在工作和運行時，客户端才能發送單向請求。這是説明各種耦合度的極好例子：在適當MOM基礎上建立的異步通信比異步單向RPC調用的耦合程度更低。

再來研究分佈式應用程序的“類型系統”級別的“耦合性”。可以看到，類型系統越強，系統不同組件的依賴程度也越高。無論在應用程序開發階段，還是在更改和重新配置運行的系統時，都是如此。前面分析過“接口語義”和“載荷語義”的差別。接口語義提供了顯式的接口名、操作名和強類型參數。

因此，組件在這個級別上達到緊耦合的程度，因為每次更改接口時，需要考慮依賴的組件，影響會波及到整個應用程序。這樣做的好處是：可以在編譯時發現受影響的應用程序部分，使其適應和反映更改，避免不兼容的消息格式引起運行時異常。載荷語義的消息格式通常更靈活，故能降低組件的耦合級別。

有些情況下，可應用消息格式驗證，如XML Schema驗證。但是，這要求參與者之間有效管理的最新模式定義。注意，使用載荷語義並不能消除更改消息格式的問題：開發人員必須瞭解受更改影響的系統部分，確保在採用新格式時，這些部分能正常運行。很多情況下，這往往意味着問題從生成時轉移到運行時。

分佈式組件的“交互模式”對耦合度有何影響呢？

以基於ORB的系統為例，該系統通常採用面向對象的方式在複雜對象樹中導航。客户端不僅需要了解各個對象的邏輯，還必須瞭解如何在對象間導航，從而導致了高耦合性。RPC形式接口不支持這類複雜導航，但與分佈對象系統相比，耦合程度降低了。基於MOM的系統一般採用更簡單的交互模型，單個隊列通常已足以作為客户端的輸入點，服務器端事務的所有輸入在單個消息中提供。

在談到這個問題時，需要考慮系統是基於RPC形式服務構建，還是基於隊列和主題而構建。一般而言，主題和隊列更靈活些，通過調整隊列配置及關聯方式，允許在運行時更方便地更改系統。大多數MOM系統強大的配置管理極大地降低了系統組件之間的耦合程度。

另一個重要因素是處理邏輯的所有權或控制。如果集中管理過程，則不同子過程和事務之間將緊密耦合。例如，數據庫機制可用於確保不同子過程所擁有數據的參考完整性和總體一致性。在大型單片式系統(如ERP)中，經常能看到這種情況。如果業務流程高度分佈(例如在B2B環境)，則不同子過程和事務通常更獨立，耦合程度更低。這時，必須接受一個現實：不存在全局定義的統一過程狀態。同樣，不同參與者擁有的數據可能不一致：一個系統已刪除了一封訂單，而另一個系統仍保存着清單。

最後，系統參與者互相定位的方式對系統的耦合級別有顯著影響。靜態綁定的服務耦合性非常高，而動態綁定的服務則鬆散耦合。在命名和目錄服務器中查找服務可以降低服務之間的耦合程度，客户端只需要瞭解待綁定服務的準確名稱即可。UDDI等服務允許使用諸如“Find me the next printer on the second floor”等約束，更靈活地定位服務。注意，UDDI為Web服務提供的動態服務發現並不是一個新概念，在此之前，CORBA命名服務等標準也支持服務發現。過去的經驗證明，需要完全動態服務發現的應用程序數量少而又少。

在制定架構決策時，必須認真分析耦合級別的優缺點。一般而言，大企業使用的OLTP(online transaction processing），在線事務處理)應用程序對松耦合的要求不高，這些應用程序在本質上是緊耦合的。若超出一個企業或一個業務單元的範圍，例如在B2B環境中，松耦合可能是惟一可選的解決方案。大多數情況下，利用松耦合來增加靈活性都會引來相應的代價：增加系統複雜度。為了運用更高級松耦合系統概念，開發工作會更繁重，對開發人員的技術要求也更高，還必須購買價格不菲的隊列系統產品。但從長遠看，如果經常調整耦合系統，則松耦合投資會引來豐厚回報。

鑑於松耦合是SOA的基礎，我覺得對於雲計算也是這樣，也許對於將松耦合分解成為很多基礎模式，這會是個不錯的主意，這些基礎模式包括：位置獨立性、通信獨立性、安全獨立性和實例獨立性。

位置獨立性引用了不管服務在哪裏的概念，需要利用這個服務的其餘組件在目錄中發現它，並通過後期綁定流程利用它。當你利用服務持續地改變物理和邏輯位置時，遲早會用到，尤其是服務在組織外部，你可能還沒有已交付的雲資源。你的風險評估服務可能只是在週一提議上存在，而在週二在雲端，這對你來説沒什麼不同。

動態探索是這個概念的關鍵所在，意味着調用組件可以按需定位服務新，不必緊密綁定服務。通常這些服務是私有的、共享的或者他們享有目錄內的公共服務。

通信獨立性意味着所有組件可以互相通信，不管他們在接口或者協議層怎樣通信。因此，我們利用授權標準，像Web服務，調解協議和接口區別。

安全獨立性引入了調節安全模型之間和組件之間的不同的概念。這種方式實現起來有點困難，但是對於任何SOA是必須的。為了實現這種模式，你必須利用聯合安全系統，該系統能夠創建組件之間的信任，無論什麼對於組件的是安全模型。這是若干聯合安全標準背後的主要驅動力，這些標準的出現為了支持松耦合模型和web服務。

實例獨立性意味着架構應該支持組件到組建的通信，這種通信使用同步和異步模型，在收到希求或者消息之前不需要其他組件在任何特定狀態。因此，如果正確執行，所有服務應該能夠異步地服務於任何請求組件，無論順序是怎樣的，也能夠記住消息狀態。