許多新生技術都經受過試圖找到問題來解決以獲得采用的痛苦經歷。另一方面，ESB的概念是由業界領袖的架構師和技術社區中的領導廠商一起和定義和構建的，因此，ESB從誕生之時便得到采用。ESB正在或已經被用在多種行業，包括金融服務、保險、制造業、零售、電信、能源、食品分銷和政府。下面是一些例子。
- 一個領先的Subprime借貸公司實現了 ESB，減少了60% 的業務處理費用。這是通過在eCredit 系統、第三方信用機構、以及他們自己的后端系統之上建立一個統一的客戶數據視圖來達到的。
- 領先的銀行已經使用ESB實現了金融交易的直通處理，很客官地節省了手工處理成本。
- 一個派生的貿易系統依靠ESB每天為1,200用戶處理超過100,000 筆交易，記錄超過數十億美元的帳務。
- 世界最大的壽命和健康再保險公司，年收入二百億美元，將ESB作為理清在總部和銷售及管理其政策的保險代理商之間的后端交易數據的交換的解決方案，產生了可觀的費用節省。
- 一個櫥柜臺面和地板制造商通過使用ESB實現了一個一體化管理的存貨系統和“可用性承諾”查詢系統，提高了供應鏈的預見能力，減少了最低庫存報警的條件。在部署的第一階段， ESB被用來連接該制造商和其60個分銷商之間的供應鏈網絡。
ESB 的部署模型允許制造商在分銷商的地點部署ESB 服務容器。這是在每個遠程地點部署一個集成Broker方案的另一選擇。
- 一個主要的照明、電視和醫學成像的制造商正在使用 ESB 創建一個統一的集成主干來連接其遍布全球的業務單位，并且為全球的客戶創建一個統一的產品和訂單視圖。
- 使用一個基于標準的，集中的管理框架，一個全家的影像零售連鎖店正在采用ESB 基礎設施來通過一個中央管理和配置控制臺動態地配置和管理 1,800個遠程店鋪，
- 世界最大的郵購公司 (收入一百二十億美元)依靠 ESB 來從其許許多多的供應商訂購產品。
- 一個電話營運商的Web門戶網站依靠ESB來對用戶點擊進行分析跟蹤 (二小時的響應對 30 天的響應時間)， 并且每天處理一千六百萬個消息。
- 美國第二大的電信營運商，收入四百三十億美元，使用 ESB來從內部的系統向競爭者提供信息。
- 一家一百億美元的電力公司可靠地實現了 ESB，用來連接內部系統和政府強制的應用。 對帳務、系統管理、運行報告、以及法規強制的與競爭者的信息共享，提供了實時數據。
- 一個主要的歐洲食品分銷網 ( 一個十二億美元的分公司)在八個星期內實現了 ESB，并且節省了使用一個集中的集線器-插頭 Broker的集成方式所需的三百萬美元。ESB 通過管理供應鏈中的買、賣和物流協調，從肉類產品的配送到飼養家畜的飼料的生產，從而自動化了整個分銷網絡。
- 在這個食物分銷網絡中， ESB 集成了跨越三個不同的運行公司和許多第三方伙伴的應用，導致運行效率增加、可觀的費用節省、以及更容易的集成新系統的方法。
n 一個美國政府機構正在使用ESB 來整合多個政府系統，以滿足USA PATRIOT法案。USA PATRIOT法案允許政府跟蹤金融交易，以防止恐怖份子得到資金。該項目包括使用 ESB 來集成門戶服務器和各種政府機構中的后端系統，以提供一個統一的數據視圖。
概括起來， ESB 具有下列各項特性:
ESB 可以采用來適應各種集成情形下的各種通用目的集成項目的需要。它能夠構建跨越整個企業和其業務伙伴的集成項目。
松散耦合的集成組件可以在總線上以廣泛分布的地理拓撲進行部署，并且在總線中可以隨處作為共享服務進行訪問。
適配器、分布式的數據變換服務、基于內容的路由服務都可以在需要時有選擇地部署，并且可以獨立地伸縮。
通過總線進行通信的所有組件能得益于可靠消息、事務完整性、以及安全的認證通信機制。
ESB 允許數據流過插入到總線中的任何應用， 不管是本地還是遠程。
ESB 支持部門和業務單元級別的本地自治，并且仍然能夠在較大的受管的集成環境中整合。
每個個別的項目能進入一個更大的集成網絡，它們可以從總線上的任何地方進行遠程管理。
ESB 可以充分利用XML作為“原生”數據類型的好處。
ESB 提供了對及時業務數據的實時洞察能力。BAM能力已經被構建到ESB 框架之內。
你現在應該有了關于 ESB的足夠的信息來滿足你的好奇欲了。 接下來，在更詳細的章節中，你將會學到更多有關其底層技術方面的內容。下幾章將會討論 ESB 的進化、目前的集成狀態，采用XML來作為一個通用的數據交換架構以在不同的數據表示之間協調的好處，以及異步消息和MOM。
編碼RFID標簽分為兩個步驟。
首先是選擇唯一跟蹤所需識別的物品的身份識別方案。其次是將這個身份識別附加到RFID標簽之上。
3.2.1.1 決定身份編碼方案
身份識別是一個鑒別某個對象或者物品的身份的動作過程。但是什么是身份（identity）? 在 RFID中，身份是一串附加到物品你上的字母或者數字編碼，允許人工或者自動化設備能夠識別到該物品的類型甚至其唯一性。這正如你在圖書館查詢圖書時，書籍是使用杜威十進制分類法或者通用十進制分類法來標識的。但是目前的圖書分類法只能標識到書籍的類型而不能標識到
考慮到有時候需要進行實體的唯一性識別，比如產品、集裝箱、物理資產、動物甚至人類本身。對一個大型企業來說，在企供應鏈上同時可能有數以百萬的物品在流動。可以使用某種編號系統來對這些物品進行標識，但是如果在公司之外沒有人，或者系統能夠理解它們，其價值就大打折扣。所以需要行業的或者通用的標準方案。
1999年，美國的MIT、英國的劍橋、澳大利亞的Adelaide 、日本的Keio、中國的復旦以及新西蘭的St. Gallen大學與行業伙伴如Sun Microsystems 和 Gillette組成了Auto-ID 中心。它們希望能夠開發一個通用標準來減少單個標簽的成本。因為該成本也是采用RFID應用的一個主要組成部分，而標準可以促進業務伙伴之間的信息共享程度從而減少單位成本。2003年8月， EPCglobal公司接管了該標準的管理，而該研究中心繼續進行單獨的研究工作。EPCglobal是歐洲物品編碼國際組織（European Article Number International，即EAN International，現在是GS1)，統一代碼協會（Uniform Code Council，即UCC，現在是GS1 US)，以及想要在RFID領域重塑條形碼的EAN.UCC標準的成功的一些業界伙伴的合資企業。EPCglobal正在開發的標準的各個組件將構成一個所謂的“EPCglobal Network”。其理念是這個網絡將兼容構建在整個供應鏈之上的標簽、閱讀器、以及信息系統，制造商、分銷商、物流商以及零售商。EPCglobal 的編碼方案被稱之為電子產品代碼（Electronic Product Code ：EPC)。
在現今的物品跟蹤領域，主要使用的是EAN.UCC 條形碼，為什么還要在RFID系統中使用同樣的類似系統呢？事實上，我們可以在RFID標簽中使用現有的成熟的條形碼編碼方案。但這些系統基本上是設計來跟蹤物品的分類而不是單個物品的，但是如果加上序列號，光學代碼和二維條碼也可以用來跟蹤到個體。那么物品級別的跟蹤和RFID本身就是趨于一致的。比如，EPCglobal的版本1.1的標簽數據標準，就定義了一個通用的身份類型：通用標識符(General Identifier:GID)。同時還定義了衍生自EAN.UCC 產品代碼的五種特定的身份類型。這些特定的身份類型是在現有的EAN.UCC標識符，諸如連續全球貿易物品編號（SGTIN）或者連續運輸集裝箱代碼（SSCC）之上添加一個額外的資產引用編號或者序列號而得來。
比如使用統一資源標識符（URI）可以標識一個GID為：
urn:epc:id:gid:GeneralManagerNumber.ObjectClass.SerialNumber
那么，一個具體的GID可能會是這樣：
urn:epc:id:gid:00012345.054322.4208
GID中的urn:epc:id:gid 部分是靜態的，作為標識符的一個頭部（header），指出標識符的類型，以及基于EPC規范還會出現哪些字段域。該header后跟值字段域，其長度和編號是由header決定的。這三個段分別表示了GID的通用管理者編號（General Manager Number）、對象類（Object Class）， 以及序列號（Serial Number ）。
General Manager Number 標識了負責分配接下來的兩個字段域的編號的組織（通常為一個公司或者貿易集團) 。Object Class 標識了產品的類型或者族。最后， Serial Number 被標簽標識的對象類的一個特定實例。這種將一個特定范圍的編號委托給某個通用管理者的方式，在允許組織管理其自身的產品編號而不用提交到中心當局，同時又確保了不與其他組織的產品相混淆，這就提供了一種靈活性。
3.2.1.2 將編碼身份編碼到RFID標簽
選定編碼方案或者方法之后，必須考慮到如何將這個身份標識編碼（物理的）到RFID標簽之中。所謂編碼（Encoding）是將認可度的消息轉換為機器可讀的代碼所必須遵循的規則。每種識別標簽的類型，從條形碼到光學散射代碼到磁條再到RFID標簽，都各自有一zhogbiaoshi期身份的特定的編碼規則。
理論上講，一旦對某個物品建立了一個身份標識，我們只需要將其簡單地寫到標簽（Label）并將其貼到物品上即可。其它人就可以毫無困難地識別出它。但是，一個自動化的系統卻要困難得多。以某種特定的字體打印下來可能對機器識別來說要容易得多，但是如果該身份之需要能夠被自動系統閱讀，為什么還要花費精力來研究如何更好地打印。
今天到處使用的條形碼就是這種推理的結果。在條形碼中，特定寬度的線條代表了特定的字母或者數字。條形碼有不同的類型，每一種都有其特定的規則來描述其如何形成一個特定類型的身份。決定我們如何將數字和字母轉換成特定的線條，以及我們可以添加什么特定的數字和字母來構成有效的標簽的規則稱為是標簽編碼規則，或者簡稱編碼。因此，條形碼可能會包含物品的身份，即一個指示所用的是何種條形碼的編號，以及在許多情況下的一個標識分配該身份的組織的編號。下圖是一個ISBM的條形碼編號。
在上圖中，標注A, B, 和 C 分別指示了條形碼的不同部分。A部分包含數字636，即一個指示圖書行業的編碼。B 部分指示ISBN 編號本身。C部分是一個校驗碼，用于閱讀器驗證是否誤讀了該編碼。中間的ISBM編碼部分是根據ISBM規則的身份，而A和C則是根據條形碼的要求所加。
為了選擇適當的編碼將身份寫入到RFID標簽中，你必須知道你將要寫入的身份的類型和所用的標簽的類型和存儲容量。在EPC規范中，GID是一個純粹身份（pure identity），它不能在沒有通過某種形式的編碼的情況下寫入到任何類型的標簽中。例如，假入我們想要將其寫入到一個96-bit Class I EPC標簽中，即一個可以保存96bit的ID，并且符合EPC標準的可寫入標簽。首先，我們需要將GID的各部分按照標簽的要求正確排序，留下那些不是標簽編碼的部分。幸運的是，僅包含相關字段的GID對EPC來說已經是正確的順序了。接下來可以添加必要的附加信息已產生一個閱讀器和事件器都能夠理解的URN 表示。對于一個GID在9bit標簽中的URN表示是：
urn:epc:tag:gid-96:FilterValue.GeneralManagerNumber.ObjectClass.SerialNumber
那么一個具體的例子可能是：
urn:epc:tag:gid-96:0.00012345.054322.4208
如果應用直接和閱讀器通信，你可能需要產生這些標簽特定的URN。如果你的應用是通過某種形式的RFID中間件通信，或者某種具有數據管理能力的智能閱讀器通信，你便可以使用某種純粹的URN 身份表示。反之亦然：閱讀器可以給你一個標簽特定的URN，而中間件則可以給你一個獨立于標簽的純粹身份。
由于試圖快速進入成長中的 ESB 范疇的廠商的慌亂，以及大量行業分析師和記者在分析報告中分別展示他們各自的觀點，可以理解，這其中對于ESB 到底是什么還具有很多混淆。這一節將概略說明 ESB 的主要特性。
如第 1 章所示， ESB 能形成普遍的網格的核心。它能夠跨越和超過擴展企業，并且橫跨部門組織、業務單位和貿易伙伴形成全局的范圍。ESB 也能很好地適合于局部的集成項目，并且對促進它們采用任何類型的集成環境提供柔性的支撐。
圖表 1?2 ESB 形成一個能跨越了一個全球企業網絡的普遍網格
應用可以按需插入總線，并且具有可視性，以及能夠與其它已經插入到總線中的任何其他應用和服務共享數據。雖然Web Services是 ESB 架構的一個有機組成部份，但是所有的應用并不是一定要被修改成為真正的Web Services才能參與到 ESB。連接性是通過多種協議、客戶端API 技術、遺留消息環境、以及第三方應用適配器來達到的。
基于標準的集成是 ESB 的基本概念。對于連接性，ESB 可以使用J2EE組件，比如使用Java Message Service (JMS)來進行MOM連接，使用J2EE 連接器結構 (JCA 或 J2CA) 來連接應用適配器。ESB 也能夠非常漂亮地與使用.Net、COM、C#、C/C++構建的應用進行集成。除此之外，ESB 也能集成支持SOAP和Web Services API的任何組件，這其中包括事實上的標準Web Services工具箱的實現，比如Apache Axis。為了處理數據操縱， ESB 可以使用XML標準，比如XSLT、XPath 和 XQuery 來提供數據變換、智能路由、以及在數據流過總線的時候提供“空中”查詢。為了處理 SOA 和業務流程路由， ESB 可以使用 Web Services描述語言 (WSDL) 來描述抽象的服務接口，使用針對Web Services的業務流程運行語言(BPEL4WS)、WS- Choreography或者一些其他基于XML的詞匯表，如 ebXML BPSS，來描述抽象的業務流程。
如果你還不懂這些深奧的詞匯的含義，也不要擔心。雖然本書并不想作為是這些各個技術的詳細參考或個別指導，我們也會在他們如何與 ESB 有關的語境中足夠詳細地解釋它們。
這些基于標準的接口和組件被整合到一個意義非凡的包含開放端點的可插入架構之中。ESB提供了一種基礎設置來同時支持基于工業標準接口集成組件和使用標準化接口來實現的專有元素。下圖展示了一個使用JMS和JCA集成一個 J2EE 應用、使用JCA應用適配器集成第三方打包軟件、使用C#客戶端程序集成一個.NET應用、使用Web Services集成兩個外部應用的案例的高階視圖。
圖表 1?3 ESB 整合多種不同的技術
ESB 在其中借鑒了傳統EAI Broker的許多功能，比如從它提供集成服務 , 像是業務流程編排、數據路由、數據變換、以及應用適配器。然而，集成中介者通常是高度集中和單一的形態。ESB 將這些集成能力提供為獨立的服務，能夠以一種高度分布的形態一起工作，并且能夠彼此間獨立伸縮。在第 6 章中，你將會學習更多有關 ESB“服務容器”，ESB 的一項核心概念的內容，它允許對集成服務進行選擇部署。
任何集成策略的一個關鍵部分就是能夠輕易地在應用之間轉換數據格式的能力。許多應用對描述相似的數據并不共享相同的數據格式。
數據變換是一個 ESB部署的一個固有部份。變換服務特別針對那些被插入總線的個別應用能夠在總線的任何地方被定位和訪問的需要。因為數據變換是ESB 本身的一個有機組成部份，解決應用之間的阻抗失配問題便可以想到ESB。
ESB 能夠為你提供本質上針對任何集成項目所必需的核心能力，并且可以通過使用分層的服務來處理特定的用途來增加。例如，特殊的能力，比如業務流程管理 (BPM) 軟件能處理工作流相關的業務流程，而協作服務器能夠提供對伙伴業務流程管理的特殊服務。專門的第三方翻譯器能夠將外部數據，比如EDI，轉換到能進入目標企業資源規劃 (ERP) 系統之內的格式，或者在通用總線之上的規范XML表現。
在 ESB驅動的、事件驅動的 SOA中，應用和服務被當做抽象服務端點，能夠輕易地對異步事件做出響應。SOA 對其底層的連接性和管線細節提供了一個抽象的方式。服務的實現不需要理解協議。服務也不需要了解消息是如何路由到其它服務的。他們只是簡單地將接收自 ESB 的一個消息作為一個事件，然后處理該消息。ESB 可以把消息發送到它想要去的其他任何地方。
在 ESB SOA 中，用戶定制服務可以被創建、擴展，并且被重用為ESB 功能。被暴露為服務的應用端點，可以同特殊的集成功能一起構造成復合業務服務和業務流程，并且它們可以根據不同目的重新組合，其目標是在一個即時企業中提供自動化的業務功能。
第 7 章將會更詳細地討論 ESB 中的 SOA 。
ESB的處理流從簡單的優先步驟序列到使用條件分支和聯合來并行執行的綜合業務流程編排。這些特征可以使用簡單的消息元數據或者通過使用諸如BPEL4WS 之類的業務編排語言來控制。
ESB 的處理流能力使得定義屬于某個部門或者業務單位局部的，或者共存于一個較大的集成網絡中的業務流程成為可能。這點卻是一個集線器-插頭中介者或一個 BPM 工具自己所不能很好地自己解決的問題。第 7 章將會詳細討論分布式的流程能力，它能提供高度分布的流程編排能力而不需要中心化的流程和規則引擎。
ESB的業務流能力也涉及到基于內容的消息的智能路由的特殊集成服務。
因為ESB 的業務流能力構建于分布式的SOA之上，它也能夠跨越高度分布的物理部署拓撲（甚至擴越大洋）而不用痛苦地忍受總線上各種應用和服務之間的物理邊界和多協議的鴻溝。
圖表 1?4 跨越物理和邏輯邊界之上的部署拓撲的編排和業務流
在 ESB 上的節點之間的連結是具有防火墻能力的。應用和 ESB之間的安全性，甚至在 ESB 節點自身之間的安全性，能夠建立和維護最高強度的認證、憑證管理、和訪問控制。
可靠性是通過處于ESB核心的企業級MOM來達到的。MOM核心提供異步通信能力、業務數據的可靠傳輸、以及事務的完整性。你們將在第 5 章中學到，這已經不是十年以前的傳統MOM技術了。需求從那時以后開始進展，并且已經成熟，而 作為ESB 的核心的MOM必須符合今天的需求。
傳統的集線器-插頭中介者方式往往具有組織性的邊界問題，這主要是因為EAI Broker對跨越防火墻和網絡域的無能的實際限制所引起。更重要的是，即使一個集線器-插頭架構能夠被伸展而跨過組織的交界，它仍然不允許各個業務單位彼此半獨立地運行所需要的局部自治。與不斷擴展的集成范圍延伸超過部門層次所相關的最大問題之一是自治和集中控制之間的問題。
作為大多數大型公司環境的業務文化的一部分，每個部門或業務單位需要彼此獨立地運作。 然而，他們仍然依賴于共享資源，以及輸入到通用業務功能之中的報告和帳戶信息。
在這樣一個環境中，需要所有的消息流量都流過位于總部的一個集中的消息Broker的集成策略是不合理的。 這不只是一個技術上的障礙；它也是公司文化的問題。在一個松散耦合的業務單元環境中，諸如本地應用之間的業務流程，或者安全域，被一個集中化的公司IT功能管理簡直沒有一點道理。組織中的松散耦合業務單元需要彼此獨立地運作。他們每一個都應該有其自己的IT功能，而不必須路由所有的消息流量，或代表它的業務規則和安全域的控制, 經過一個集中的集成經紀人在一個位置或另一個(第 1 章)。
圖表 1?5 如果使用一個集中的集線器，分開業務單位缺乏必需的自治-和-了集成經紀人
本地業務單位和部門需要有對他們自己的局部IT資源的控制，比如在其站點運行的應用。集成基礎設施應該支持部署拓撲來支持具有實用性的業務模型。ESB 也提供這種部署模型， 允許本地流量、集成組件以及適配器能夠被本地安裝、配置、加固和管理，并且仍然能夠以一種集成的安全模型一起將本地集成域插入到一個更大的聯邦集成網絡之中。
圖表 1?6 自治的而且公布聯邦制,ESB 允許橫過組織的交界對合作地同盟的運算組織
ESB 的分布式特征是通過從實際的部署細節和底層的連接協議中抽象出來的將端點定義，以及在那些端點之間的數據的編排和路由來達到的。聯邦特征則是通過 ESB 能夠隔離和選擇地橫過應用域和安全邊界的能力來達到的。
在一些業務模型中，在每一個遠程地點都安排有本地的IT職員是不大可能的，雖然仍然需要松散耦合的、自治的聯邦的集成網絡。舉例來說明這一個點，我們來想象一下部署在零售行業中的ESB 的案例。一個視頻租借鏈可能有數百或數千個包含相同應用的地點，所有以相同的形態運行的操作涉及到目錄管理、會計和報表等。
圖表 1?7 和數以千計遙遠的儲存一個視像零售鏈,所有的包含應用程序的相同組
使用 ESB，可以建立一個集成藍圖來處理遠程店鋪中的局部應用之間的通信。這包括店內應用的接口定義、消息流量的路由、消息通道的管理、以及安全許可。它還可能包括集成組件，比如應用適配器、協議適配器或者數據變換器。這個集成藍圖，或稱模板，可以在所有地點進行部署和定制，并且獨立地扮演所有其他店鋪。
圖表 1?8 ESB 配置藍圖在每個遙遠的位置和很遠地展開配置而且處理
這個遠程部署藍圖的能力并不單針對零售行業，它也可以擴展到所有其他行業的應用。聯邦的集成域的遠程管理對于在一個高度分布的環境中的任何ESB的成功部署都是非常關鍵的。
安全、可靠的消息聯結
除了在每個店鋪的本地應用之間共享數據之外，這些遠程店鋪還需要同總部共享信息以便進行帳務處理和報表、信用管理以及職員數據的追蹤。遠程店鋪還需要彼此之間共享信息。舉例來說，一個大型的音像連鎖店可能會提供這樣的服務，顧客可以選擇從離家近的店租賃影碟，然后在離辦公室近的另一個店歸還。因此，在同一個地理區域內的店鋪之間可能會需要以近乎實時的狀態共享有關租賃的數據。因為在遠程店鋪和總部之間的衛星網絡通信連接存在較大的反應期和彈性，要在總部維護一個有關所有租賃信息的實時集中訪問點是不現實的。那些有關你只是在兩個小時之租借的數據需要共享，或者通過遠程店鋪之間的一個集成的數據共享連接來進行訪問。
因為總部和遠程店鋪之間的連接是通過可靠的消息來達到的，因此由于不可靠的衛星電路所造成的網絡服務終端可以從消息層得到補償。也應該注意到，對于遠程店鋪之間來說，通過Internet來建立一個安全和可靠的消息通道也是可以的。
當數據通過ESB 在應用之間流動的時候，XML是一個表現它們的理想基礎。被應用程序的一個巨大的行列生產而且耗盡的數據能以多種的格式存在和包裝方案。有大量的應用產生和消費的數據，可以以各種格式或者打包的Schema存在。對ESB來說雖然的確可以依你喜歡的打包形式或者封裝方案來承載數據，但將途中數據表現為XML具有莫大的好處，包括使用能夠結合來自于不同的源數據以創建一個新的數據視圖的產生數據的特殊 ESB 服務， 以及針對應用間高級數據共享的濃縮和重定目標。第 4 章將會探究使用XML功能本好處—將避免一個組織的應用間同步升級的需要—并且更詳細地討論分布式XML變換之后的基本原理。
ESB通過為途中數據在總線之上的應用間傳輸的時候提供實時吞吐消除了潛伏反應問題。目前，最流行的集成方法之一是每夜進行批處理。 然而，打包的成批處理集成策略，不管是每夜還是其它，都具有較高的邊際錯誤率，并且造成信息獲取的延遲。其結果是高反應期產生獲取了過時數據將使代價高昂的。第 9 章將詳細討論這個問題，并且研究 ESB 可以如何用來將你的業務數據從每夜批處理模式重構為實時吞吐模式。
運行感知意思是業務分析師能夠獲得對業務運行的狀態和健康情況的洞察能力。 一個允許對數據在其以某個業務流程中的某個消息形式在組織中流動時進行實時跟蹤和報告的基礎設施，對于幫助建立運行感知是一個無價的工具。一個稱為是業務活動監控 (BAM)的產品門類已經出現來解決運行感知的這些問題。
使用XML作為ESB的原生數據格式的好處之一就是消息沒有被處理為不透明的數據塊。如果應用和服務之間的所有數據都被格式化為XML文檔，ESB提供的基礎支撐便允許你在ESB之上再構建一層高級能力，以獲得對流過你的企業的業務數據的實時洞察能力。這些能力，不管是否是ESB的固有組成部分，還是有一個擴展來驅動，都表現為包括了路由、處理流、以及下層的管線，并且不需要再在其上鎖定一個第三方的BAM產品的一個通用基礎設施的一個有機組成部分。
作為ESB的一個基礎部分的審計和跟蹤能力允許對在SOA中的所有流動的業務流程和消息流的健康狀況進行監控和跟蹤。諸如數據緩存、數據收集和聚集、以及XML數據的可視化表現之類的增值服務，可以用來創建一個基礎服務，該基礎服務可以在數據在企業中流動時，產生對業務流程的狀況洞察的警告、提醒和報表能力。
圖表 1?9 增值型服務促成操作的覺察提供對活的業務數據的即時洞察
對ESB中的數據的根蹤和報表是通過在業務流中定義審計點來達到的，然后再對從業務消息中收集的重要內容在ESB中流動時提供插入點。可追蹤數據例子是業務消息自身，以及指示某業務消息是否通過了某個特定的業務處理步驟的業務事件。
高級的增值服務可以提供數據收集服務、查詢機制以及報表能力，它們能夠講所有數據進行收集、進而表現為各種具有意義的形式。XML持久性服務可以提供緩存和聚集點，這樣可以收集將要轉換的數據從而向其他應用提供數據輸入，或進入到可以被業務分析師使用的人可讀的報表機制之內。這意味著流經ESB的數據可以進行實時分析，以提供有關你的業務狀態的實時信息—比如，可以隨時提供有關你的供應鏈中的存貨的狀態快照。
區別是否真正是 ESB 的一個主要方面是看其是否具有逐漸采用的能力，相對于另一個“全有-或-全無”的論斷。在 Y2K 之后的開支削減中，數百萬美元預算的項目數目已經今非昔比。有一些跡象表明，預算資金籌備正在開始釋放以解決短期的戰術性集成需要，但是預算仍然謹慎地處于一個執行層面。，然而，同時仍然有一些期望實現較大的公司范圍集成策略計劃—這些計劃嚴重依賴于集成和現有IT資產的重用。
圖1-10說明了 ESB 可以如何用于小項目中，然后它們都可以進入到一個更大的集成網絡之內。 當我們深入閱讀本書的時候，我們會詳細研究這是如何實現的。
圖表 1?10 ESB 支持逐漸采用的集成，同時向著一個策略目標工作
ESB 的聯邦/自治能力也對一次一個項目采用 ESB的能力有助益。ESB 集成項目漸進式的分布部署能夠在朝著一個更廣的企業層面的計劃目標的前提下得到立即價值。
逐漸采用的觀念將進一步通過橋接到一個已有的集成Broker集線機器和遺留系統Broker來得到進一步支持。集成Broker集線器和他們的特點將在第 2 章中詳細研究。
一版來說，架構是指將系統分解為各個單獨的組件，以表示它們之間如何一起協同工作來滿足整個系統的需求和目的。隨著技術的融合，RFID系統提供的一些主要功能已經對使用它的系統架構帶來明顯的影響。我們本部分將研究RFID加入到系統架構中的組件，以及這些組件如何影響系統的相關特性，比如：系統的非功能性需求，如性能、安全、可伸縮性、可管理性等等。并且對使用RFID的系統提出架構指南。.
RFID 可能在跟蹤技術和傳感器網絡技術方面具有很強的相關性和可融和性，在很多領域的技術發展和進步也體現了這一征兆。
根據摩爾定律，RFID 會越來越便宜，并且可能會集成更高的存儲和處理能力，并且在市場可以接受大規模使用的場景。
半導體技術的進步并不僅僅是使得RFID的成本變得越來越便宜，而且也隨著網絡和痛惜年技術的發展出現了許多智能設備，比如移動電話、PDA、數字媒體設備等，也包括RFID閱讀器的傳感器。智能設備和無處不在的網絡連接和帶寬會導致許多基于移動和邊緣的應用。RFID 就是物聯網（Network of Things）之隨處連接以提供超出企業和組織數據中心和內部網絡邊界的自動化的理念的一種實現。智能家居、智能汽車、甚至智能衣服和消費品都是需要這些邊緣處理能力的應用。比如當前的智能家居概念和實現就利用了大量各種具有IP能力的家用設備連接到住宅網關，然后由它在連接到互聯網絡。下圖就描述了一個連接到Internet的智能設備的概念示意圖，可稱為網絡化生活：
圖表 3?1 網絡化智能生活
越來越普遍的寬帶數據網絡和超越連線和物理限制的無線通信，以及更加能夠接受的強大的服務器，使得應用的架構越來越偏向于分布，即將業務的處理移到業務發生的地方，凡是保證中心的管理和統一的安全。這意味著在一個整體框架之下，可以部屬各種企業應用組件到邊緣位置，比如倉庫和店面。
所謂邊緣處理能力就是企業系統中由于強大但低廉的個人計算機、以及企業部屬在邊緣的服務器、以及到企業數據中心安全和可靠的寬帶連接給企業帶來的在邊緣處理業務的計算能力。RFID 系統就將大量的計算、數據管理和帶寬需求放到這些邊緣。這并不是偶然的單獨現象而是一個總體趨勢。所謂邊緣，就是分布于企業數據中心或者總部之外的地點，而大都是實際業務發生的所在地，比如倉庫、店面、生產線甚至物流運輸途中。
企業中成功采用RFID技術的關鍵在于如何將RFID數據集成到企業業務應用骨干中。RFID閱讀器會產生大量的數據。如果它們不加過濾地傳遞到下游應用，可能會使其崩潰。為了避免后端關鍵業務應用遭受數據洪水，以及將重復、無效或者無用的數據隔離在物理設備，如閱讀器和天線之外，可以使用專門的RFID中間件，比如事件管理器。SOA允許我們開發和部署松散耦合的應用組件，這些組件件使用簡單但強大的服務接口來進行通信。目前許多RFID 中間件都基于Web Services標準，RFID中間件的總體架構也符合在企業業務系統中日益被接受和采用的SOA架構。
圖表 3?2 企業邊緣
RFID系統具有多重可能的不同用法，這自然會影響到其架構的差別。例如，通常由制造商實現的用于標簽和物流跟蹤的應用的實現通常關注于產品的自動化標簽以及在物流過程中的特定的閱讀器能夠以一種高于最小可接受準確率來讀取。總而言之，這些系統都主要集中于實現的物理方面，而不是產生諸如提前裝船通知之類的簡單報表。這樣的話，它們趨向于具有最小的數據管理和交換要求。但另一方面，一家藥品公司可能會想要根據其藥品從工廠到分銷商再到零售藥店，這就需要具有實時的信息，包括某件在流程的某個點上某件商品位于何處之類的詳細信息，以及它們是被如何以及在何處生產的，以及到過什么地方。很多可能，零售商和制造商都需要這些跟蹤信息的某些部分。因此，這種系統將要求不但具有單個物品級的跟蹤能力，還需要具有某種程度的B2B信息交換能力。
下圖所示是RFID的5種基本能力和相關不同應用對這些能力的需求映射。
可以想見， RFID 系統將不斷演進以滿足更廣的應用需要，因此也要求不同的架構方式。但是我們可以定義通用的，失和于所有RFID用法的RFID 系統架構或者實現。但是，幾乎對每個RFID系統來說可能都需要某些特定的能力。
圖表 3?3 不同的RFID應用系統需要的能力
總的來說，一個RFID 系統必須能夠提供下述特征或者能力中的全部或者部分：:
- 編碼RFID標簽的能力
- 附加經過編碼的RFID標簽到被標識物品上的能力
- 跟蹤被標簽的物品的移動的能力
- 將RFID信息集成到業務應用的能力
- 產生能夠在業務之間共享的信息的能力
- 開發自組織智能設備的能力