松耦合

最近，人們越來越熱衷於比較應用程序交互的松耦合方法和緊耦合方法。造成這個趨勢的主要技術原因是：使用UDDI(Universal Description, Discovery and Integration，通用描述、發現和集成)等標準，Web服務可以動態地發現和綁定到其他服務。而主要業務原因是：企業越來越需要靈活地處理業務流程的更改以及與合作夥伴的交互方式。

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

在運營狀況起伏不定的環境下，必須有一個松耦合架構，以降低整體複雜性和依賴性。松耦合使應用程序環境更敏捷，能更快地適應更改，並且降低了風險。除此之外，系統維護也更方便。在B2B領域，由於要求業務實體之間獨立交互，因此松耦合顯得尤為重要。業務合作夥伴之間的關係變化莫測，聯合關係時而建立，時而又斷絕，還需要在商業合作夥伴之間建立業務流程以滿足市場的要求。兩家公司在某一市場是合作夥伴，而在另一市場卻可能是競爭對手。底層IT基礎結構要適應這樣的靈活性和獨立性要求。理想情況下，業務關係應當互不影響：在建立新型業務關係時，不對已有的業務關係造成影響。為一個業務合作夥伴提供的功能或許不應當供給另一個合作夥伴；與一個業務合作夥伴相關的更改不應對其他合作夥伴造成影響。一個商業合作夥伴不應為了等待一個同步響應，而阻塞另一個合作夥伴。IT系統的可用性也不應依賴於業務合作夥伴IT系統的技術可用性。

所謂“耦合”，指將兩個元素像鏈子一樣連接在一起。在軟體領域，“耦合”一般指軟體組件之間的依賴程度。那麼，什麼是依賴？各種依賴對耦合度和鬆散度有多大影響？軟體耦合可以發生在許多級別。必須區分生成時(編譯時)依賴和運行時依賴。在分佈環境中，為了確定系統的耦合程度，必須分析各個級別。表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環境中，松耦合可能是惟一可選的解決方案。大多數情況下，利用松耦合來增加靈活性都會引來相應的代價：增加系統複雜度。為了運用更高級松耦合系統概念，開發工作會更繁重，對開發人員的技術要求也更高，還必須購買價格不菲的隊列系統產品。但從長遠看，如果經常調整耦合系統，則松耦合投資會引來豐厚回報。

當今的企業應用程序環境混雜著多種不同技術和分佈概念。一方面，這是由歷史原因、各人偏好及收購和兼并造成的(甚至在同一個組織單元也存在多個冗餘概念)；另一方面，企業中存在的各種補充概念和技術加重了複雜性。在一個企業中，不同類型的分佈問題產生不同的需求，導致了不同解決方案共存的局面。

現代架構必須支持所有這些技術和概念。異質性(包括中間件的異質性)的存在是一個基本事實，我們無法阻止它，卻可有效地管理它。另外，架構必須適應底層分佈基礎結構的不斷變化。當今基礎結構產品與企業應用程序的生命期大多不同，必須保護現有應用程序環境的資產，並能利用最新的基礎結構產品。

通過本章的學習，您可了解到精心選擇正確方法來集成兩個分散式軟體組件的必要性。您必須選擇正確的通信基礎結構、同步、調用語義和中介，並在“面向對象”和“以數據為中心”的介面之間做出選擇。所有這些決策都會影響兩個系統的耦合程度。