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