為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??

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

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:消息作為傳輸數(shù)據(jù)的載體充當(dāng)一個很重要的角色。同時，消息通道把消息生產(chǎn)者與消息消費者進(jìn)行了解耦操作)

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:當(dāng)進(jìn)行發(fā)送消息是，如果返回值為 true，則說明該消息成功發(fā)送， 如果發(fā)送超時或者被中斷，方法將返回 false，表示消息發(fā)送失敗。)

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:開始提到 消息通道支持兩種模式，是否對支持消息緩存。如下的兩個子接口分別針對這兩種不同需求進(jìn)行了定義： pollable[支持緩存] 與 subscribable[不支持緩存] 通道。如下的定義是針對 PollableChannel 接口的定義展現(xiàn)）)

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:與發(fā)送方法類似，當(dāng)通道接受一個消息時，當(dāng)方法返回為null 則表明當(dāng)前接受情況被中斷或者超時)

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 接口，并再次基礎(chǔ)上提供了發(fā)送消息給訂閱者的接口。 因此，他沒有提供用戶輪詢接收消息的方法，作為代替的方法見下文定義：)

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提供了幾種不同消息通道的實現(xiàn)類，每個介紹如下描述，
下面介紹的是 class 類是針對上述幾個接口實現(xiàn)，上面介紹的是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(廣播訂閱通道) 實現(xiàn)廣播發(fā)送給他的任何消息給全部的訂閱者。 這是最常見的用于發(fā)送事件消息，其主要作用是通知，而不是文件的消息一般都是為了要處理一個單一的處理。 注意 PublishSubscribeChannel 的send 方法是可以被直接調(diào)用的。因為廣播的動作是在 send 觸發(fā)后，自動調(diào)用的。 所以 作為消息訂閱者，必須擁有一個 MessageHandler 并且注冊到 PublishSubscribeChannel 上。 這個不同于 PollableChannel 接口的 receive() 方法，該方法是被客戶端自動觸發(fā)的。)

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 類內(nèi)部封裝了一個 隊列用戶存儲消息。QueueChannel 支持 點對點 的傳輸策略。 通俗理解：即便QueueChannel 同時擁有對個消費者時，一個消息僅能給其中之一的消費者持有[廣播模式對消息進(jìn)行了復(fù)制操作 ])，同時 該類提供了無參數(shù)的構(gòu)造函數(shù)[隊列的容量默認(rèn)是nteger.MAX_VALUE]，同時也提供了一個指定容量大小 的構(gòu)造函數(shù)，如下所示

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（強(qiáng) 制） 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:當(dāng)QueueChannel內(nèi)部的隊列容量沒有達(dá)到使用上限，那么，調(diào)用send() 方法發(fā)送消息給channel時則會立刻返回， 消息被緩存于消息隊列中等待被接收者接受。當(dāng)內(nèi)部隊列達(dá)到上限時，這是在調(diào)用 send() 方法，將被阻塞，直到 隊列出現(xiàn)空位或者超時被終端才返回。這種情況同樣適用于接受。如果隊列中存在自己需要的消息，則直接返回。當(dāng)隊列為空時， 接收方法同樣阻塞，直到有消息到達(dá)或者超時被中斷。當(dāng)然，如果強(qiáng)制想讓 receive() 方法不管是否接受到消息都 立即返回，則設(shè)置 超時時間 參數(shù) 為 0 即可。如果沒有參數(shù)，阻塞將被無限期延長。)

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 強(qiáng)制實現(xiàn) 先進(jìn)先出 的消息消費模式，而 PriorityChannel 實現(xiàn)允許消息在隊列內(nèi)改變 自己順序的功能（基于優(yōu)先級）。默認(rèn)的策略屬性 定義在消息頭中 的 priority映射的屬性。但是需要自定義優(yōu)先級判斷邏輯 ，比較器實現(xiàn)了Comparator<Message<?>>接口，通過調(diào)用該接口實現(xiàn) 優(yōu)先級策略。)

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（適當(dāng)）. 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 實現(xiàn) "direct-handoff" 功能，當(dāng)一個消息生產(chǎn)者發(fā)送消息到 RendezvousChannel后將被阻塞， 直到消費者調(diào)用 該 channel的 receive() 方法[反之亦然]。其內(nèi)部實現(xiàn)是這樣子的， 他實現(xiàn)很類似 QueueChannel 除了他使用的隊列是 SynchronousQueue[JDK5 有標(biāo)準(zhǔn)提供，讀者自己翻閱資料：隊列大小 為 0 的 BlockingQueue的實現(xiàn)。]，RendezvousChannel 是為了實現(xiàn)當(dāng) 消費 與 生產(chǎn) 消息位于不同的線程時進(jìn)行同步 使用。這樣發(fā)送者可以明確知道消息是否被消費。而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:切記：到目前為止描述的所有基于 隊列模式的 消息通道對消息的緩存默認(rèn)都是采用內(nèi)存的。 如果需要對消息進(jìn)行持久化是，你需要提供一個 'message-store' 屬性的實現(xiàn) 用戶 可持久化消息的 隊列機(jī)制的實現(xiàn)， 或者 用一個持久化的隊列機(jī)制取代 當(dāng)前的 channel實現(xiàn)，例如 JMS 。文章在 19章對此有詳細(xì)的描述。 反之，當(dāng)不需要對消息進(jìn)行緩存是，由一個比較簡單的實現(xiàn) 那就是 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 常被應(yīng)用與應(yīng)答模式的場景，消息發(fā)送者創(chuàng)建一個臨時的，匿名的 RendezvousChannel 實例 作為發(fā)送消息的返回通道被消息引用。 當(dāng)消息發(fā)送后，發(fā)送者可以立刻 對 該臨時的 channel 調(diào)用 receive 方法 ，這樣在響應(yīng)返回之前程序處于阻塞狀態(tài)，直到響應(yīng)返回或者超時。這是一個 Spring Integration 框架中最簡單的 request-reply 模式組件的實現(xiàn))

轉(zhuǎn)載于:https://my.oschina.net/qfhxj/blog/95351

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。