Windows服務總線點對點通信以減少廣播

我使用Windows Service Bus 1.0在不同進程之間進行通信，每個上下文事件流作爲主題存在於總線上。Windows服務總線點對點通信以減少廣播

使用服務總線來鏈接有界上下文之間的事件我需要一種方法來同步事件（或者換言之，請求重放過去的事件），當有界的上下文恢復在線但想要限制潛在的消息氾濫只返回到請求它的端點，至少如果這是通過使用現有服務總線功能可以輕鬆完成的事情。

因此，給定一個假想的ContextC發送一條消息來請求來自ContextA和ContextB的所有先前事件，是否有任何方式讓這些重播消息只發送給ContextC？

將上下文映射爲主題所有者（或換句話說，單個總線用戶到總線主題）的最佳方式是什麼？以便於上面的單播重放？

2013-03-17 g18c

您是否試圖實現可以在本地或Windows Azure平等部署的解決方案？ – 2013-03-17 06:58:20

對於我來說，由於其餘的問題都假設採用CQRS架構的事件，所以術語是錯誤的。上下文不應該將消息「發送」給對方，而是相互傾聽。你能談談你的更高層次的需求嗎？爲什麼下游消費者需要擔心所有這些東西？你是否這樣做是爲了促進事件的重放，以便在依賴環境中的讀取模型中「吹走並重建」狀態？ – 2013-03-17 07:05:29

魯本感謝您的持續幫助，這是值得讚賞的。事件的發送和回放僅適用於恢復已聯機並且想要同步以前事件的有界上下文 - 我同意您的意見，因爲在我們通常只聽的正常操作過程中應發生的事情是相同的 – g18c 2013-03-17 18:47:16

在我的世界裏，我保持鬆散耦合的東西 - 每個環境將東西放到一個主題上，任何需要東西訂閱的人。

每個SB訂閱可以使用基於屬性的Service Bus過濾設施（例如，您可以通過在消息上添加屬性來標記事件，然後在訂閱上具有過濾條件，這意味着只有白名單事件類才適用於每個事件消費者）。

這加上你已經按主題分隔的事實。

訂閱和話題允許您在不丟失任何信息的情況下處理事件，或讓發佈商回過頭來擔心或追逐訂閱者。

你還提到你在其他問題中將它綁定到事件存儲 - 在這種情況下，你的消息有可能需要按順序使用。如果是這樣的話，你需要在你的消息上加上會話ID。

我可以推測爲什麼你想這個訂戶驅動relivery，但現在不會。在任何人回答使用服務總線最佳實現方式之前，您需要首先解釋/驗證該概念和要求（通過提出解釋您更高級別目標的問題）。

來源

2013-03-17 07:10:23

Windows服務總線點對點通信以減少廣播

回答

相關問題