《Open Source ESB in Action》作者谈开源ESB
Ivan
《Open Source ESB in Action》作者谈开源ESB
作者 Stefan Tilkov译者 胡键 发布于 2009年3月23日 上午3时42分
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：非常感谢！