Spring Integration RC1孵化：与Iwein Fuld谈主要优势、部署及未来发展方向

Spring Integration提供了Spring编程模型的一个扩展，以支持众所周知的企业集成模式。RC1在本周宣布可用之后，InfoQ采访了SpringSource的Iwein Fuld以了解主要优势、部署场景和Spring Integration的未来方向。

Spring Integration能在基于Spring的应用中进行简单的消息通信，并通过简单的适配器与外部系统集成。这些适配器提供了一个更高级别的抽象，超越了Spring对远程调用、消息和调度的支持。其主要目标是在保持关注点分离的同时，为构建企业集成解决方案提供一个简单的模型，该模型对产出可维护、可测试的代码来说是必不可少的。

InfoQ与Iwein Fuld讨论了Spring家族的这一新成员。

InfoQ：Iwein，你认为使用Spring Integration的主要优势是什么？

传统的消息都以ESB的形式，或至少以JMS代理的形式引入企业。这需要创建一个新的环境，或者在现有应用中进行较大的改变。Spring Integration与此不同，因为它从现有应用的视角进行集成。它允许开发人员为应用进行声明式的异步集成，而不用改变服务实现。

在我们的实现中，我们非常注意保持事情的简单性。保持开发人员利用框架完成必须做的工作尽量简单很重要，不仅如此，保持开发人员调试时必须理解的代码尽量简单也同样重要。

跟Spring的其它部分一样，我们在应用代码之外维护底层代码。所以只要你坚持并发编程的最简单规则——无状态服务和不变对象，将你的服务绑定到任何生产者或消费者上都会轻而易举。如果你想从JMS转换为RMI（这只是举一个例子），你并不用修改你的代码。

InfoQ：常见的部署场景有哪些？

最常见的，人们将结合JMS使用Spring Integration。JMS配置的简化，仅仅这一点就是开始使用它的强有力的理由。当然还有其它应用，因为我们并不依赖JMS作为传输机制。

例如你可以使用Spring Integration在Web客户端实现一个等待页面。如今许多应用程序都在服务器端阻塞线程，以等待一个外部的Web服务调用。使用Spring Integration就能很容易地予以避免，而不需要JMS条件或自己编写并发代码。如果你有支持“推”（push）的富客户端，你甚至不用编写自己的缓存，客户端就能“拉”（poll）出缓存。

我们在论坛上看到很多人有简单的EDA，它基于目录中提供的文件，或者是发送到特定地址的电子邮件。我们已经让编写自己的适配器变得很容易，人们对XMMP、OSGi、Twitter的尝试一直都是成功的。由于将这些东西绑定在一起是那么容易，以至于我都期望Spring Integration能对使网络成为更有趣的地方而大有裨益。

InfoQ：你如何看待Spring Integration未来的发展？

首先，我们正在增加适配器的种类。Spring Extensions项目主办了专门的Spring Integration Adapters项目，该项目将存放不同的适配器，你能从中进行挑选。这给社区提供了一种很好的方式来贡献他们认为最有用的适配器。

我们一直在尝试的第二件事情是用Spring Integration构建可伸缩的应用。因为它能用非常简洁的方式进行并发处理，这可能是在多核环境下构建网格方案很好的备选方法。我们期望至少以后能实现一些示例。

一直以来，我们多次被问到Spring Integration是不是一个ESB，简短的回答是“不是”。但是从我们提供的组件构建ESB会非常容易。我们通常认为没有ESB会更好一些，但看起来似乎ESB构建者会使用Spring Integration。

出于个人兴趣，对Spring Integration用于与Amazon EC2协同工作的自动伸缩环境，我已经有了一些构想。这些东西看起来非常有希望，但对企业来说，为当前存在的问题找到解决方案要比追随最新的流行语更为重要。我认为我们比OSGi早实现FTP集成是一种有力的标志。我们关心的是企业如今不得不处理的底层问题。

你可以在InfoQ上获取更多关于Spring家族、SOA、架构和企业集成模式的内容。

查看英文原文：Spring Integration RC1 hatched: Q&A with Iwein Fuld on key benefits, deployment & future directions