关于 Mule 3 发布对 Ross Mason 的访谈

Mulesoft 最近发布了 Mule 3 ，他们的下一代 ESB 平台。在这次发布的版本中包括了一些重要的特性。【摘自 Mule 3 的发布】

Mule 云连接

该功能针对 SaaS（一种流行的云）和 Web 2.0 提供商（比如，Amazon Web 服务和 Facebook），同时也为用户提供了一种简单的方法使其能够创建自己的云连接器。

Mule 3 采用Native REST 支持的方式完全接纳 web 平台，采用AJAX/JavaScript集成的方式对各种 javascript 框架提供支持，也支持如ATOM，RSS和JSON这样的协议与数据格式。Mule 3 也提出了流的概念；这是一种集成构件，用户只需构件单元来构建方案，通过这样可以为用户提供非常简单却很灵活的办法来实现消息处理和集成方案。

流（Flow）

流是 Mule 提供的一种新颖而强大的创建消息流的方式。很多人在 Mule 的服务模型方面固守成规，这是因为他们没有从本质上以提供服务的角度来考虑问题。流允许开发人员通过自己思考解决问题的方式来创建集成流。我们在未来的文章中会更多地谈论到这点。

通过提供基于配置选项的模式，Mule 3 也提供了丰富的对模式的支持，这使得用户可以使用基于构件单元的方式应用常用的集成场景，比如 RESTful Web 服务。该产品据宣传说提供了新的部署方式，使其可以提供如自动热部署这样的特性。

这次产品的修订有大量架构方面的变化，以期支持某些新特性，这些特性旨在使产品更加易于使用、配置和部署。

InfoQ 有幸与 Ross Mason 进行了访谈，得以了解从这次产品的发布中我们大家所能期待有一些什么样的新特性。

InfoQ：大多数商业 EAI 工具和框架都提供了允许你把建模服务作为工作流的工具。尤其常见于 BPM 工具中以服务编排的方式对流程进行建模。流是如何适应那种生态系统的呢？您能不能详细说明一下您对流的定义？

RM：流是 Mule 里一种新的构件模型。对用户来说，他们看到的就是一个 XML——基于模式的 DSL——可以使服务流得以快速开发。尽管我们确实有图形化工具正在开发中，但是这种基于模式的方法益处良多——集成流的快速开发，无需学习新的接口，这就是 XML——一种能够提供自动完成和验证功能的模式——对于代码视图弹出的每一个元素和属性有完整的上下文为之提供帮助，从而使学习变得容易。我们正在开发一个开源的基于 Eclipse 的工具产品，最近还为其原型开了博： http://blogs.mulesoft.org/new-mule-ide-coming/

InfoQ：您能否解释一下在服务配置中对模式的使用情况如何？这是否是该产品的一种发展演进，通过使用一个 IDE 集成的工具链来使我们获取一个集合了各种场景的面板？如今这种支持能够发挥多大的作用？

RM：的确，模式是 ESB 的一种演进。我们已经从我们的用户和客户那里挖掘了很多的模式，并且使得这些特性在 Mule 中得以轻松的实现。这些模式将通用的（有时是复杂的）功能涵盖进一个单独的配置元素，这样使开发人员无需了解所有的细节便可以使用。Mule 向来是欢迎模式的，早在 2004 年就率先成为实现企业集成模式的第一个 ESB 产品。这些新的模式为通用服务和集成场景提供了较大粒度的构建模块。开发人员也能够定义其自己的模式。我们同时也计划在我们的 Eclipse 工具中为这些模式提供一个专门的开发面板。

InfoQ：我们在 web 应用中看到的通用场景之一，尤其对 mashups，就是对安全 javascript 调用的需求，这种调用要么是通过使用某个集中的 mashup 服务器，要么是通过支持 JASONP 的服务来提供的。那么，我们的产品在支持此类场景方面能提供多大的支持呢？

RM：当然，Mule 3 中对 AJAX/JSON 的支持是非常广泛的。正因如此，JSON 已经成为与 XML 齐名的第一等级的数据表现格式，这就意味着你可以自动完成一些事情，比如绑定 JSON 数据到 Java 对象。JSON 是如何起作用的呢，是通过一个集中的 AJAX 服务器来监管的，这样的话一个 Mule 应用就可以通过 JavaScript 调用去请求如 Salesforce.com 或 Facebook 这样的外部服务。从服务器到浏览器之间的 AJAX 通道也可以得到保护。

InfoQ：这是从 DZone 里的一段引述，能否请您就这段话谈一下您的观点？

一开始，MuleSoft 想要把 Mule 3 模块化，但他们最终决定不这样做。“如果不在 OSGi 之上增加很多额外的抽象层，厂商要把最终用户屏蔽到复杂的 OSGi 之外不是轻而易举的事”，Mason 说到。一年前他们甚至把 Mule 中所有的东西都移植到了 OSGi bundles 并且还提供了一个演示。不巧的是，这样一来开发人员就不得不明确地去管理这些 bundles，而部署模式也不会像今天这样简单。“我们没有抛弃 OSGi，因为围绕 OSGi 存在着一些新的东西。”但就目前而言，Mason 认为 OSGi 对于一般的终端用户来说还不是一个适合的技术。

RM：关于“一开始，MuleSoft 想要把 Mule 3 模块化，但他们最终决定不这样做”；Mule 一直都是模块化的，该文作者其实是在说把 Mule 运行到某个 OSGi 容器上（我们之前的确把所有 Mule 模块都移植到了 OSGi bundles）。几年前当 OSGi 刚出现在我们的视野中时，我对此还是很兴奋的。但最终证明，作为规范，OSGi 对软件厂商来说的确是很棒的，但由于其附加的一些复杂的配置和绑定，对最终用户来说就比较糟糕了。我们在 Mule 3 中达到了一个目标——简化一切。而使用 OSGi 规范，我们不能让我们的部署模式简化成用户期望的那样，所以我们决定在 OSGi 的原则基础上来构建我们自己的部署模型。这并不意味着我们不再考虑 OSGi，如果其规范改进并解决我们关于终端用户复杂性的疑虑，我们无疑将会重新评估这种方案。

InfoQ：在视频中，您简要描述了访问 mule 服务的语言绑定的可用性。您是否能再跟我们谈一些目前的可用性支持以及未来有什么计划？

RM：Mule 支持 JSR-223 脚本语言规范，这意味着可以很容易地使用如 Groovy 和 Jython 这样的动态语言来编写模块和转换器。同样的，在 Mule 中我们也提供了扩展表达语言，这使得查询、操作消息以及使用任何 JSR-223 规范支持的语言都非常容易。我们发现目前的一个趋势是：在服务器端使用 JavaScript 以及把 Mule 和 Python 结合使用，所以我们打算为这两种语言提供更多的支持。我们将为 Python 和 JavaScript 开发人员提供更舒适的方式在使用 Mule 的同时也去探寻一下 Scala。

查看英文原文： Interview With Ross Mason On The Release Of Mule 3

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