为什么使用Spring Integration
Spring Integration使整个项目，以及项目的每一个模块（可以理解为功能点）轻量化。使项目易部署，易扩展，项目的内部和外部都降低了耦合度。具体来说，所有的事件、功能都是一个个小的模块，可以任意组装。如果想要增加新的需求，可以复用已支持的模块并增加新的模块来支持新的功能。所有这些又几乎都可以通过配置文件实现。就像是乐高积木，虽然最终产物不同，但是组成单位是固定的。系统和系统间通过统一Message的格式实现交互，而不用维护相同的Class。大大的增加了项目的灵活性和可扩展性。
Spring Integration的组成结构
以项目为边界划分，Adapter（其中一种Endpoint）负责接收或者发送，与外界做交互。比如通过接收Ftp的文件，将它转化为message进入项目；最终可能通过Email的outbound channel adapter将最终的message通过Email的方式发送出去。目前支持的adapter有：
Ftp/SFtp，UDP/TCP，Rest/Soap，Email（Pop3、IMAP、SMTP），JMS，JDBC，Twitter…
然后到了系统内部，内部的结构像是很多的链状结构，像是圣诞节的彩灯。连接彩灯的线叫做channel，前一个灯泡给它发送message，后一个灯泡把message收走（可能是点到点的也可能是广播式的）。然后彩灯分成了两部分，一种是普通灯泡：实现业务逻辑，转换文件或者执行一些具体操作；另一种是功能性灯泡。之后会具体说一些已有的控件的具体功能。
SpringIntegration中传递的信息我们叫做Message，它可以以很多形式存在，比如Xml、String甚至DB里面的records。message有两部分组成，header部分记录了message的一些信息比如它从哪里来要到哪里去… payload部分则是message的内容。message又有很多种有的是传递信息的有的是传递命令的。
Message Channel刚刚简单提了一下，他的目的主要是将每一个功能模块彼此隔离，解耦。他不一定是一对一的，也有可能多对一一对多，值得一提的是，可以通过这种方式实现负载平衡，比如一个channel有三个receiver，每个receiver都能完成某一个功能，每次只有一个receiver接收message，那么当一个receiver忙的时候其他的receiver就可以进行处理。
关于Message Endpoint这个概念就是我们之前提到的“模块”，是整个结构中用来对信息处理的部分。在开始我们说到了Channel adapter是一种在开始和结束整个处理流程时候用的单向的接受发送信息的Endpoint。与之类似的概念还有Gateway，他也在最后一跳的，正如它的名字，与前者不同他是双向的，也就是说在发送请求出去之后可以对返回的reply做进一步处理。
Service Activator我理解它像一个内部的webservice，就是你去call这个service然后他返回给你你想要的内容。
Router也和他的名字一样，起到了路由的作用，根据message的内容，决定使用哪一个channel作为message的出口。
Splitter用来根据某种规则拆分message，并且这些被拆分的部分进入下游被同时处理。与之相对的Aggregator用来将一组信息重新组合，只有所有部分组合完成了才会继续处理。
Spring Integration与通用企业Integration
有四种通用的企业集成模式，除了Spring Integration明显支持的Message交互，还有另外三种：
基于文件的集成：所有的集成项目都有最简单的读写文件功能，但是有一个限制就是如何保证文件的“正确性”，这个正确性可能包括时效性，完整性，可追踪性等等，总的来说就是如何保证用户或者系统再读这个文件是应该要处理的文件，是这个集成的关键。
基于数据共享的集成：就是不同应用如何共享一些公用的数据问题。一种方式是应用件都熟悉彼此的表结构，另一种是共享同一个表结构。存在的问题主要有：无法统一成一种模型；统一模型之后一变则需要多变；避免更新冲突引发的性能问题；内存开销。
基于远程程序调用的集成：就是不同系统间的方法调用，提供结果隐藏实现。相比于内部调用，远程调用因为是系统间的call，所以是不可靠的。并且仍然暴露了方法和参数信息。
针对以上这些集成问题的解决方案之后的文章中可能会提到。
总结：
以上是这本书Part 1的主要内容，我们可以大致了解到Spring Integration 的优势，特点，应用场景，大概结构。简单介绍了一些“零件”，并且引出了一些集成方面的问题。下一个章节将介绍关于Message和Channel的内容。如果想了解更多，推荐看原书。
