為什么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 是如何相互依賴(lài)的。大多數(shù)的企業(yè)集成模式的工作原理也基于這些原理[本人覺(jué)得 ESB 就是集成之一組件])， 例如 過(guò)濾、路由、協(xié)議轉(zhuǎn)換、Service-Activators、分包、組包等， 該章節(jié)同時(shí)涉及一些系統(tǒng)管理方面的資料，例如控制總線以及歷史消息支持等
由于該章節(jié)比較多，接下來(lái)的連續(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)一個(gè)很重要的角色。同時(shí)，消息通道把消息生產(chǎn)者與消息消費(fèi)者進(jìn)行了解耦操作)

3.1.1?The MessageChannel Interface

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

(PS:作為Spring Integration 中一個(gè)重要的頂層接口類(lèi) 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，則說(shuō)明該消息成功發(fā)送， 如果發(fā)送超時(shí)或者被中斷，方法將返回 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:開(kāi)始提到 消息通道支持兩種模式，是否對(duì)支持消息緩存。如下的兩個(gè)子接口分別針對(duì)這兩種不同需求進(jìn)行了定義： pollable[支持緩存] 與 subscribable[不支持緩存] 通道。如下的定義是針對(duì) 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ā)送方法類(lèi)似，當(dāng)通道接受一個(gè)消息時(shí)，當(dāng)方法返回為null 則表明當(dāng)前接受情況被中斷或者超時(shí))

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ā)送消息給訂閱者的接口。 因此，他沒(méi)有提供用戶輪詢接收消息的方法，作為代替的方法見(jiàn)下文定義：)

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提供了幾種不同消息通道的實(shí)現(xiàn)類(lèi)，每個(gè)介紹如下描述，
下面介紹的是 class 類(lèi)是針對(duì)上述幾個(gè)接口實(shí)現(xiàn)，上面介紹的是interface 這一點(diǎn)讀者要注意）

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（相對(duì)于） 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(廣播訂閱通道) 實(shí)現(xiàn)廣播發(fā)送給他的任何消息給全部的訂閱者。 這是最常見(jiàn)的用于發(fā)送事件消息，其主要作用是通知，而不是文件的消息一般都是為了要處理一個(gè)單一的處理。 注意 PublishSubscribeChannel 的send 方法是可以被直接調(diào)用的。因?yàn)閺V播的動(dòng)作是在 send 觸發(fā)后，自動(dòng)調(diào)用的。 所以 作為消息訂閱者，必須擁有一個(gè) MessageHandler 并且注冊(cè)到 PublishSubscribeChannel 上。 這個(gè)不同于 PollableChannel 接口的 receive() 方法，該方法是被客戶端自動(dòng)觸發(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 類(lèi)內(nèi)部封裝了一個(gè) 隊(duì)列用戶存儲(chǔ)消息。QueueChannel 支持 點(diǎn)對(duì)點(diǎn) 的傳輸策略。 通俗理解：即便QueueChannel 同時(shí)擁有對(duì)個(gè)消費(fèi)者時(shí)，一個(gè)消息僅能給其中之一的消費(fèi)者持有[廣播模式對(duì)消息進(jìn)行了復(fù)制操作 ])，同時(shí) 該類(lèi)提供了無(wú)參數(shù)的構(gòu)造函數(shù)[隊(duì)列的容量默認(rèn)是nteger.MAX_VALUE]，同時(shí)也提供了一個(gè)指定容量大小 的構(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（無(wú)論） 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（無(wú)限期）.

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

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

RendezvousChannel

TheRendezvousChannel（會(huì)合通道） 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（場(chǎng)景） 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 實(shí)現(xiàn) "direct-handoff" 功能，當(dāng)一個(gè)消息生產(chǎn)者發(fā)送消息到 RendezvousChannel后將被阻塞， 直到消費(fèi)者調(diào)用 該 channel的 receive() 方法[反之亦然]。其內(nèi)部實(shí)現(xiàn)是這樣子的， 他實(shí)現(xiàn)很類(lèi)似 QueueChannel 除了他使用的隊(duì)列是 SynchronousQueue[JDK5 有標(biāo)準(zhǔn)提供，讀者自己翻閱資料：隊(duì)列大小 為 0 的 BlockingQueue的實(shí)現(xiàn)。]，RendezvousChannel 是為了實(shí)現(xiàn)當(dāng) 消費(fèi) 與 生產(chǎn) 消息位于不同的線程時(shí)進(jìn)行同步 使用。這樣發(fā)送者可以明確知道消息是否被消費(fèi)。而QueueChannel 則無(wú)法提供該功能的反饋。 )

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:切記：到目前為止描述的所有基于 隊(duì)列模式的 消息通道對(duì)消息的緩存默認(rèn)都是采用內(nèi)存的。 如果需要對(duì)消息進(jìn)行持久化是，你需要提供一個(gè) 'message-store' 屬性的實(shí)現(xiàn) 用戶 可持久化消息的 隊(duì)列機(jī)制的實(shí)現(xiàn)， 或者 用一個(gè)持久化的隊(duì)列機(jī)制取代 當(dāng)前的 channel實(shí)現(xiàn)，例如 JMS 。文章在 19章對(duì)此有詳細(xì)的描述。 反之，當(dāng)不需要對(duì)消息進(jìn)行緩存是，由一個(gè)比較簡(jiǎn)單的實(shí)現(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)答模式的場(chǎng)景，消息發(fā)送者創(chuàng)建一個(gè)臨時(shí)的，匿名的 RendezvousChannel 實(shí)例 作為發(fā)送消息的返回通道被消息引用。 當(dāng)消息發(fā)送后，發(fā)送者可以立刻 對(duì) 該臨時(shí)的 channel 調(diào)用 receive 方法 ，這樣在響應(yīng)返回之前程序處于阻塞狀態(tài)，直到響應(yīng)返回或者超時(shí)。這是一個(gè) Spring Integration 框架中最簡(jiǎn)單的 request-reply 模式組件的實(shí)現(xiàn))

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

總結(jié)

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

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