[toc]
Why SpringIntegration
翻译自 JoshuaLong，Getting Started With Spring Integration
Spring Integration 是 Spring 体系下创建的又一个 框架，面向企业应用集成（EAI）。说到集成，并不缺“解决办法”：硬编码的 Java 客户端、其它 ESB 产品，还有消息队列等更加传统的应用集成技术。
Spring Integration 对以上各种解决方法都有所改进，Spring Integration 非常轻量、易于测试；几乎没有入门门槛，概念上比任何“自己编写”的解决方法都要简单。长远来看，它更为灵活、更具有适应性。一旦使用，你就会恋上它。
Spring Integration 可以和 EJB、RMI、JMS 这些标准技术协同使用，能让你在一处对复杂的解决方法进行建模，从而对标准技术有所增强。这在很大程度上简化了这些技术的使用。由于 Spring Integration 非常轻量（直接嵌入到了SpringApp中），而且很注重开发生命周期（方便配置的 XML schema、友好的 POJO 形式 API、与 Spring 框架和 JEE 的强大集成），所以你会发现跟其它很多的 ESB 产品相比，Spring Integration 要更加适用。
Spring Integration 本身就很强大，毋庸置疑，它从 Spring 框架中得到了强大的支持。比如说，配置格式无非还是 Spring schema，这些配置格式反过来又为你抽象出了 bean 示例。Spring Integration 的使用没什么特殊之处，可以像编写其它Spring应用一样编写SpringIntegration代码。
Spring Integration 中很多对 RPC 和消息的可用支持都以 Spring 框架的支持为基础。Spring Integration 配置文件中的所有内容仍是标准的 Spring 应用上下文，和通常的 Spring bean 一样，它也受益于依赖注入和运行时可用的方面（Aspect）。使用 Spring Integration，应用上下文就是总线了。比如这能使依赖于应用上下文事件的解决方案成为可能。这是没有独立“运行时”的另一个原因，因为只要上下文可用，总线就存在。
Background
企业应用集成（EAI）是集成应用之间数据和服务的一种应用技术。它能解决很多问题，解决方案也是多种多样。全世界工程师们已经为这些解决方案的创建努力了数十年。就在最近，我们才确定了原则的最佳实践，并对这些方案进行了分类。现代 EAI 的模式通常要归功于 Gregor Hohpe 等人编著的《企业集成模式》，该书对集成解决方案共有的很多集成模式进行了分类和阐述。Hohpe 等人列出了四种集成风格：
- 文件传输：两个系统生成文件，文件的有效负载就是由另一个系统处理的消息。该类风格的例子之一是针对文件轮询目录或 FTP 目录，并处理该文件。
- 共享数据库：两个系统查询同一个数据库以获取要传递的数据。一个例子是你部署了两个 EAR 应用，它们的实体类（JPA、Hibernate 等）共用同一个表。
- 远程过程调用：两个系统都暴露另一个能调用的服务。该类例子有 EJB 服务，或 SOAP 和 REST 服务。
- 消息：两个系统连接到一个公用的消息系统，互相交换数据，并利用消息调用行为。该风格的例子就是众所周知的中心辐射式的（hub-and-spoke）JMS 架构。
这些风格迥然不同，因为没有一种解决办法能解决所有的问题。这导致整个中间件领域都在基于这些模式寻求可用或者更好的解决办法，通常被称为企业服务总线（ESB）。ESB 是最终的代理人：它知道如何使用各种语言在各种协议上调解传递的各种消息。
这些架构风格是不同的，它们各有所长。通常，JEE 标准存在着不足（坦率地说，现今的任何开发平台都是一样），与其它系统集成时这些标准并不能提供解决方案。考虑到很多项目都是维护项目，新平台中又有多少技术会使用旧服务或功能呢？少之又少!
JEE 以及后来的 Spring 在简化企业编程模型方面都有了长足的进步。JEE 进行了标准化并商业化了常见企业问题——数据库访问、远程过程调用、事务、认证、目录服务等等。除了基本的 RPC 和消息，JEE 中并没有对 EAI 解决方案的直接支持。
JMS、REST 和 SOAP 都与平台无关，但这是假设有单一的消息协议。比如说，有一个旧的主机应用，其输入、输出都是存放在一些 FTP 端点上的批处理文件，解决方案要求集成该应用就是不可能的。简单来说：现今的中间件能很好地处理常见问题，但在特殊情况的处理上就有所不足了。
之后复杂性会急剧上升。随着时间的推移，应用变得更为重要，与商业伙伴、其它应用、其它平台集成的负担也变得更加昂贵。对必须进行维护的系统来说，每次集成都增加了系统间点对点的新通道。最终，集成各个端点的通道就会成为一个维持不了的烂摊子、复杂的架构。
SpringIntegration 简化了编程方式，以此改进了标准的 ESB。
Consolidate Architecture
如何统一企业级应用集成方案并消除架构壁垒？
企业应用集成有很多模式，同样有很多需要处理的协议。Spring Integration 提供 ESB 风格解决方案的建模能力，但使用方法及其便利性与 Spring 框架并无二致。ESB 不仅能提供消息解决方案的建模能力，还有其它不同的技术 / 协议。
ESB service
大多数 ESB 产品都有一些共性。其中最重要的有：
- 路由：能按条件逻辑或配置好的路由规则路由消息。
- 消息传递：对任何复杂的解决方案来说，将消息的有效负载从一种类型转换为另一种类型都至关重要。在消息传递中，标准数据模型模式要求系统提供通用的格式。处理消息自然也是 ESB 的另一个重要组成部分。
- 调解：适配器和服务映射。
- 复杂事件处理（CEP）：根据相关性将总线上的事件处理为聚集的能力。
- 调用：这应该是最明显的一个。每个 ESB 都要能消费、提供服务。
除了上面列出的服务，ESB 通常还要包括记日志、审计、认证（安全）和管理等机制。如果你的需求更加复杂，那 ESB 会提供很大的价值。对比你在 JEE 平台中已经获得的东西和 ESB 能带给你的东西很有价值。
Popular Solutions
Spring Integration 是新生事物，当然会遭受质疑。
Mule 是一个非常受欢迎的的 ESB 产品，值得密切关注。Mule 似乎有很大的影响力，在解决方案的灵活性上也令人印象深刻。通过 MuleForge 实现的开源扩展使其成为几乎所有问题令人信服的选择。它是一个标准的服务器：能部署并运行解决方案。Maven 插件有助于开发的生命周期。
ServiceMix 也比较受欢迎。ServiceMix 原本基于 Java 业务集成规范（JBI；JSR 208[9]）。JBI 是构建 ESB 产品的 JCP 规范。由于出身 JBI，ServiceMix 不如 Mule 那般灵活，但它正在进行改进。容器正转向 OSGi 基础设施。
这里没有列出其它所有有价值的 ESB 产品，要是有机会你还是要对它们多了解一下。有些非常有价值，值得研究。
Spring Integration 开箱即用的功能表现得很好，非常易于使用。开发用例非常引人注目：如果你已经被 POJO 和近年来测试友好的框架宠坏了，那这个框架也是你的拿手好戏。只要你愿意，你可以使用接口或标准框架类，你还可以完全为 POJO 和你的领域模型进行编码，或者，你可以将两者结合使用。
Getting Started
Spring Integration 应用就是使用 Spring schema 配置的简单 Java 程序。如果你倾向于用常规的 Spring 配置来配置一切，就可以不使用 schema。Schema 会使事情更为简单，这和用 schema 配置使用 Spring 中方面的事务功能会更加简单大致一样。Spring Integration 为一般概念（集成命名空间）提供了方便的 schema，还有适配器的具体配置，比如针对消息队列、电子邮件或文件类型的配置。
Overview
Spring Integration 应用处理从通道传递过来的消息概念。消息的生命周期始于一个端点，通常是对适配器做出的反应。消息在经过处理管道的过程中，会在总线内被转化、路由至其它通道、分发、响应，或者被中断并发送到一个死消息通道中去，即消息生命终结了。
message
Message 类是个包装器，包装被处理消息的有效负载。对它进行操作，很容易获得有效负载和消息头，你可以对有效负载进行类型转换，可以检查、改变消息头。Spring Integration 不要求你直接使用 Message 接口，而应该将其转化为应用所需的数据传输对象。
例如，对于来自文件适配器（可以从文件系统发送消息的适配器）的消息可能会被改为 java.io.File 实例。对于来自MQTT适配器的消息可能会从二进制转换为JavaBean。
channel
消息在通道中传递，通道总是从一端传递到另外一端，例如，往往消息始于适配器，并流入到通道里面，在一些列的操作之后，消息离开了通道，完成了自己的使命。
通道中有多个组件：
- 转换器：获取消息内容（即负载），并改变消息本身，例如进入通道的时候是MQTT的二进制消息，转换之后变成了JavaDomainBean或其它。转换之后，消息将继续向下走
- 过滤器：根据自身业务要求，过滤出需要处理的消息
- 路由器：将经过处理的消息发送到其它的 SpringIntegration 组件，或者是SpringService，甚至可以是Event。。。SpringIntegration的宿主是SpringApplicationContext，所以IOC容器中的所有可访问的地方都可以是消息的下一个目的地
- 更多的组件。。。
Fall Short
Spring Integration 是全新且强大的。你可以对其背后的 SpringSource 的价值及其自身的不断发展抱有信心。但这并不意味着它是完美的——它离完美还远着哩！
应用集成不是一个新的领域，考虑解决方案和架构已经有数十年。应用集成的一些用法按惯例包含了重量级的适配器，比如那些与 SAP 集成的集成方法或 JDEdwards OneWorld。Spring Integration 不能直接支持这些具体情况。
尽管 Spring Integration 支持大量开箱即用的功能，但它对一些典型的适配器缺少支持，比如 SFTP、HTTPS 或 AS2。
目前，一些专有的解决方案能更好地支持这些需求。有些解决方案非常昂贵，所以你可以为 Spring Integration 试着改造第三方库、编写自己的适配器。如果你有兴趣，你会因为为 Spring Integration 编写适配器相当简单而感到惊喜。你要想开始创建解决方案，
基于种种情况，可能最终，Spring Integration 可能并不是你现在最佳的解决方案。
Conclusion
Spring Integration 是一个干净、简练的 EAI 手段，也是很好的 ESB 产品替代者。现在的 ESB 方案沉重且很难引入到一些环境中。Spring Integration 则是一个功能强大、低摩擦的替代方案，它能温和地解决一些最复杂的集成问题。
