3.1 Message Channels

Spring Integration's top-levelMessageChannelinterface is defined as follows.

(PS:作为Spring Integration 中一个重要的顶层接口类 MessageChannel，定义如下的接口方法： )

public interface MessageChannel {boolean send(Message message);boolean send(Message message, long timeout);
}

When sending a message, the return value will be true if the message is sent successfully. If the send call times out or is interrupted, then it will return false.

(PS:当进行发送消息是，如果返回值为 true，则说明该消息成功发送， 如果发送超时或者被中断，方法将返回 false，表示消息发送失败。)

Since Message Channels may or may not buffer Messages (as discussed in the overview), there are two sub-interfaces defining the buffering (pollable) and non-buffering (subscribable) channel behavior. Here is the definition ofPollableChannel.

(PS:开始提到 消息通道支持两种模式，是否对支持消息缓存。如下的两个子接口分别针对这两种不同需求进行了定义： pollable[支持缓存] 与 subscribable[不支持缓存] 通道。如下的定义是针对 PollableChannel 接口的定义展现）)

public interface PollableChannel extends MessageChannel {Message<?> receive();Message<?> receive(long timeout);}

Similar to the send methods, when receiving a message, the return value will be null in the case of a timeout or interrupt.

(PS:与发送方法类似，当通道接受一个消息时，当方法返回为null 则表明当前接受情况被中断或者超时)

TheSubscribableChannelbase interface is implemented by channels that send Messages directly to their subscribedMessageHandlers. Therefore, they do not provide receive methods for polling, but instead define methods for managing those subscribers:

(PS:SubscribableChannel 继承了 MessageChannel 接口，并再次基础上提供了发送消息给订阅者的接口。 因此，他没有提供用户轮询接收消息的方法，作为代替的方法见下文定义：)

public interface SubscribableChannel extends MessageChannel {boolean subscribe(MessageHandler handler);boolean unsubscribe(MessageHandler handler);}

3.1.2 Message Channel Implementations

Spring Integration provides several different Message Channel implementations. Each is briefly described in the sections below.

（PS：Spring Integration提供了几种不同消息通道的实现类，每个介绍如下描述，
下面介绍的是 class 类是针对上述几个接口实现，上面介绍的是interface 这一点读者要注意）

public QueueChannel(int capacity)

A channel that has not reached its capacity limit will store messages in its internal queue, and thesend()method will return immediately even if no receiver is ready to handle the message. If the queue has reached capacity, then the sender will block until room is available. Or, if using the send call that accepts a timeout, it will block until either room is available or the timeout period elapses, whichever occurs first. Likewise, a receive call will return immediately if a message is available on the queue, but if the queue is empty, then a receive call may block until either a message is available or the timeout elapses. In either case, it is possible to force（强 制） an immediate（立即） return regardless（无论） of the queue's state by passing a timeout value of 0. Note however, that calls to the no-arg versions ofsend()andreceive()will block indefinitely（无限期）.

(PS:当QueueChannel内部的队列容量没有达到使用上限，那么，调用send() 方法发送消息给channel时则会立刻返回， 消息被缓存于消息队列中等待被接收者接受。当内部队列达到上限时，这是在调用 send() 方法，将被阻塞，直到 队列出现空位或者超时被终端才返回。这种情况同样适用于接受。如果队列中存在自己需要的消息，则直接返回。当队列为空时， 接收方法同样阻塞，直到有消息到达或者超时被中断。当然，如果强制想让 receive() 方法不管是否接受到消息都 立即返回，则设置 超时时间 参数 为 0 即可。如果没有参数，阻塞将被无限期延长。)

TheRendezvousChannel（会合通道） enables a "direct-handoff"（直接切换） scenario where a sender will block until another party invokes the channel'sreceive()method or vice-versa（反之依然）. Internally, this implementation is quite similar to theQueueChannelexcept that it uses aSynchronousQueue(a zero-capacity implementation ofBlockingQueue). This works well in situations（场景） where the sender and receiver are operating in different threads but simply dropping the message in a queue asynchronously is not appropriate（适当）. In other words, with aRendezvousChannelat least the sender knows that some receiver has accepted the message, whereas（然而） with aQueueChannel, the message would have been stored to the internal queue and potentially never received.

(PS: RendezvousChannel 实现 "direct-handoff" 功能，当一个消息生产者发送消息到 RendezvousChannel后将被阻塞， 直到消费者调用 该 channel的 receive() 方法[反之亦然]。其内部实现是这样子的， 他实现很类似 QueueChannel 除了他使用的队列是 SynchronousQueue[JDK5 有标准提供，读者自己翻阅资料：队列大小 为 0 的 BlockingQueue的实现。]，RendezvousChannel 是为了实现当 消费 与 生产 消息位于不同的线程时进行同步 使用。这样发送者可以明确知道消息是否被消费。而QueueChannel 则无法提供该功能的反馈。 )

Keep in mind（切记，牢记） that all of these queue-based channels are storing messages in-memory only by default. When persistence（持久化） is required, you can either provide a 'message-store' attribute within the 'queue' element to reference a persistent MessageStore implementation, or you can replace the local channel with one that is backed by a persistent broker, such as a JMS-backed channel or Channel Adapter. The latter option allows you to take advantage of any JMS provider's implementation for message persistence, and it will be discussed in Chapter 19, JMS Support. However, when buffering in a queue is not necessary, the simplest approach is to rely upon theDirectChanneldiscussed next.

(PS:切记：到目前为止描述的所有基于 队列模式的 消息通道对消息的缓存默认都是采用内存的。 如果需要对消息进行持久化是，你需要提供一个 'message-store' 属性的实现 用户 可持久化消息的 队列机制的实现， 或者 用一个持久化的队列机制取代 当前的 channel实现，例如 JMS 。文章在 19章对此有详细的描述。 反之，当不需要对消息进行缓存是，由一个比较简单的实现 那就是 DirectChannel。 )

TheRendezvousChannelis also useful for implementing request-reply operations. The sender can create a temporary, anonymous instance ofRendezvousChannelwhich it then sets as the 'replyChannel' header when building a Message. After sending that Message, the sender can immediately call receive (optionally providing a timeout value) in order to block while waiting for a reply Message. This is very similar to the implementation used internally by many of Spring Integration's request-reply components.

(PS: RendezvousChannel 常被应用与应答模式的场景，消息发送者创建一个临时的，匿名的 RendezvousChannel 实例 作为发送消息的返回通道被消息引用。 当消息发送后，发送者可以立刻 对 该临时的 channel 调用 receive 方法 ，这样在响应返回之前程序处于阻塞状态，直到响应返回或者超时。这是一个 Spring Integration 框架中最简单的 request-reply 模式组件的实现)