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
评论