关于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