本系列編譯自 O'Reilly的《Enterprise Service Bus》，將陸續(xù)發(fā)布上來。
1 企業(yè)服務(wù)總線簡介
在一個事件驅(qū)動型企業(yè)中，影響業(yè)務(wù)流程的正常進程的業(yè)務(wù)事件可以以任何順序隨時發(fā)生。那些以自動化的業(yè)務(wù)處理方式交換數(shù)據(jù)的應(yīng)用需要使用事件驅(qū)動的 SOA 來彼此通信，以便能夠?qū)Σ粩嘧兓臉I(yè)務(wù)需求具有敏捷的反應(yīng)。SOA 向業(yè)務(wù)分析師和集成架構(gòu)師提供了處理高階服務(wù)的關(guān)于應(yīng)用和集成組件的寬泛的抽象視圖。而在 ESB，應(yīng)用和事件驅(qū)動的服務(wù)彼此以一種松散耦合的緊密地與流行的 SOA 維系在一起，這允許它們彼此能夠獨立運行，并且仍然能夠提供較寬廣的業(yè)務(wù)功能價值。
在 SOA 的王國，事件被表現(xiàn)為一種開放的XML格式文件，以及經(jīng)過一個對驗證開放的，可以協(xié)調(diào)的透明管線中的流（Flow）
—John Udell, InfoWorld
SOA 的服務(wù)組件暴露的是一種粗粒度的接口，其目的是使應(yīng)用之間能夠異步地共享數(shù)據(jù)。而使用 ESB，一種集成架構(gòu)將應(yīng)用程序和分離的集成組件拉在一起，以產(chǎn)生服務(wù)裝配組合從而形成復(fù)合的業(yè)務(wù)流程，進而自動化一個即時企業(yè)中的業(yè)務(wù)功能。
ESB 為SOA提供實現(xiàn)骨架。那就是說，它通過一個跨越多種協(xié)議的消息總線來提供一個有關(guān)命名路由目的地的高度分布的世界來提供松散耦合的，事件驅(qū)動的 SOA。ESB 中的應(yīng)用程序 (和集成組件) 在理論上是彼此解耦的，而且通過總線彼此連接為暴露為事件驅(qū)動服務(wù)的邏輯端點。
通過分布式的部署配置基礎(chǔ)設(shè)施， ESB 能有效率地提供對在擴展企業(yè)中分布的服務(wù)的中心配置、部署和管理。一種普遍集成的新方式應(yīng)用諸如SOA、EAI、B2B 和Web服務(wù)之類的技術(shù)的通常目標主要是創(chuàng)建一個集成架構(gòu)，且能夠深入并且跨越整個擴展企業(yè)。對于一個集成基礎(chǔ)設(shè)施到達到這種普遍性，它必須具有下列各項特性:
- 它必須能夠適應(yīng)多種集成情形項目的通常目的需要，不管是大型的還是小型的。適應(yīng)性包括提供一個能夠經(jīng)受協(xié)議、接口技術(shù)、甚至流程模型的變化趨勢的持久架構(gòu)。
- 它必須以一種單一和統(tǒng)一的方式，以及一個通用的基礎(chǔ)設(shè)施來連接擴越擴展企業(yè)的各種應(yīng)用。
- 它必須能夠擴展超出單一公司IT中心的邊界。并且自動化伙伴關(guān)系，比如在B2B 和供應(yīng)鏈的情況下。
- 它必須具有設(shè)計的簡單性和較低的進入門坎，使得日常的IT專業(yè)人員也能夠成為自我修練的集成架構(gòu)師。
- 它必須提供一個跨越普遍集成的 SOA，它能使集成架構(gòu)師能夠?qū)镜膽?yīng)用資產(chǎn)和自動化業(yè)務(wù)流程有一個廣泛的、抽象的視圖。
- 它需要有能夠反應(yīng)和符合不斷變更的業(yè)務(wù)需求和競爭的壓力需要的靈活性和能力。
在 ESB中，應(yīng)用和事件驅(qū)動服務(wù)以一種松散耦合的方式緊密地聯(lián)系在SOA 中。 這使得它們能夠彼此獨立運行，并且仍然能夠提供廣泛的業(yè)務(wù)功能價值。
ESB 架構(gòu)解決了這些需要，并且正在被各種通用的集成項目所采用。它也能夠在企業(yè)應(yīng)用層面普遍地伸展，不管是物理位置還是技術(shù)平臺。任何應(yīng)用都可以通過大量的連接選擇插入到一個 ESB 網(wǎng)絡(luò)中，并且可以立即參與到與那些通過總線暴露為共享服務(wù)的應(yīng)用之間的數(shù)據(jù)共享之中。這是 ESB 為什么經(jīng)常被稱為集成網(wǎng)絡(luò)（integration network）或集成構(gòu)造（fabric）的緣故。
ESB 提供為集成提供了一種高度分布式的架構(gòu)，并且具有能夠讓獨立的部門和業(yè)務(wù)單元能夠以一種逐漸增加的、可消化的分塊來構(gòu)建它們的集成項目的獨特能力。使用 ESB，部門和業(yè)務(wù)單元仍然能夠繼續(xù)在獨立的集成項目中維護它們自己的本地控制和自治，并且仍然能夠?qū)⑺鼈兊募捎媱澾B接到一個更大的、更全局的的集成網(wǎng)絡(luò)或網(wǎng)格之中。
1.2針對 Web 服務(wù)的SOA，如今已經(jīng)可用
Web 服務(wù)已經(jīng)通過為應(yīng)用間的互操作性提供一種基于標準的方式為面向服務(wù)架構(gòu)找到了新的重要性。Web服務(wù)的主要目的是提供了一種服務(wù)抽象，它允許應(yīng)用之間的互操作性使用不同的平臺和環(huán)境來構(gòu)建。這一個目標的實現(xiàn)將能夠提供一個應(yīng)用之間的普遍集成的更容易的路徑。
由于ESB的出現(xiàn)，現(xiàn)在有了一種方式能夠?qū)eb Services和SOA合并到一個意義非凡的架構(gòu)中，以將應(yīng)用和服務(wù)以一種高度伸縮的狀態(tài)集成到一個擴越擴展企業(yè)的骨架之中。ESB使用今天已經(jīng)成熟的技術(shù)立刻使得Web Services、XML、以及其他集成技術(shù)更加有用。
SOA 的核心原則對于普遍集成項目的成功至關(guān)重要，并且已經(jīng)在 ESB 中被徹底實現(xiàn)。 Web Services標準正在有朝著正確的方向前進，但是在提供企業(yè)級能力方面還未完成，比如安全性、可靠性、事務(wù)管理和業(yè)務(wù)流程編排。ESB 以這些領(lǐng)域中今天已經(jīng)確定的標準為基礎(chǔ)，而且已經(jīng)有實際實現(xiàn)部署在各種領(lǐng)域和行業(yè)中。ESB完全有能力跟上Web Services相關(guān)能力的革新進展步伐。第 12 章提供了更詳細的關(guān)于這一個主題的討論。
ESB 通過從EAI中介者（Broker）那里學來的概念和技術(shù)將Web Services和其他補充標準結(jié)合在一起。然而，ESB 并不僅僅是在同一個老式的EAI 集線器之上的簡單的Web Services外衣。
傳統(tǒng)的形式化的集成方法都有其優(yōu)缺點。第 1 章就展示了有關(guān)集成的一些高階的顯著特色， 范圍從左下方最不令人想要的，到右上方象限中的最令人想要的。
圖表 1?1 傳統(tǒng)的 EAI 中介器，應(yīng)用服務(wù)器，MOM和 ESB 的特性
傳統(tǒng)的 EAI 中介器，包括那些已經(jīng)構(gòu)建在應(yīng)用服務(wù)器之上的，使用一種集線器和插頭（hub-and-spoke）架構(gòu)。集線器和插頭有一些中心化功能的好處，比如路由邏輯和業(yè)務(wù)規(guī)則的管理，但是不能很好地伸展擴越部門和業(yè)務(wù)單位的邊界。第 2 章將討論使用集線器在集成中的早期嘗試的巨大代價，以及它們的初步成功。
應(yīng)用服務(wù)器可以通過標準協(xié)議進行互操作，然而它們是以一種緊密耦合的方式進行連接的，并且集成邏輯和應(yīng)用程序邏輯糾纏在一起。
EAI 中介器通過將應(yīng)用邏輯從集成和流程路由邏輯中分離出來提供了增加價值，然而你仍舊要忍受集線器-插頭架構(gòu)的痛苦。
面向消息中間件 (MOM) 提供了以松散耦合和異步的方式連接應(yīng)用的能力。然而，MOM自身需要在應(yīng)用中進行低級的編碼。使用傳統(tǒng)的MOM，以及定制的編程技術(shù)，比可以在分布式的集成解決方案上走得更遠。然而，沒有對路由邏輯的高階抽象，這種方式仍然要忍受集成邏輯難以連接，并且也和應(yīng)用邏輯糾纏在一起的痛苦。依賴于MOM的使用，即使是分布式特征也會受到限制，因為一些傳統(tǒng)的MOM基礎(chǔ)設(shè)施對實際的網(wǎng)絡(luò)邊界的跨越也不是做得很好。
最后，在 ESB 中，服務(wù)可以被配置而不是編碼。處理流程和服務(wù)能夠透明地跨越整個服務(wù)總線。ESB 提供了能夠很好地擴越集線器-插頭架構(gòu)范圍的高度分布式集成環(huán)境，并且清晰地分離了應(yīng)用邏輯和路由數(shù)據(jù)變換之類的集成邏輯。一個 ESB 架構(gòu)形成了一個消息集線器和集成服務(wù)的互連接性網(wǎng)格，具有一個徹底分布的集成網(wǎng)絡(luò)的功能性和智能性。
第 6 章更進一步描述在使用應(yīng)用服務(wù)器集成和使用ESB集成之間的對比。MOM的概念在第 5 章討論。第 2 章的 “附屬架構(gòu)”繼續(xù)討論業(yè)務(wù)流程路由邏輯和業(yè)務(wù)邏輯之間的分離。
ESB 的一個關(guān)鍵特性就是要為支持分布式的、松散耦合的業(yè)務(wù)單位和伙伴，比如自動化供應(yīng)鏈，提供支撐基礎(chǔ)。ESB 的這些能力是其固有的必要特征，并且是中間件廠商與那些想要創(chuàng)建大規(guī)模集成架構(gòu)的業(yè)界專家共同工作的結(jié)果。這些業(yè)界專家包括了大公司IT架構(gòu)師、以及電子市集貿(mào)易社區(qū)中想要基于共享服務(wù)、消息、XML何其他眾多的連接選擇來建立B2B集成骨架的改革者，并且要堅持遵守工業(yè)標準。第 3 章將會討論對 ESB 概念的創(chuàng)造有助益的許多催化劑。
同時，仍然必須解決的最大需要在于如何還沒有的最大需要被定址包括該如何有效地提供集成能力、比如應(yīng)用適配器、數(shù)據(jù)變換、以及能夠用于通用的集成項目，跨越多種集成情性的智能路由。并且需要超越于個別戰(zhàn)術(shù)性的集成項目之上的，更加通用的技術(shù)和更加架構(gòu)性的方式。
IT專家已經(jīng)對以前的一些技術(shù)趨勢失望，比如CORBA、或者EAI什么的。CORBA 有著與SOA 一樣的正確理念，但是其與生俱來就太復(fù)雜而難以維護，因為它依賴于應(yīng)用和服務(wù)之間的緊密耦合接口。EAI 也痛苦于對單個項目上的陡峭的學習曲線和昂貴的進入負擔 (下一章將詳細討論這個內(nèi)容)。真正需要的是SOA的簡單方式，以及可以被采用來適應(yīng)任何集成工作，大型或者小型，的一種架構(gòu)。此外，那就是需要一個能夠經(jīng)受協(xié)議、接口、甚至業(yè)務(wù)建模趨勢的變革的持久架構(gòu)。ESB的概念就是創(chuàng)建來解決這些需要的。
自從ESB 概念在 2002 年被首次引入，ESB 的集成方式已經(jīng)被中間件、集成和Web服務(wù)市場中的很多重要的廠商采用。其接受度正在穩(wěn)定持續(xù)地增長。
從2002年早期開始，分析公司，比如 Gartner 公司、IDC、ZapThink等，就已經(jīng)開始跟蹤和編寫有關(guān) ESB 的技術(shù)趨勢。在Gartner 公司于2002年發(fā)布的一份報告(DF-18-7304)中，分析師 Roy Schulte 這樣寫道：
一種新型的 企業(yè)服務(wù)總線架構(gòu)- 結(jié)合了面向消息中間件（MOM）、Web Services、數(shù)據(jù)變換和智能路由的基礎(chǔ)設(shè)施—將會 2005 之前在很多的企業(yè)中運行。
這些高功能、低成本的ESB能夠被很好地適應(yīng)作為面向服務(wù)架構(gòu)和企業(yè)神經(jīng)系統(tǒng)的主干。
那四個支柱—MOM、Web Services、數(shù)據(jù)變換和路由智能 — 表現(xiàn)了任何優(yōu)秀的ESB 的基礎(chǔ)。當我們探究 ESB 的時候，本書將會集中于其中每一個基礎(chǔ)和其他必須的組件的角色。我們還要討論將會討論 ESB 究竟能為企業(yè)做些什么、以及它的基本組件所扮演的角色。我們還要討論一些高階主題，包括橫越多種行業(yè)之上的實踐性使用的架構(gòu)性概述。
有許多中間件和集成廠商已經(jīng)，或者正在構(gòu)建，符合ESB描述的某些產(chǎn)品。并且這個名單還在不斷增加。附錄中列出所有的已知廠商。一些廠商已經(jīng)聲稱他們已經(jīng)開始提供 ESB了 ；而有些則正在計劃構(gòu)建；有些則只是在市場宣傳材料中使用這一技術(shù)術(shù)語而實際上背后還沒有實質(zhì)性的東西。當超過 25個廠商正在為相同的技術(shù)空間競爭的時候，這一個技術(shù)范疇注定要變成像上世紀90年代的應(yīng)用服務(wù)器一樣的炙手可熱。
這個清單中有個別廠商應(yīng)該特別提及。Sonic軟件最先倡導(dǎo)了這個概念，此后不久許多其他的較小廠商業(yè)進入此領(lǐng)域，聲稱他們也正在提供 ESB 或是正在開發(fā)之中。一但那些著名的集成公司，比如webMethods、SeeBeyond 和 IBM 最終搭上這趟巴士（“BUS”），并且想要開始建立他們的ESB，ESB 術(shù)語才真的開始廣泛引起業(yè)界注意，是一個強大的不斷發(fā)展技術(shù)范疇。
在本書寫作的時候，微軟公司還沒有對其Indigo項目和有關(guān)ESB發(fā)布任何公開的說明。然而，一些記者和分析師在Indigo項目宣布的時候還是將二者聯(lián)系起來。2003 年11月 30 日， ComputerWorld 的文章說，“開發(fā)人員的興趣被微軟的技術(shù)傷害了”，Gartner 公司的 Roy Schulte關(guān)于Indigo項目提出。
Roy Schulte，是Gartner 公司在斯坦福的一個分析師，注意到Indigo項目其實是微軟消息隊列（MSMQ）、公司的COM、COM+、.Net Remoting、以及Web Services技術(shù)的超集。“把它想成代表微軟公司的通信中間件計劃的簡化和統(tǒng)一，”他說，并說他認為Indigo是一個非常好的企業(yè)服務(wù)總線(ESB)。
Indigo以消息為基礎(chǔ)，并且打算結(jié)合MSMQ 和Web Services。可以提供一個消息總線的基礎(chǔ)。然而，其集成能力的其余部分則被鎖定到BizTalk 之內(nèi)，而它是一個集線器-插頭風格的集成服務(wù)器。為了成為真正的ESB，分布式消息總線和分布式集成能力都要具備。
如果Indigo項目完成，構(gòu)建于微軟平臺之上的應(yīng)用和服務(wù)將能夠更加吸引人地作為端點連接到ESB之上。將Indigo包含到微軟平臺和開發(fā)環(huán)境之內(nèi)將更加能夠使得應(yīng)用具有松散耦合和消息感知能力。