為什么80%的碼農都做不了架構師？>>> ??

Part?III.?Core Messaging

This section covers all aspects of the core messaging API in Spring Integration. Here you will learn about Messages, Message Channels, and Message Endpoints. Many of the Enterprise Integration Patterns are covered here as well, such as Filters, Routers, Transformers, Service-Activators, Splitters, and Aggregators. The section also contains material about System Management, including the Control Bus and Message History support.

(PS:該章節覆蓋了Spring Integration的核心API講解，你將了解到Messages, Message Channels, and Message Endpoints 是如何相互依賴的。大多數的企業集成模式的工作原理也基于這些原理[本人覺得 ESB 就是集成之一組件])， 例如 過濾、路由、協議轉換、Service-Activators、分包、組包等， 該章節同時涉及一些系統管理方面的資料，例如控制總線以及歷史消息支持等
由于該章節比較多，接下來的連續幾篇文章都是關于該章節的分段描述。

3.?Messaging Channels

3.1?Message Channels

While theMessageplays the crucial（重要） role of encapsulating（封裝） data, it is theMessageChannelthat decouples（解 耦） message producers from message consumers.

(PS:消息作為傳輸數據的載體充當一個很重要的角色。同時，消息通道把消息生產者與消息消費者進行了解耦操作)

3.1.1?The MessageChannel Interface

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，表示消息發送失敗。)

PollableChannel

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 則表明當前接受情況被中斷或者超時)

SubscribableChannel

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 這一點讀者要注意）

PublishSubscribeChannel

ThePublishSubscribeChannelimplementation broadcasts（廣播） any Message sent to it to all of its subscribed handlers. This is most often used for sending Event Messages whose primary role is notification as opposed to（相對于） Document Messages which are generally intended to be processed by a single handler. Note that thePublishSubscribeChannelis intended for（用于） sending only. Since it broadcasts to its subscribers directly when itssend(Message)method is invoked, consumers cannot poll for Messages (it does not implementPollableChanneland therefore has noreceive()method). Instead, any subscriber must be aMessageHandleritself, and the subscriber'shandleMessage(Message)method will be invoked in turn.

(PS:PublishSubscribeChannel(廣播訂閱通道) 實現廣播發送給他的任何消息給全部的訂閱者。 這是最常見的用于發送事件消息，其主要作用是通知，而不是文件的消息一般都是為了要處理一個單一的處理。 注意 PublishSubscribeChannel 的send 方法是可以被直接調用的。因為廣播的動作是在 send 觸發后，自動調用的。 所以 作為消息訂閱者，必須擁有一個 MessageHandler 并且注冊到 PublishSubscribeChannel 上。 這個不同于 PollableChannel 接口的 receive() 方法，該方法是被客戶端自動觸發的。)

QueueChannel

TheQueueChannelimplementation wraps a queue. Unlike thePublishSubscribeChannel, theQueueChannelhas point-to-point semantics. In other words, even if（即使） the channel has multiple consumers, only one of them should receive any Message sent to that channel. It provides a default no-argument constructor (providing an essentially unbounded capacity ofInteger.MAX_VALUE) as well as a constructor that accepts the queue capacity:

(PS:QueueChannel 類內部封裝了一個 隊列用戶存儲消息。QueueChannel 支持 點對點 的傳輸策略。 通俗理解：即便QueueChannel 同時擁有對個消費者時，一個消息僅能給其中之一的消費者持有[廣播模式對消息進行了復制操作 ])，同時 該類提供了無參數的構造函數[隊列的容量默認是nteger.MAX_VALUE]，同時也提供了一個指定容量大小 的構造函數，如下所示

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 即可。如果沒有參數，阻塞將被無限期延長。)

PriorityChannel

Whereas theQueueChannelenforces first-in/first-out (FIFO) ordering, thePriorityChannelis an alternative implementation that allows for messages to be ordered within the channel based upon a priority. By default the priority is determined by the 'priority' header within each message. However, for custom priority determination logic, a comparator of typeComparator<Message<?>>can be provided to thePriorityChannel's constructor.

(PS:由于 QueueChannel 強制實現 先進先出 的消息消費模式，而 PriorityChannel 實現允許消息在隊列內改變 自己順序的功能（基于優先級）。默認的策略屬性 定義在消息頭中 的 priority映射的屬性。但是需要自定義優先級判斷邏輯 ，比較器實現了Comparator<Message<?>>接口，通過調用該接口實現 優先級策略。)

RendezvousChannel

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 模式組件的實現)

轉載于:https://my.oschina.net/qfhxj/blog/95351

總結

以上是生活随笔為你收集整理的#翻译NO.4# --- Spring Integration Framework的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。