尽管引用了1996年Spike Lee的电影，这个栏目中的bus不是那种带轮子的巴士；它是一种通常称为企业服务总线（ESB）的中间件。在过去的两年中，我从一个ESB怀疑论者转变成一个ESB迷。

　　我将向您展示我的转变，并且提供关于什么是ESB的见解，以及如何使它适应企业的应用程序基础设施。

　　什么是企业服务总线？

　　从本质上讲，ESB是一个简化应用程序间通信的软件。它还能够简化企业在多个应用系统之间共享数据和功能，支持复杂的处理需求。ESB 还可以在不同应用程序之上提供一个一致层（逻辑上来讲），显著地减少编写访问这些不同系统的开发人员的工作量。通过这些应用链接和后端抽象功能，ESB 可以帮助企业实现面向服务架构（SOA）。了解ESB的一些事项：

　　ESB的“骨干”通常是一个消息队列和发送机制，例如IBM的WebSphere MQ（以前称为MQSeries，我称之为MQ）。

　　ESB可以提供基于内容的消息路由（正确路由基于消息内容的消息的能力，相对于基于消息标题信息）。

　　ESB可能有针对不同打包应用程序（例如SAP和其它供应商出售的应用程序）的 “适配器”。

　　应用程序通常可以通过 “正常” 的接口与ESB“对话”。这种接口包括Java消息服务（Java Message Service，JMS）、简单对象访问协议（SOAP）和HTTP等。

　　ESB可以访问公开为Web服务的应用程序的函数（虽然这通常被认为是ESB最佳实践，但是ESB并不限于使用Web服务作为调用手段）。

　　ESB可以提供数据转换服务，例如将XML标签数据转换成在CICS COMMAREA中被替换的输入字符串（反之亦然）。

　　ESB可以包含可用来定义工作流的 “规则引擎”。

　　ESB可以包含一个“流程引擎”，它能根据通过规则引擎指定的规则来执工作流（以后有关于此的更多内容）。

　　ESB：寻找问题的解决方案？

　　当我第一次听说ESB软件时，我的企业正在使用DB2。一些公司在尝试向我们销售ESB产品，并且我的企业有几个人支持这些技术。我很长时间内看不到ESB的实际用途。我知道ESB与消息处理有关，但是我们已经有一个成品MQ。ESB能做哪些MQ不能做的工作呢？

　　当有人建议（再次说明，是公司里面的支持者）后端应用程序服务的所有请求（包括通过DB2访问程序提供的数据请求）都应该通过 ESB 时，我的怀疑开始发生动摇。我再次思考：“所有请求？即使是我们的最高量同步 [从用户角度而言] 事务也包含？”。那对我没有意义。它意味着添加一层软件（或插入一个额外的软件）来处理需要快速响应时间的流程。这不会奏效。

　　随着我学习关于ESB技术的更多知识（通过接触其雇主已经部署 ESB 解决方案的人员），我改变了想法。我现在发现，对于某些类型的事务，使用ESB可以产生显著的优势，并且通过 ESB 运行所有请求是一些企业的最佳选择。

　　ESB应用：ACL事务

　　我相信，ESB用于ACL事务（即异步、长期运行和复杂的事务）时能获得最大的优势。

　　对于异步，从发起用户的角度来看，处理过程的完成事务是一个异步事件。

　　考虑一个简单的订单输入流程。消费者想要在线购买一件特定的衬衫。当用户输入的信息更新了后端订购管理系统数据库时，服装厂商认为事务完成。如果后端处理可以足够快地完成，那么让用户等待工作完成没有问题。用户在他的屏幕上看到一个沙漏标，当事务完成消息被发送到服装厂商时沙漏标消失，这在后端数据库更新发生之后发生。如果响应快速，那么每个人都很高兴。

　　如果事务量达到很高的级别（每秒几千次）或者关联的后端处理变得非常复杂（因此很耗时间），那么处理模型就会崩溃。对于这种情况，使用发起用户异步的方式进行尽可能多的处理就会很有意义。

　　考虑经纪公司部署的股票购买程序。它的量非常大，并且处理的完成取决于不受经纪公司控制的系统（它们由证券交易所运行）。这些情况中，明智的方法是尽可能将购买/销售事务处理的同步部分压缩成基本的 “我们已经收到您的订单” 消息，表明已经在强大而可恢复的数据仓库中捕获到用户交易指令。

　　收到 “订单已收到” 消息后，用户可以单击 “查看订单状态” 按钮。通常，在单击 “查看订单状态” 几秒钟后，用户将看到订单已经按计划执行，以每股 z 美元（或欧元、或日元等）购买（出售）了Y公司的x股股票。

　　如果交易订单比通常完成的时间长一点，那么用户会在单击 “查看订单状态” 按钮后看到一些形式的 “执行挂起” 消息；这条消息可能伴有 “刷新订单状态” 链接。单击该链接很有可能使用户收到 “订单执行完成” 信息。

　　同样，这样每个人都很高兴。用户很快收到 “订单已收到” 确认（并且可能在可接受的时间内看到 “订单执行完成” 信息），并且经纪公司能够有效地管理从订单捕获的那部分处理流程。

