這一節將詳細討論，今天各個企業應用怎樣進行集成、或者怎樣沒有集成。還包括對今天很多組織中很流行的集成方式：偶然架構的討論。
在過去二十年以來，無數分布式計算模型一一登場：包括 DCE、CORBA、DCOM、MOM、 EAI Broker、J2EE、Web Services、.NET。 然而，跡象表明，不管采用何種技術，只有很少數企業的應用時很好連通的。按照來自 Gartner 公司的一個研究報告[1]，這個數字少于10%。
關于應用的連通性，其他的統計數結果更令人吃驚，— 只有 15% 的應用的集成采用了正式的集成中間件。其余則使用 ETL 和批量文件傳輸技術，其主要以手工編寫的腳本和其他定制方案為基礎。關于 ETL 和批量文件傳輸的更多信息，以及他們相關的問題，我們在第9章討論。
Gartner 15% 統計值提供一個關于當今的集成狀態的一個令人深思的數據。那么其他85% 的應用是如何連接的呢? 一種在今天的企業中普遍存在的情形，我將其稱為是“偶然架構”。所謂偶然架構就是沒有人公開宣布創造的；相反，是多年積累的一種“就事論事”的解決方案。在一個偶然架構中，公司的應用被永遠鎖定在一個不靈活的剛性基礎架構之上。然后他們又被視為是信息“地牢”，因為集成基礎設施不能適應新的業務需求。 (圖 2-1)
大多數集成嘗試都從某個深思熟慮的設計開始，但是經過一段時間后，其他的部分好像都各就各位地“集成”了，但是手工編寫的代碼卻早已飄移出原來的內容之外。經過逐漸進行的螺栓和補丁，所謂整合的系統已經失去了其原來的設計完整性，尤其是如果系統是被很多的人來維護的，而他們對最初的設計意圖可能沒有很好地溝通。事實上，這種“就事論事”的方法將完全失去集成的一致性，因為工程師總將是“只是做一點點修改”作為解決問題的權益之計。最后甚至對找出那些地方做了修改都變得非常困難，更不要說要理解這些結果導致了那些方面的副作用影響。在一個部署系統中，這可能會對你的業務造成損失慘重的悲慘結果。
對集成遵守標準能夠為你創建一個針對所期望功能的基線來遵從。如果基礎設施是專有的， 不基于標準的，那么隨時間變化保持計劃的設計和指導原則就變成棘手問題。雖然也可以構造專有的平臺并且變通規則，但是這通常又導致更加“多樣性”的后果，結果更加鎖定于其上。然而，你應該記住的是簡單地遵守標準并不必然地阻止你構建一個偶然架構。
圖表 2?1 偶然架構將永遠使公司的應用成為“信息發射井”
在偶然架構背后的技術是各不相同的。圖 2-1中的實線、虛線和點劃線表示了連接應用的不同技術。這些技術可能包括 FTP 文件傳輸、直接的socket連接 、專有的MOM、以及有時是 CORBA 或其他類型的遠程過程調用(RPC) 機制。某些定向的點對點解決方案可能已經使用了XML信封定義，或者基于SOAP或者其他什么機制的技術，來為集成的應用之間承載數據。
圖中間的集成Broker表示了在部門級的層次連接應用的一個島嶼。然而這并不意味著它能夠連接任何事物。集成Broker通常只是結交給基礎設施中的某一塊，因此資金豐富的項目可能會取得適度的成功，但是它們再也不能與其它所承諾的部分進行很好的集成。
偶見架構表現為得到一個剛性的，不能對集成提供一致的、持久的基礎設施。它不能如其應該達到的效果那樣很好地解決你的組織性的問題。要改變偶然架構一直以來就是個挑戰，因為點對點的解決方案的數量不斷在增長。這通常也意謂著應用之間的互相依賴性是緊密耦合的。使應用中的數據的表現的修改意謂著你還必須修改共享該數據的其他所有應用。這就限制你快速地改變你的業務流程，以適應變化了的或者新的業務機會。這些緊密耦合的、硬連接的接口不僅僅是偶然架構的問題。因為控制流、業務應用之間的通信的編排被硬編碼進應用本身之中，這進一步導致了復雜化。這些都增加了系統之間的緊密耦合和脆弱性，使變更業務流程更加困難，并且導致了廠商所定。
偶然架構的先天技術不足隊組織中的人力協調問題具有推波助瀾的作用。不管問題是緊密耦合的接口還是硬編碼的流程編排，要想回頭或者對其進行較大的翻新改造簡直是一件恐怖的事情。這經常需要安排大量的會議，和屬于不同項目的不同的開發組的人們開會，就緊緊對要做什么以及何時做這類的問題達成一致。如果應用，以及他們分屬的開發項目組，分別處于不同的地理位置和時間區，應用改變所需的協調問題則會變得更加困難。
有時某些應用程序被視為“遺留”系統，對他們你是不愿意或不能夠對其進行多少修改，因為它們已經進入維護模式。我們通常說，“遺留系統”的一個定義就是那些你昨天剛安裝的系統。即使你對自己開發的應用具有完全的訪問和源代碼的控制權，當開發人員繼續進行其他項目或離開公司的時候，對其進行修改也是非常困難的。我們將會在第 4 章中看到， ESB 大大地減少了隨時間變化，修改數據模式和格式所帶來的影響。
即使你已經對跟蹤和修改應用數據及其接口建立了良好的公司實踐，偶然架構仍然還有其他缺點。使用不同的連接技術意謂著安全模型可能是混雜的，所以沒有確定的方式來建立和執行公司級的安全策略。 對插入新的應用沒有一致的 API可以依賴，而且沒有基礎來在棋上構建公司關于集成的最佳實踐。最近與一些領導的專家進行了交流，總結了偶然架構的下列各項問題:
應用之間的通信或許能得益于異步的消息的可靠性。如果一個大型業務流程中的某兩個應用之間的通信連接失敗，整個業務流程可能會事務性地返回或者重啟。我們將會在第5章學到更多有關松散耦合的、異步的可靠消息的更多內容。
不管你是否你已經有了一個預先的性能規劃并且試圖分析一個現有的性能問題，由于偶然架構的許許多多的子系統和他們各自的運行特征，這個工作是極其困難的。通常的做法是采用混雜的、“投入資源到其中，直到它能正確運行”式的解決方法，這將造成磁盤、處理器、內存等上面的過度開支。
沒有哪個單一方法能夠提供充分的診斷和報告能力。 意外架構需要很多具有很高能力的維護人員圍著所有有缺陷得生產系統轉，這將導致整體擁有成本 (TCO)的急劇上升。各部分實現的方式差異越大，在其失效時需要用來解決它們的問題的專家經驗就越寬。另外，建立一個基線來描述期望的正確行為也是一個挑戰。
沒有任何方式能夠保證這個泥潭中的所有組建都能夠滿足你的關于可接受的冗余、彈性和容錯度的定義。這意謂著要為依賴于后段系統的新功能定義可達到的服務級別協議 (SLAs) 是很困難的。
如果你的系統攜帶又能夠收費的帳單數據 ( 比如電信)，那么賬單數據的利息就可以被丟失在偶然架構之中。因此，你可能會損失收入并且還一點都不知道。
沒有一致的方法來監控和管理一個偶然架構。假定你的整合應用系統必須運行 24/7 ，而且你的職員負責關注運行監控工具，并且做出糾正。這些工具將不會以相同的方式工作，那么在無數不同的小方案的基礎上進行培訓 ( 和再培訓) 將是非常昂貴的事情。簡單地安裝企業級的運行管理工具并不能自動地將自省能力提供給集成基礎設施，并且偶然架構通常并不能提供所有可能需要的控制點。
總而言之，偶然架構表現為一種剛性的、高成本的基礎設施，并且不能滿足你的組織變更的需要，還要承受以下缺點的痛苦：
- 緊密耦合的、易碎的、對變更不靈活的
- 因為多個點對點解決方案導致的昂貴的維護負擔
- 修改一個應用程序可能影響其他很多應用
- 路由邏輯是硬編碼到應用程序之中的
- 沒有通用的安全模型；安全是混雜的
- 沒有通用的 API(通常)
- 沒有通用的通信協議
- 沒有建立和構建最佳實踐的通用基礎
- 難以支持異步處理
- 不可靠
- 沒有對應用和集成組件的健康監控和部署管理
如你所知，偶然架構的創建已經有些年頭了，要替換和解決它并不是一蹴而就的事情。隨著繼承項目的需求的增加，解決方案應該更加柔性的、簡單、以及運行便宜，而不是其他什么東西。偶然架構給了你的那些敏捷的競爭者得到好處，而你卻不能夠在一個合理的時間范圍內實現新的業務機會。
你需要一個內聚的架構，面向實踐、標準來解決著大量的問題。ESB 提供了架構和基礎設施，并且使你能夠逐個項目的基礎上采用它。采用 ESB 并不是全有或全無，推倒重來式的方式。而是，你可以漸進式地采用它，同時還能利用你的現有資產-包括偶然架構和集成Broker，以一種“留下而分層”的方式。
2.2.3 ETL，批量傳輸，和 FTP
提取、轉換、和載入 (ETL) 技術，比如 FTP 文件傳輸和每夜批處理式的集成在今天仍然是最流行的方法。
這通常涉及到將位于各個應用中的數據打包然后上傳這樣的操作。問題是有很大的可能在應用間的數據失去同步。一個失敗的打包上傳的處理程序可能要花上一天的時間。在京及和業務全球化的情況下，系統以24/7 的方式運行，再也沒有了“夜晚”的概念，那你得批處理又該在何時執行呢？
其他問題也可能與每夜的批處理相關。因為批處理的反應期問題，在分析關鍵業務數據的時候，最好的情形是24 小時輪轉時間。這一延遲可能嚴重地阻礙你對隨時變化的業務事件進行反應的能力。
有時，一次跨越多個面向批處理系統的端對端處理處理甚至會花費一整個星期才能完成。處理從源頭到目標的數據的總體潛伏反應期完全阻止了收集具有意義的，反應目前業務情形的數據的洞察力。比如，在供應鏈的場景中，這將導致你永遠不知道你的庫存的真實狀態。
第 9 章將會呈現一個通過FTP進行成批傳輸的技術和業務意義的案例研究，并且會研究ESB如何能幫助你逃脫偶然架構的困境。
2.2.4 集成Broker
集線器-和-插頭的集成Broker，或者EAI Broker，提供了偶然架構的替代。集成Broker是從上世紀90年代出現在，現在已經被植入到MOM主干或應用服務器平臺之中。
集成Broker市場的一些公司包括:
- SeeBeyond
- IBM
- webMethods
- TIBCO
- Ascential (Mercator)
- BEA (more recently)
- Vitria
集成Broker能夠使用一個集線器-和-插頭架構幫助偶然架構提供應用之間的集中路由。此外，他們還允許使用業務程序管理 (BPM) 軟件將業務流程從下層的集成代碼中分離出來。到此為止，所有的都是好消息。
然而，對集成Broker方式也有缺點。一個集線器-和- 插頭拓撲不允許對局部集成域之上進行局部控制。構建在一個集線器-和-插頭拓撲之上的BPM 不能夠建立跨越部門和業務單位的業務流程極其編排。 集成Broker也可能受限于下面的MOM不能越過物理的LAN網段和防火墻的能力限制。
有許多公司已經在其集成策略中采用了集線器-和-插頭的集成Broker解決方案。 這些技術具有較高的成本，并且成功也值得懷疑。1990 年代后期的昂貴集成Broker項目已經取得了名義上的成功，但是將組織置于專有的集成域的井中。一項Forrester在2001 年十二月發布的研究報告[2] 展示了下列各項統計:
- 集成項目平均 20+ 個月才完成
- 少于 35% 的項目能夠準時和在預算內完成
- 35% 的軟件維護預算被花費在維護點對點應用連接之上
- 在 2003 年， 全球 3500 家企業平均期望花費六百四十萬美元到集成項目上
這項研究還是在EAI 在它的最尖峰的時候進行的，而且幾乎沒有跡象表明這一數字在那時候起之后得到了改善。注意一年六百四十萬美元是公司會在集成項目上花費的平均數的一個預測。當于這些公司的領導們交流這些問題的時候，我進行了一個一般性的求證。
照今天的預算標準來看，EAI Broker項目是很昂貴的。集成軟件費用很貴的，通常單獨對于軟件許可費用，每個項目的價格范圍就在從 $250,000 到一百萬美元不等。這還不算一起的咨詢服務組件，而這個組件的價格往往是軟件許可費用的5到12倍。
集成Broker高昂的啟動成本又被另一事實所進一步惡化，即從一個項目中學到的知識不能很好地轉移到下一個項目。由于傳統的 EAI Broker技術的專有特性，通常具有很陡峭的學習曲線，對于每個項目來說，有時候實6個月。要試圖彌補這個負擔的通常方式是聘請事前對專有技術經過培訓的特別的顧問。當然，高特殊性=高價格。這是高昂咨詢費用的一個重要組成部分( 另一個大的組成是技術安裝、配置、部署、和管理的復雜性)。并且一旦項目完成，顧問就不見了。
集成項目的實現時間普遍是在 6-18 月之間。這意謂著。根據事前針對短期設定的標準、以及項目資金，實施時間吃掉了項目原本想要利用的策略性窗囗。
集成Broker的專有性質，以及高昂的咨詢費用通常導致供應商鎖定和重啟后續項目的巨大成本。這意謂即便對于成功的項目，增長和伸展也是令人恐懼的。而且在你對你的供應商或者實現心生不滿的時候，你也得面對到底是就目前的情況繼續走下去，還是選擇完全重新開始，雇用更多的咨詢顧問或者投入另一個新的學習曲線之間左右為難。因為所有這些，一些IT組織通常留下了一些難以再集成到其他項目的“集成孤島”。總而言之，集成Broker已經證明是偶然架構里面的老套技術，而并非它的解決方案。
當我們更詳細地討論集成Broker的時候，我們將看到導致這里所列的問題的技術屏障。另外，許許多多的非技術因素也導致了對采用ESB的需求的增長。
[1] [2]來自 Gartner 公司的統計,"集成Broker，應用服務器和 APSs,"10/2002.
[2] [3]來自 Forrester 研究的統計學,"減少集成費用,"12/2001.