Spring Integration 是Spring 框架创建的又一个API，面向企业应用集成（EAI）。说到集成，并不缺“解决办法”：硬编码的Java 客户端、其它 ESB 产品，还有消息队列等更加传统的应用集成技术。Spring Integration 对以上各种解决方法都有所改进，改进的方式有时还颇具戏剧效果。Spring Integration 非常轻量、易于测试；几乎没有入门门槛，概念上比任何“自己编写”的解决方法都要简单。长远来看，它更为灵活、更具有适应性。一旦使用，你就会恋上它。Spring Integration可以和 EJB、RMI、JMS 这些标准技术协同使用，能让你在一处对复杂的解决方法进行建模，从而对标准技术有所增强。这在很大程度上简化了这些技术的使用。由于 Spring Integration 非常轻量（与应用一起部署 Spring Integration 服务器，不用将应用部署到Spring Integration 中去），而且很注重开发生命周期（方便配置的XML schema、友好的POJO 形式 API、与 Spring 框架和 JEE 的强大集成），所以你会发现跟其它很多的ESB 产品相比，Spring Integration 要更加适用。 Spring Integration 本身就很强大，毋庸置疑，它从 Spring 框架中得到了强大的支持。比如说，配置格式无非还是Spring schema，这些配置格式反过来又为你抽象出了 bean 示例。Spring Integration 的使用没什么神奇之处，你可以自信地编写 main(String [] args)方法来完成XML 配置所做的一切。Spring Integration 中很多对 RPC 和消息的可用支持都以 Spring 框架的支持为基础。Spring Integration配置文件中的所有内容仍是标准的Spring 应用上下文，和通常的Spring bean 一样，它也受益于依赖注入和运行时可用的方面（Aspect）。使用Spring Integration ，应用上下文就是总线了。比如这能使依赖于应用上下文事件的解决方案成为可能。这是没有独立“运行时”的另一个原因，因为只要上下文可用，总线就存在。 背景 企业应用集成（EAI）是集成应用之间数据和服务的一种应用技术。它解决无限的问题，解决方案也几乎没有穷尽。工程师们已经为这些解决方案的创建努力了数十年。就在最近，我们才确定了原则的最佳实践，并对这些方案进行了分类。 现代 EAI 的模式通常要归功于 Gregor Hohpe 等人编著的《企业集成模式》[1]，该书对集成解决方案共有的很多集成模式进行了分类和阐述。Hohpe 等人列出了四种集成风格： 1. 文件传输：两个系统生成文件，文...
