《Open Source ESB in Action》作者谈开源 ESB

InfoQ 已发布了 Tijs Rademakers 和 Jos Dirksen 所著新书《Open Source ESBs In Action》的样章，借此机会，我们对作者在现实项目中使用开源ESB 的经验进行了采访。

InfoQ：鉴于开源 ESB 目前的状态，您认为能够把它们看作是商业产品相当的替代品么？

Tijs Rademakers (TJ)：我曾经有幸使用过商业产品（非开源）和开源 ESB。在使用 Mule ESB 时我有一个惊人发现，即它让企业集成和面向服务这些个复杂工作变得容易。使用商业 ESB 就意味着，前期巨额的许可费用，繁重的安装过程，不得不学习新的 IDE，必须从可用文档和售后咨询那里学习。在你处理完这些前期成本后，著名的非开源 ESB 产品，诸如 WebSphere，Tibco，Sonic 等，才能尽其所能。至于开源 ESB，你一开始得把它先下载下来，10 分钟后，你就拥有了一个携带可用范例的 ESB 环境。接着，看一看范例的配置文件，你就能相当容易地实现你自己的集成解决方案。实现一项定制功能意味着：写一个 Java 类和使用 Mule ESB Java API。这对于 Java 开发人员是很容易理解的。而且要是你有什么不知道的，还有活跃的大型社区可以让你在邮件列表中进行提问。

Jos Dirksen (JD)：我认为，从核心的 ESB 功能看，目前开源社区中的领先者当然能够看作是商业产品相当的替代者。例如路由，转换和连通性是开源 ESB 能够替代或者比许多商业产品表现更好的方面。同时，在易用性方面，我认为，开源 ESB 比许多商业产品表现的更好。

TJ: 有一点可能会令人惊讶，开源 ESB 的功能跟它的商业替代品非常类似。同时更惊人的是，由于简单的配置机制和干净的 API，集成解决方案的配置和开发显得更加友好。商业产品通常会提供一个 IDE，在其中你可以进行拖拽和单击你的集成解决方案，顺便说一句，这样做很好，但是要实现那些不支持拖拽的功能可就要痛苦的多。所以，简而言之，为你的组织选择 ESB 时，你真的应该考虑开源 ESB。

InfoQ：您认为 ESB 在 SOA 中充当了什么样的角色？它应该是中心，联络点或者活跃在边缘地带？

JD：视情况而定。通常，你会听到每个 SOA 架构都应该在其核心有一个 ESB，但是我其实认为这不是必须的。如果你已经有一个现代化的（比如面向 Web 服务）架构，你就不需要引入 ESB。在这样的场景下，如果你引入一个注册库，就能创建一个非常好的、优雅的面向服务架构。要是你身处一个相当复杂的环境（比如，很多的遗留系统，.net 和 Java 结合，大型主机），你可能就需要一个更加‘智能’的集成层，以面向服务的方式暴露这些应用。在这样的场景下，我想，ESB 就应该是 SOA 的中心点了。

TJ：有些人宣称 SOA 已死，所以我当然不愿意把 ESB 放在这个列表中。:-) 在我看来，SOA 跟仅仅用 ESB 集成遗留系统和提供服务相比是一个相当大的课题。SOA 拥有业务视角和技术视角，而 ESB 主要还是技术相关的。因此，ESB 是用来实现 SOA 的一个小的但很重要的部分。ESB 是提供诸如路由，转换，安全和协议转换这些功能的重要组成部分，这些功能有助于服务彼此之间的通信，并实现（BPEL）流程跟服务的通信。

InfoQ：您认为开源 SOA 解决方案最需要改进的地方是什么，您遗漏了什么重点吗？

JD：我遗漏了什么……有趣的问题。我个人认为最大的遗漏就是一个真正好的集成解决方案。当我们用开源工具进行 SOA 项目时，我们通常不仅仅使用 ESB，比如我们还需要一个 BPM 引擎。当前，尽管有所提升，但是 BPM 引擎，规则引擎和 ESB 之间的集成还不是很完美。因此，我们通常需要自己写这些组件间的集成代码。我认为，这一点是需要极大提升的地方。

TJ：实际上，在开源 SOA 项目领域有很多活动。他们是 ESB 项目（Mule，ServiceMix，Synapse，Open ESB 等），BPM 项目（JBoss jBPM，Apache ODE，Open ESB BPEL 组件等），服务注册（Mule Galaxy，WSO2 注册等），业务规则引擎（Drools/JBoss Rules）。因此有很多好的现成 SOA 项目。但是，在我看来在这些组件的集成方面还有很大的提升空间。商业或者非开源 SOA 产品在这一点走在了前面，因为他们提供了一套完整的 SOA 工具。但是缺点当然就是厂商锁定喽。

JD：在我看来，开源 ESB 需要提升的地方在于管理和图形化的支持。当你看到商业的 ESB 时，它们的管理支持做得比较好，同时在支持工具领域也是如此，对于开发工具，开源 ESB 有很多地方需要改进。但是，我认为后者对于高水平使用者不太重要，因为他们对 ESB 的深入了解，使其不受限于那些图形化工具。对于我个人，我希望看到一个好的集成解决方案，提供 BPM，业务规则和好的服务存储库。

InfoQ：您能分享一些来自案例的非功能的统计数据么？

TJ：好尖锐问题！非功能性统计数据通常很难界定，在 ESB 环境下，当然也差不多。 但是我们完成了一个工程，在 Mule ESB 上用 JORM 作为消息引擎每秒处理多条消息。

