许多新生技术都经受过试图找到问题来解决以获得采用的痛苦经历。另一方面，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信息集成到业务应用的能力
- 产生能够在业务之间共享的信息的能力
- 开发自组织智能设备的能力