　　将ESB放入工作流中确实给应用程序增加了一层代码，这可能会影响响应时间（后面您将看到，可以减轻这种影响）。但是，给事务处理的异步部分增加一点响应时间通常不是什么大问题，这是我喜欢为异步工作流使用 ESB 的原因。

　　“但是，等一下”，您可能会说：“难道不能使用MQ和用于消息存取的代码来处理异步工作流吗？为什么要购买ESB呢？”

　　好问题。答案是我的ACL异步有许多复杂和长期运行的部分。

　　以天为单位度量响应时间

　　不相信我吗？您不认为在现实中存在一些事务，并且日历能够提供合适的响应时间度量的吗？请再次思考。

　　假设公司ABC允许客户在线订购其产品。公司QRS的员工（公司 ABC 的客户之一）为产品XYZ输入一个订单。下面是接下来发生的情况：

　　订单信息被公司ABC捕获，订单输入人员收到 “订单已收到” 消息。

　　产品XYZ的订单出现在公司ABC的一个员工的工作队列中，他负责与订单管理应用程序交互。

　　与订单有关的信息到达使用应用程序生成构建请求的另一个员工那里（可以用各种方式配置产品XYZ）。

　　出货部门的人员在应用程序中输入确定所订购产品出货日期和运输方式（常规的水陆运输、空运等）的信息。

　　一些员工在生成发票的帐单应用程序中输入信息。

　　一个客服人员在生成电子邮件的应用程序中输入信息，为输入订单的个人发送邮件（“谢谢您订购XYZ。如果您在接下来的 30 天内订购 XYZ 增强的 JKL 产品，我们将给予您 10% 的折扣”）。

　　朋友们，这个事务（唯一的同步部分是 “订单已收到”）不仅是异步的，并且是复杂的（涉及多个完全不同的应用系统）和长期运行的（“订单已收到” 和 “产品已发出” 的时间可以是几天）。

　　在这里，ESB可以产生可观投资回报。对于新手，ESB可以减小（有时极大地减小）ACL 事务的周期时间。如何减小？通过ESB规则和流程引擎提供的工作流控制。

　　通过规则引擎定义了复杂的产品订单等流程之后，流程引擎将确保每个关联的子流程（订单管理、构建请求、记帐、出货、客服等）以正确的顺序执行直至成功完成（否则，会产生一个警告并发送到相应的组等待解决）。这种协作可以手动完成，但是ESB始终在工作，缩短周期时间。各个子流程与不同应用系统交互不会产生问题；ESB设计用于大多数应用平台。ESB会在复杂的流程中丢失数据吗？不会，ESB的基础是一个强壮并可恢复的消息队列和传输机制（在IBM的WebSphere Enterprise Service Bus中是MQ）。

　　这里速度是最大的优势，它提高了服务质量。ESB始终遵循规则。如果正确指定了规则，决不会发生因为以错误顺序执行子流程而导致遗漏步骤和挂起。

　　真的不错，不是吗？许多企业已经通过ESB将工作流编排变成工作的初始活动，从而实现SOA。

　　ACL是ESB的全部功能吗？

　　在实际场景中，已经成功通过企业的ESB处理后端应用服务的所有请求。这样做的好处是：调用应用服务的一致接口。

　　这不能使用不需要ESB的Web services来实现吗？可以，但要请记住ESB的规则引擎。我知道有一家公司由于一系列的收购活动而拥有几个企业资源计划（ERP）系统。ESB为访问不同系统提供一致的方法；ERP服务消费程序的开发人员根据ESB进行编码（基于内容路由消息将请求传递给正确的后端系统）。后来，当公司准备撤销一个ERP系统（其数据已经被迁移到另一个系统）时，它只需通过ESB的规则引擎进行更改；将流向ERP系统A的请求引向ERP系统B。

　　另一个例子：一家实现SOA的公司使用ESB来避免程序员从头编写应用服务（服务重用是SOA的关键原则）。所有应用服务请求都需要经过 ESB，任何应用服务都必须注册到 ESB，以便其可用于服务消费程序。这种严格的方法提供 “门槛”，允许检测服务重复。允许服务请求绕过 ESB 将提供一个终止运行，它会导致丢失开发流程规则，这又会导致重复的服务开发和SOA无法提高程序员的生产率。

　　但是，如果在服务请求和服务提供程序之间放置额外的代码层（ESB），情况会怎样呢？是的，额外的路径长度的确存在。但是ESB产品通常提供一些功能（比如数据缓存），这能够减轻ESB对事务吞吐量和响应时间的影响。关于数据缓存的更多信息，请参阅参考资料中的专栏 “Can SOA Perform?” 。

　　ESB：好得难以置信？

　　我的目的并不是展示ESB产品能为所有应用集成和SOA需求提供解决方案。它不是魔法棒，但这门技术确实为多个行业的许多企业带来了利益。您可以帮助公司检验一些ESB产品。以怀疑的态度接近这些产品。我就是这样做的，并且最终发现了隐藏在表面现象背后的价值。