消息設計模式
[英]Message Design Patterns
問題描述
對於基於消息的傳遞系統，您的“消息設計模式”是什么？
限制定向消息（即特定目的地）
避免長級聯鏈（即與MsgB，MsgC等對MsgA作出反應）
有一個系統“心跳”消息
其他例子？
5 個解決方案
解決方案1
7
如果您正在實現基於消息的系統，我建議您閱讀規范資源以深入了解消息傳遞體系結構： 企業集成模式：設計，構建和部署消息傳遞解決方案，由Gregor Hohpe和Bobby Woolf撰寫。
有關每種模式的簡短摘要，請訪問http://www.eaipatterns.com/toc.html 。在頁面末尾有兩個案例研究。
這本書是一個很好的資源，你會發現你以前沒有想到的問題和情況，並對解決它的策略進行了很好的分析。
解決方案2
6 已采納
所有重要的內容都在“ 企業集成模式 ”一書中。 看看這個。
解決方案3
5
支持冪等消息處理：允許重復消息而不會導致“雙重借記”。
避免大信息 - 更喜歡“行李托運”的習語
避免消息訂購要求 - 大大簡化了基礎架構的負擔
解決方案4
5
消息傳遞設計模式（MDP）和模式實現 - 在第17屆程序模式語言會議上發布（PLoP 2010）。
抽象
信息交換（即信息傳遞）是自然和人為過程的固有部分。 消息傳遞是我們周圍世界無處不在的一部分。 傳統的軟件方法和組件技術忽略了消息傳遞，因此提供了不完整的模型。 另一方面，消息傳遞范例和相關的消息傳遞設計模式（MDP）解決了這一差距，並提供了更完整和准確的現實世界模型。 結果，軟件工程過程和技術得到顯着改善。 在設計和制造軟件時，我們不僅需要考慮軟件組件，還要考慮這些實體之間交換的消息傳遞。 封裝，解耦和可重用性得到改善，同時降低了復雜性。 本文還討論了如何利用消息傳遞設計模式來實現或幫助實現其他眾所周知的設計模式，如Gang of Four設計模式（GoF），數據訪問對象（DAO）和J2EE設計模式。 請記住，大多數設計模式在某種程度上負責在參與者之間交換信息。 整體設計和UML圖表得到簡化和簡化，使其更易於理解和實施。 由此產生的軟件設計和實現也更加健壯和直接。 使用MDP實現的設計模式可以重復使用，以提供對遠程組件/服務的透明和安全訪問，作為完整分布式組件模型的基礎。
解決方案5
4
根據企業集成模式 ，作者Gregor Hohpe和Bobby Woolf記錄了60多種消息模式，分為以下六類：
消息構造
消息 ：要在通過消息通道連接的兩個應用程序之間交換信息，請將信息打包到消息中，消息是消息傳遞系統可以通過消息通道傳輸的數據記錄。
命令消息 ：要使用消息傳遞在另一個應用程序中調用過程，請使用命令消息可靠地調用該過程。
文檔消息 ：要使用消息傳遞在應用程序之間傳輸數據，請使用文檔消息可靠地傳輸數據結構。
事件消息 ：使用消息傳遞將事件從一個應用程序傳輸到另一個應用程序，使用事件消息在應用程序之間進行可靠的異步事件通知
請求 - 答復 ：要在應用程序發送消息時從接收方獲得響應，請在其自己的信道上發送一對請求 - 應答消息。
返回地址 ：要通知回復者發送回復消息的位置，請求消息應包含返回地址。
相關標識符 ：為了允許請求者將請求與回復進行匹配，每個回復消息應包含相關標識符，該唯一標識符指示消息回復的目的請求。
消息序列 ：要通過消息傳送任意大量的數據，將數據分成塊並將其作為消息序列發送，用序列標識字段標記每條消息。
消息過期 ：要指示何時應將消息視為過時且因此不應處理，請將消息過期設置為指定消息可行的時間限制。
格式指示符 ：要設計消息的數據格式以允許將來可能的更改，請包括格式指示符，以便消息指定它使用的格式。
消息路由
管道和過濾器 ：要在保持獨立性和靈活性的同時對消息執行復雜處理，請使用管道和過濾器架構樣式將較大的處理任務划分為一系列通過通道連接的較小的獨立處理步驟（過濾器）（管道）。
消息路由器 ：要分離各個處理步驟，以便根據一組條件將消息傳遞到不同的過濾器，插入一個特殊的過濾器，一個消息路由器，它消耗來自一個消息通道的消息並將其重新發布到另一個消息通道通道取決於一組條件。
基於內容的路由器 ：為了處理單個邏輯功能（例如，庫存檢查）的實現分布在多個物理系統上的情況，使用基於內容的路由器基於消息內容將每個消息路由到正確的接收者。
消息過濾器 ：為避免組件接收不感興趣的消息，請使用特殊類型的消息路由器（消息過濾器），以根據一組條件消除來自通道的不需要的消息。
動態路由器 ：為了避免路由器對所有可能目的地的依賴性，同時保持其效率，請使用動態路由器，這是一種可以根據來自參與目的地的特殊配置消息進行自我配置的路由器。
收件人列表 ：要將郵件路由到動態指定的收件人列表，請為每個收件人定義一個頻道。 然后使用“收件人列表”檢查傳入郵件，確定所需收件人列表，並將郵件轉發到與列表中收件人關聯的所有頻道。
拆分器 ：要處理消息，如果它包含多個元素，每個元素可能必須以不同的方式處理，請使用拆分器將復合消息分解為一系列單獨的消息，每個消息包含與一個項目相關的數據。
聚合器 ：要組合單個但相關的消息的結果以便可以將它們作為一個整體進行處理，請使用有狀態過濾器（聚合器）來收集和存儲單個消息，直到收到完整的相關消息集。 然后，Aggregator發布從單個消息中提取的單個消息。
重定序器 ：要將相關但無序的消息流恢復到正確的順序，請使用有狀態過濾器（重定序器）來收集和重新排序消息，以便它們可以按指定的順序發布到輸出通道。
組合消息處理器 ：要在處理由多個元素組成的消息時維護整個消息流，每個元素可能需要不同的處理，請使用組合消息處理器來處理組合消息。 組合消息處理器將消息拆分，將子消息路由到適當的目的地，並將響應重新聚合回單個消息。
Scatter-Gather ：為了在需要將消息發送給多個收件人（每個收件人都可以發送回復）時維護整體消息流，使用Scatter-Gather向多個收件人廣播郵件並將響應重新聚合回一個單個消息。
路由滑動 ：當在設計時不知道步驟序列並且每個消息可能不同時，通過一系列處理步驟連續路由消息，將路由滑動附加到每個消息，指定處理步驟的順序。 使用讀取路由滑動的特殊消息路由器包裹每個組件，並將消息路由到列表中的下一個組件。
進程管理器 ：當在設計時可能不知道所需步驟並且可能不是順序時，通過多個處理步驟路由消息，使用中央處理單元，進程管理器來維護序列的狀態並確定下一個基於中間結果的處理步驟。
消息代理 ：要將消息的目標與發送方分離並保持對消息流的集中控制，請使用可從多個目標接收消息的中央Message Broker，確定正確的目標並將消息路由到正確的通道。
消息轉換（翻譯）
消息轉換器 ：要允許使用不同數據格式的系統使用消息傳遞相互通信，請在其他過濾器或應用程序之間使用特殊過濾器，消息轉換器將一種數據格式轉換為另一種數據格式。
信封包裝器 ：要允許現有系統參與對郵件格式提出特定要求的郵件交換，例如郵件頭字段或加密，請使用信封包裝器將應用程序數據包裝在符合郵件基礎結構的信封內。 在郵件到達目的地時展開郵件。
內容豐富 ：如果消息發起者沒有可用的所有必需數據項，要與另一個系統通信，請使用專用變換器（內容加載器）訪問外部數據源，以便增加缺少信息的消息。
內容過濾器 ：為了簡化處理大型郵件，當一個人只對一些數據項感興趣時，使用內容過濾器從郵件中刪除不重要的數據項，只留下重要的項目。
聲明檢查 ：要減少通過系統發送的消息的數據量而不犧牲信息內容，請將消息數據存儲在持久性存儲中，並將聲明檢查傳遞給后續組件。 這些組件可以使用Claim Check來檢索存儲的信息。
規范化程序 ：要處理語義上等效但以不同格式到達的消息，請使用規范化程序通過自定義消息轉換程序路由每種消息類型，以便生成的消息與通用格式匹配。
規范數據模型 ：為了在集成使用不同數據格式的應用程序時最小化依賴性，請設計獨立於任何特定應用程序的規范數據模型。 要求每個應用程序以此通用格式生成和使用消息。
消息端點
消息端點 ：要將應用程序連接到消息傳遞通道以發送和接收消息，請使用消息端點，消息傳遞系統的客戶端，然后應用程序可以使用該客戶端發送或接收消息。
消息傳遞網關 ：要封裝從應用程序其余部分對消息傳遞系統的訪問，請使用消息傳遞網關，這是一個類，而不是包裝特定於消息傳遞的方法調用，並向應用程序公開特定於域的方法。
消息傳遞映射器 ：要在域對象和消息傳遞基礎結構之間移動數據，同時保持兩者彼此獨立，請創建一個單獨的消息傳遞映射器，其中包含消息傳遞基礎結構和域對象之間的映射邏輯。 對象和基礎設施都不知道Messaging Mapper的存在。
事務客戶端 ：要允許客戶端tp控制其與消息傳遞系統的事務，請使用事務客戶端 - 使客戶端與消息傳遞系統進行事務性會話，以便客戶端可以指定事務邊界。
輪詢使用者 ：為了允許應用程序在應用程序准備就緒時使用消息，應用程序應該使用輪詢消費者，該消費者在想要接收消息時明確地進行呼叫。
事件驅動程序使用者 ：為了允許應用程序在消息可用時自動使用消息，應用程序應使用事件驅動的消費者，消費者在消息傳遞時自動傳遞消息。
競爭消費者 ：為了允許消息傳遞客戶端同時處理多個消息，在單個通道上創建多個競爭消費者，以便消費者可以同時處理多個消息。
消息調度程序 ：要在單個通道上協調跨多個使用者的消息處理，請在通道上創建消息調度程序，該消息調度程序將使用來自通道的消息並將其分發給執行者。
選擇性消費者 ：為了允許消息使用者選擇它希望接收哪些消息，使消費者成為選擇性消費者，消費者過濾由其渠道傳遞的消息，以便它只接收符合其標准的消息。
持久訂閱者 ：為避免訂閱丟失消息而未偵聽消息，請使用持久訂閱者使消息傳遞系統保存在訂閱者斷開連接時發布的消息。
冪等接收器 ：為了允許消息接收者處理重復消息，將接收器設計為冪等接收器，即可以安全地多次接收相同消息的接收器。
Service Activator ：要創建要通過各種消息傳遞技術和非消息傳遞技術調用的應用程序服務，請設計一個Service Activator，將通道上的消息連接到正在訪問的服務。
消息頻道
消息通道 ：要允許一個應用程序使用消息傳遞與另一個應用程序通信，請使用消息通道連接應用程序，其中一個應用程序將信息寫入通道，另一個應用程序從通道讀取該信息。
點對點信道 ：為了確保呼叫者只有一個接收者將接收文檔或執行呼叫，請在點對點信道上發送消息，這確保只有一個接收者將接收特定消息。
發布 - 訂閱頻道 ：要允許發送者向所有感興趣的接收者廣播事件，請在發布 - 訂閱頻道上發送事件，該頻道將特定事件的副本傳遞給每個接收者。
數據類型通道 ：要允許應用程序發送數據項以使接收器知道如何處理它，請為每種數據類型使用單獨的數據類型通道，以便特定通道上的所有數據具有相同的類型。
無效的消息通道 ：為了使消息接收器能夠正常處理接收無意義的消息，接收方應將不正確的消息移動到無效消息通道，這是一個特殊的通道，用於接收器無法處理的消息。
死信頻道 ：當消息系統確定它不能或不應該傳遞消息時，它可以選擇將消息移動到死信頻道。
保證傳遞 ：為了確保發送者能夠傳遞消息，即使消息傳遞系統出現故障，也可以使用Guaranteed Delivery使消息保持持久性，以便即使消息傳遞系統崩潰也不會丟失消息。
通道適配器 ：要將應用程序連接到消息傳遞系統以便它可以發送和接收消息，請使用可以訪問應用程序的API或數據的通道適配器，並根據此數據在通道上發布消息，同樣可以接收消息和調用應用程序內的功能。
消息傳遞橋 ：為了允許多個消息傳遞系統的連接，以便其他消息可用的消息也可以在其他消息傳遞系統上使用，請使用消息傳遞橋（消息傳遞系統之間的連接）在系統之間復制消息。
消息總線 ：一種允許單獨的應用程序協同工作的體系結構，但是以分離的方式使應用程序可以輕松添加或刪除而不影響其他應用程序，是一種消息總線，它連接這些應用程序之間的中間件並使它們能夠一起使用消息。
系統管理（監控）
控制總線 ：要有效管理分布在多個平台和廣泛地理區域的消息傳遞系統，請使用控制總線來管理企業集成系統。 控制總線使用與應用程序數據相同的消息傳遞機制，但使用單獨的通道傳輸與消息流中涉及的組件的管理相關的數據。
繞行 ：要通過中間步驟路由消息以執行驗證，測試或調試功能，使用通過控制總線控制的基於上下文的路由器構建Detour。 在一種狀態下，路由器通過附加步驟路由傳入消息，而在另一種狀態下，路由器將消息直接路由到目標信道。
Wire Tap ：要檢查在點對點通道上傳輸的消息，請將簡單的收件人列表插入到將每個傳入消息發布到主通道和輔助通道的通道中。
消息歷史記錄 ：要在松散耦合的系統中有效地分析和調試消息流，請將消息歷史記錄附加到消息中。 消息歷史記錄是消息自發起以來所經過的所有應用程序的列表。
消息存儲 ：要在不干擾消息傳遞系統的松散耦合和瞬態特性的情況下報告消息信息，請使用消息存儲來捕獲有關中央位置中每條消息的信息。
智能代理 ：要跟蹤將請求消息發布到請求者指定的返回地址的服務上的消息，請使用智能代理存儲原始請求者提供的返回地址，並將其替換為智能代理的地址。 當服務發送回復消息時，將其路由到原始的返回地址。
測試消息 ：要防止組件因內部故障而混淆傳出消息，請使用測試消息來確保消息處理組件的運行狀況。
設計模式
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.