??? 最近，人們?cè)絹碓綗嶂杂诒容^應(yīng)用程序交互的松耦合方法和緊耦合方法。造成這個(gè)趨勢(shì)的主要技術(shù)原因是：使用UDDI(Universal Description, Discovery and Integration，通用描述、發(fā)現(xiàn)和集成)等標(biāo)準(zhǔn)，Web服務(wù)可以動(dòng)態(tài)地發(fā)現(xiàn)和綁定到其他服務(wù)。而主要業(yè)務(wù)原因是：企業(yè)越來越需要靈活地處理業(yè)務(wù)流程的更改以及與合作伙伴的交互方式。
?
??? 傳統(tǒng)上，業(yè)務(wù)流程是在企業(yè)范圍，甚至在企業(yè)的不同業(yè)務(wù)單元內(nèi)開發(fā)。這些活動(dòng)在詳細(xì)的實(shí)時(shí)信息的幫助下進(jìn)行管理。跨多個(gè)業(yè)務(wù)單元或跨企業(yè)的流程必須更加靈活，以應(yīng)對(duì)各種各樣的需求。在這種情況下，可能出現(xiàn)更多的不確定性：參與者及其角色不斷變化，所需的交互類型也不斷變化。
?
??? 在運(yùn)營(yíng)狀況起伏不定的環(huán)境下，必須有一個(gè)松耦合架構(gòu)，以降低整體復(fù)雜性和依賴性。松耦合使應(yīng)用程序環(huán)境更敏捷，能更快地適應(yīng)更改，并且降低了風(fēng)險(xiǎn)。除此之外，系統(tǒng)維護(hù)也更方便。在B2B領(lǐng)域，由于要求業(yè)務(wù)實(shí)體之間獨(dú)立交互，因此松耦合顯得尤為重要。業(yè)務(wù)合作伙伴之間的關(guān)系變化莫測(cè)，聯(lián)合關(guān)系時(shí)而建立，時(shí)而又?jǐn)嘟^，還需要在商業(yè)合作伙伴之間建立業(yè)務(wù)流程以滿足市場(chǎng)的要求。兩家公司在某一市場(chǎng)是合作伙伴，而在另一市場(chǎng)卻可能是競(jìng)爭(zhēng)對(duì)手。底層IT基礎(chǔ)結(jié)構(gòu)要適應(yīng)這樣的靈活性和獨(dú)立性要求。理想情況下，業(yè)務(wù)關(guān)系應(yīng)當(dāng)互不影響：在建立新型業(yè)務(wù)關(guān)系時(shí)，不對(duì)已有的業(yè)務(wù)關(guān)系造成影響。為一個(gè)業(yè)務(wù)合作伙伴提供的功能或許不應(yīng)當(dāng)供給另一個(gè)合作伙伴；與一個(gè)業(yè)務(wù)合作伙伴相關(guān)的更改不應(yīng)對(duì)其他合作伙伴造成影響。一個(gè)商業(yè)合作伙伴不應(yīng)為了等待一個(gè)同步響應(yīng)，而阻塞另一個(gè)合作伙伴。IT系統(tǒng)的可用性也不應(yīng)依賴于業(yè)務(wù)合作伙伴IT系統(tǒng)的技術(shù)可用性。
?
??? 所謂“耦合”，指將兩個(gè)元素像鏈子一樣連接在一起。在軟件領(lǐng)域，“耦合”一般指軟件組件之間的依賴程度。那么，什么是依賴？各種依賴對(duì)耦合度和松散度有多大影響？軟件耦合可以發(fā)生在許多級(jí)別。必須區(qū)分生成時(shí)(編譯時(shí))依賴和運(yùn)行時(shí)依賴。在分布環(huán)境中，為了確定系統(tǒng)的耦合程度，必須分析各個(gè)級(jí)別。表3-1簡(jiǎn)要介紹了這些級(jí)別，以及這些級(jí)別與緊耦合-松耦合的關(guān)系。
?
??? 
??? 下面將詳細(xì)分析表3-1中的各項(xiàng)。
??? 在研究分布系統(tǒng)的“耦合”問題時(shí)，與遠(yuǎn)程組件的連接方式可能是最重要的技術(shù)因素。在物理級(jí)別上，物理中介支持松耦合。MOM系統(tǒng)松散耦合，消息隊(duì)列扮演中介角色，解耦合消息的發(fā)送者和接收者。而RPC形式的應(yīng)用程序緊密耦合，因?yàn)榭蛻舳撕头?wù)器直接交互，客戶端要求服務(wù)器可用、可訪問，以達(dá)到交互目的。
?
??? 如前所述，在“通信方式”級(jí)別上，同步和異步通信對(duì)耦合級(jí)別的影響經(jīng)常與分布式組件的物理鏈接密切相關(guān)。異步通信通常與松耦合相關(guān)。不過，這要求底層中間件能以松耦合方式支持異步通信。以單向RPC為例：雖然客戶端不等待服務(wù)器的應(yīng)答，但單向RPC仍然緊耦合，因?yàn)橹挥挟?dāng)客戶端直接連接到服務(wù)器，而且服務(wù)器正在工作和運(yùn)行時(shí)，客戶端才能發(fā)送單向請(qǐng)求。這是說明各種耦合度的極好例子：在適當(dāng)MOM基礎(chǔ)上建立的異步通信比異步單向RPC調(diào)用的耦合程度更低。
?
??? 再來研究分布式應(yīng)用程序的“類型系統(tǒng)”級(jí)別的“耦合性”。可以看到，類型系統(tǒng)越強(qiáng)，系統(tǒng)不同組件的依賴程度也越高。無論在應(yīng)用程序開發(fā)階段，還是在更改和重新配置運(yùn)行的系統(tǒng)時(shí)，都是如此。前面分析過“接口語(yǔ)義”和“載荷語(yǔ)義”的差別。接口語(yǔ)義提供了顯式的接口名、操作名和強(qiáng)類型參數(shù)。因此，組件在這個(gè)級(jí)別上達(dá)到緊耦合的程度，因?yàn)槊看胃慕涌跁r(shí)，需要考慮依賴的組件，影響會(huì)波及到整個(gè)應(yīng)用程序。這樣做的好處是：可以在編譯時(shí)發(fā)現(xiàn)受影響的應(yīng)用程序部分，使其適應(yīng)和反映更改，避免不兼容的消息格式引起運(yùn)行時(shí)異常。載荷語(yǔ)義的消息格式通常更靈活，故能降低組件的耦合級(jí)別。有些情況下，可應(yīng)用消息格式驗(yàn)證，如XML Schema驗(yàn)證。但是，這要求參與者之間有效管理的最新模式定義。注意，使用載荷語(yǔ)義并不能消除更改消息格式的問題：開發(fā)人員必須了解受更改影響的系統(tǒng)部分，確保在采用新格式時(shí)，這些部分能正常運(yùn)行。很多情況下，這往往意味著問題從生成時(shí)轉(zhuǎn)移到運(yùn)行時(shí)。
?
??? 分布式組件的“交互模式”對(duì)耦合度有何影響呢？以基于ORB的系統(tǒng)為例，該系統(tǒng)通常采用面向?qū)ο蟮姆绞皆趶?fù)雜對(duì)象樹中導(dǎo)航。客戶端不僅需要了解各個(gè)對(duì)象的邏輯，還必須了解如何在對(duì)象間導(dǎo)航，從而導(dǎo)致了高耦合性。RPC形式接口不支持這類復(fù)雜導(dǎo)航，但與分布對(duì)象系統(tǒng)相比，耦合程度降低了。基于MOM的系統(tǒng)一般采用更簡(jiǎn)單的交互模型，單個(gè)隊(duì)列通常已足以作為客戶端的輸入點(diǎn)，服務(wù)器端事務(wù)的所有輸入在單個(gè)消息中提供。
?
??? 在談到這個(gè)問題時(shí)，需要考慮系統(tǒng)是基于RPC形式服務(wù)構(gòu)建，還是基于隊(duì)列和主題而構(gòu)建。一般而言，主題和隊(duì)列更靈活些，通過調(diào)整隊(duì)列配置及關(guān)聯(lián)方式，允許在運(yùn)行時(shí)更方便地更改系統(tǒng)。大多數(shù)MOM系統(tǒng)強(qiáng)大的配置管理極大地降低了系統(tǒng)組件之間的耦合程度。
?
??? 另一個(gè)重要因素是處理邏輯的所有權(quán)或控制。如果集中管理過程，則不同子過程和事務(wù)之間將緊密耦合。例如，數(shù)據(jù)庫(kù)機(jī)制可用于確保不同子過程所擁有數(shù)據(jù)的參考完整性和總體一致性。在大型單片式系統(tǒng)(如ERP)中，經(jīng)常能看到這種情況。如果業(yè)務(wù)流程高度分布(例如在B2B環(huán)境)，則不同子過程和事務(wù)通常更獨(dú)立，耦合程度更低。這時(shí)，必須接受一個(gè)現(xiàn)實(shí)：不存在全局定義的統(tǒng)一過程狀態(tài)。同樣，不同參與者擁有的數(shù)據(jù)可能不一致：一個(gè)系統(tǒng)已刪除了一封訂單，而另一個(gè)系統(tǒng)仍保存著清單。
?
??? 最后，系統(tǒng)參與者互相定位的方式對(duì)系統(tǒng)的耦合級(jí)別有顯著影響。靜態(tài)綁定的服務(wù)耦合性非常高，而動(dòng)態(tài)綁定的服務(wù)則松散耦合。在命名和目錄服務(wù)器中查找服務(wù)可以降低服務(wù)之間的耦合程度，客戶端只需要了解待綁定服務(wù)的準(zhǔn)確名稱即可。UDDI等服務(wù)允許使用諸如“Find me the next printer on the second floor”等約束，更靈活地定位服務(wù)。注意，UDDI為Web服務(wù)提供的動(dòng)態(tài)服務(wù)發(fā)現(xiàn)并不是一個(gè)新概念，在此之前，CORBA命名服務(wù)等標(biāo)準(zhǔn)也支持服務(wù)發(fā)現(xiàn)。過去的經(jīng)驗(yàn)證明，需要完全動(dòng)態(tài)服務(wù)發(fā)現(xiàn)的應(yīng)用程序數(shù)量少而又少。
?
??? 在制定架構(gòu)決策時(shí)，必須認(rèn)真分析耦合級(jí)別的優(yōu)缺點(diǎn)。一般而言，大企業(yè)使用的OLTP(online transaction processing，在線事務(wù)處理)應(yīng)用程序?qū)λ神詈系囊蟛桓撸@些應(yīng)用程序在本質(zhì)上是緊耦合的。若超出一個(gè)企業(yè)或一個(gè)業(yè)務(wù)單元的范圍，例如在B2B環(huán)境中，松耦合可能是惟一可選的解決方案。大多數(shù)情況下，利用松耦合來增加靈活性都會(huì)引來相應(yīng)的代價(jià)：增加系統(tǒng)復(fù)雜度。為了運(yùn)用更高級(jí)松耦合系統(tǒng)概念，開發(fā)工作會(huì)更繁重，對(duì)開發(fā)人員的技術(shù)要求也更高，還必須購(gòu)買價(jià)格不菲的隊(duì)列系統(tǒng)產(chǎn)品。但從長(zhǎng)遠(yuǎn)看，如果經(jīng)常調(diào)整耦合系統(tǒng)，則松耦合投資會(huì)引來豐厚回報(bào)。
?
??? 當(dāng)今的企業(yè)應(yīng)用程序環(huán)境混雜著多種不同技術(shù)和分布概念。一方面，這是由歷史原因、各人偏好及收購(gòu)和兼并造成的(甚至在同一個(gè)組織單元也存在多個(gè)冗余概念)；另一方面，企業(yè)中存在的各種補(bǔ)充概念和技術(shù)加重了復(fù)雜性。在一個(gè)企業(yè)中，不同類型的分布問題產(chǎn)生不同的需求，導(dǎo)致了不同解決方案共存的局面。
??? 現(xiàn)代架構(gòu)必須支持所有這些技術(shù)和概念。異質(zhì)性(包括中間件的異質(zhì)性)的存在是一個(gè)基本事實(shí)，我們無法阻止它，卻可有效地管理它。另外，架構(gòu)必須適應(yīng)底層分布基礎(chǔ)結(jié)構(gòu)的不斷變化。當(dāng)今基礎(chǔ)結(jié)構(gòu)產(chǎn)品與企業(yè)應(yīng)用程序的生命期大多不同，必須保護(hù)現(xiàn)有應(yīng)用程序環(huán)境的資產(chǎn)，并能利用最新的基礎(chǔ)結(jié)構(gòu)產(chǎn)品。
?
??? 通過本章的學(xué)習(xí)，您可了解到精心選擇正確方法來集成兩個(gè)分布式軟件組件的必要性。您必須選擇正確的通信基礎(chǔ)結(jié)構(gòu)、同步、調(diào)用語(yǔ)義和中介，并在“面向?qū)ο蟆焙汀耙詳?shù)據(jù)為中心”的接口之間做出選擇。所有這些決策都會(huì)影響兩個(gè)系統(tǒng)的耦合程度。
?
?