这一部分我将简单介绍书中关于Message和Channel的内容，Channel的部分将会具体介绍一些常用的Channel
Message
上一篇说过，Message作为整个流程传输的信息，实现了各个部分之间的解耦。它可以是任何形式，String/Object/XML..但是它包含了要传输的所有内容。
Message由两部分组成：[Message Header + PayLoad]
Message Header就像是信件的信封，虽然收件人不关心信封上的邮票，地址等内容，但是这些内容确保了信件能够流到收件人手里。具体的来讲就是流程中要用与决策或者执行的时候要进行参考的信息。PayLoad则是具体新建的内容。
根据角色和实现，Message可以分为三部分：
Document messages that contain only information
Command messages that instruct the recipient to perform various operations
Event messages that indicate notable occurrences in the system and to which the recipient may react
创建一个Message的流程：
Step 1: A Builder is created with Payload
Step 2: Headers are added
Step 3: A Message is created by the Builder
Message helloMessage = MessageBuilder.withPayload("Hello, world!").setHeader("custom.header", "Value").setHeaderIfAbsent("custom.header2", "Value2").build();
Channel
Channel在整个流程中起到了管道的作用，他不用在意消息的内容，也几乎不对消息进行处理，他只需要知道消息从哪里来，要往哪里去就可以了。但是他的作用并不止于一个二传手，他还可以实现很多分发的策略。
Channel都继承自Message Channel类，Message Channel又衍生了两个子类：SubscribableChannel 和 PollableChannel，他们的区别在于是否缓存，书中有两句话说明了他们的职责：SubscribableChannel就像它的名字一样是订阅式的，无需缓存，解释为“I’ll let you know when I’ve got something”，所以他的方法返回boolean值。PollableChannel需要缓存并做轮询操作，解释为“Do you have any messages for me”。
接下来用一个简单的例子来介绍几种Channel
Case：channelA -> service-activatorA -> channelB -> service-activatorB -> channelC -> adapterA
<channel id="channelA"/>
<service-activator input-channel="channelA" output-channel="channelB" ref="service-activatorA"/>
<channel id="channelB"/>
<service-activator input-channel="channelB" output-channel="channelC" ref="service-activatorB"/>
<channel id="channelC"/>
<outbound-channel-adapter channel="channelC" ref="adapterA"/>
有一个问题：这个流程是同步的，也就是说只有adapter做完才会有下一个message进来。那么如果adapter的效率不高，因为网络或者什么原因，就会限制整个的处理速度。这个时候就应该将service-activatorB和adapterA拆开，通过异步实现，就引入了带Queue的channel。配置如下：
<channel id="channelC"><queue /></channel>
下一个问题：如果有多个adapter都要发送这个flow的message，就是遇到类似分流的事情，该如何操作？这里要使用publish-subscribe-channel,所有配置以该channel为inbound的component都能接收到，但是他有一个缺点，就是不能直接实现异步，如果想实现异步还要通过bridge结构来辅助实现。配置如下：
<publish-subscibe-channel id="channelC"/>
<bridge nput-channel="channelC" output-channel="channelD"/>
<channel id="channelD"><queue /></channel>
在下一个问题：如果信息处理的顺序有规定，也就是说要按一定的优先级来结束最后的flow，要怎么做呢？可以使用priority-queue来控制进来message的先后顺序。配置如下：
<channel id="channelA"><priority-queue comparator="comparatorA"/></channel>
Channel collaborators
MessageDispatcher消息分发器，有两个子类，一个是UnicastingDispatcher,点对点进行发布，另一种是BroadcastingDispatcher进行广播式的分发。MessageDispatcher中依赖了一个Handler，用来实现逻辑部分。而dispatch则实现Delivery。
ChannelInterceptor是另一个和Channel相关的Component。它可以在Channel收到或者发送message之前或者之后进行一些处理（拦截）。它包括的方法有{preSend，postSend,afterSendCompletion,preReceive,postReceive,afterReceiveCompletion}具体是做什么的也很明显。
在channel中注册：channel.addInterceptor(someChannelInterceptor);
可以通过如下方式配置interceptor：
<channel id="channelC">
<interceptors><beans:ref bean="interceptorA"/></interceptors>
</channel>
还可以通过在interceptor中配置wire-tap来将message送到另一个Channel，用于分析message，而不在住流程中分析。
<interceptors><wire-tap channel="monitoringChannel"/></interceptors>
interceptor使用MessageSelector决定是否channel能够被发送。
Summary
这一部分主要是简单介绍了Message是什么，有哪些种类。主要介绍了一些Channel的一些应用场景。其实这一部分内容，其实看到配置是如何写的更容易理解这个channel的使用。最后一部分其实还有一些问题，可能之后在具体应用里面具体分析。下一部分将会简单介绍一些EndPoint。