JD：目前，我正在从事的项目是处理城市住户和地方当局之间的互动。这是一个基于 Mule 的系统，其中有 800,000 名市民籍由一个.net 前台跟一系列后台服务打交道。服务间的交互是基于 Mule 的。Mule 也把一系列旧的后台应用暴露成 Web 服务。

InfoQ：您认为，对于 MuleESB 和 ServiceMix，它们各自的优缺点是什么？在使用时有何建议？

JD：二者都有优缺点。我喜欢 ServiceMix 的模型，它让热部署新的集成流程变得容易，并且事实上它是基于标准的。尽管 JBI 标准没有获得太多的青睐，但它是一个相当不错的规范，当你理解 JBI 时，它会让你对 ServiceMix 很容易上手。我很喜欢有可热插拔的集成组件，特别是它们是可以热部署的。包含 Camel 也是 ServiceMix 的一个亮点。我真的喜欢可以用 DSL 去开发集成流程。ServiceMix 的不足之处跟它的优点是有关联的。JBI 规范确实引入了另一个困难级别，对 XML 的关注并不见得总是适合你在集成领域中遇到的需求。另一方面，Mule 让集成流程的创建变得容易和简单。它有非常广泛的路由器，易于扩展，并有很多可选的开箱即用的连通性、路由和转换。使用 Mule，使你能够在数分钟内让相当复杂的集成流程启动并运转起来。然而，Mule 也有缺点。尽管不是很大，但是对我个人而言，它的一个最大的缺点就是没法热部署新的集成流程。如果 Mule 集成 OSGi 或者其他方法，就能很容易的更新集成流程，这将是一个大大的加分点。

TJ：当前，ServiceMix 被分成了两个项目，ServiceMix 3.2.x/3.3.x 和 ServiceMix 4。我们书中使用 ServiceMix 3.2.x（基于 JBI），但我们对 ServiceMix 4（基于 OSGi，支持 JBI）也有一个简短的介绍。因此，ServiceMix 和 Mule ESB 之间的主要不同点就是，ServiceMix 是基于 JBI，而 Mule ESB 实现了基于 Java 的定制模型。但是这些 ESB 间还有很多共同点（支持 Spring，通过 CXF 支持 Web 服务，XML 配置）。但是，让我们着重谈谈不同点。

Mule ESB 是一个以 Java 为中心的 ESB，这让 Java 开发者能很容易地上手。它拥有强大的 XML 模式集合，它们创建了一个真正清洁可读的 XML 配置并提供了代码补全支持。当你想实现一项转换逻辑或者路由逻辑时，你能够很轻易地开发出一个简单的 Java 类 /Spring bean/ 脚本文件，把它引入到 XML 配置中。如果必须要指出 Mule 的一个不足之处，那就是缺乏对于热部署的支持。

ServiceMix 是一个以 JBI 为中心的 ESB，它提供了大量的 JBI 组件，比如 JMS，Web 服务，Camel 以及 BPEL 组件。当然，你也可以使用来自其它基于 JBI 的 ESB 的 JBI 组件，诸如 PEtALS 和我们书中介绍的 Open ESB。ServiceMix 为每个 JBI 组件都提供了一个简易的 XML 配置语言，为部署你的集成解决方案提供了热部署功能。ServiceMix 的一个缺点是进入 JBI 的学习曲线。因此，问题实际就是：在 Mule 和 ServiceMix 之间，你更愿意选择哪一个？。ServiceMix 提供了 JBI 支持，BPEL 集成，关注 XML 消息和热部署功能。Mule 提供了以 Java 为中心的模型，支持 jBPM，支持消息无关，没有热部署功能。

JD：选择使用哪一个，其实取决于你的需求。当你面临的是关注 XML 标准的集成场景时，ServiceMix 就是个不错的选择。如果你需要低级别的集成，Mule 可能是个好的选择。这两个 ESB 都是不错的开源集成解决方案，对于大多数集成问题都能很好地解决。

InfoQ：为什么你们最终选择了 ServiceMix 和 Mule，而不是其他选择？对 Apache Synapse 或者 Spring 集成（Spring Integration）有何建议？

TJ：ServiceMix 和 Mule 是活跃社区中成熟开源 ESB 的绝佳范例，它们代表了基于 JBI 的 ESB 和以 Java 为中心的 ESB 的方法。我们还会考虑其他替代方法，Apache Synapse 就是最主要的替代者。顺便说一句，在本书中，我们已经包含了 Apache Synapse 以及 Spring 集成的例子。Apache Synapse 是面向 Web 服务的 ESB 的典范，它是基于 Apache Axis2 的。当你一门心思想要获得 WS-* 支持和 Rest 支持时，Synapse 显然是一个你需要考虑的 ESB。我发现 Spring 集成是个不错的框架，可以跟 Apache Camel 相媲美。它们都对 Hohpe 和 Woolf 描述的企业集成模式提供了支持，这样无需单独的集成容器，你就能很轻易地将你的 Java 应用程序集成进来。因此，在不需要引入中心 ESB 容器，在应用程序级别实现集成功能情况下，这些框架非常有用。

JD：我个人没有过多接触 Spring 集成，为了体验它，我们正在用它做一个很小的项目。目前为止，我们对它印象还不错。它是相当轻量级的解决方案，可以轻易地与我们编写的其余 Spring 应用程序相结合。在我们开始写这本书时，开源 ESB 社区还不如现在成熟，而且现在有了更成熟的解决方案。

TJ：一定要关注开源 ESB 社区，这里有许多活动和项目以及活跃的社区可供选择！

InfoQ：非常感谢！

查看英文原文： Tijs Rademakers and Jos Dirksen on Open Source ESB 。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。