NServiceBus - 兩個發佈者，一個訂閱者，相同的消息接口

我很困惑UnicastBusConfig，MsmqTransportConfig，和MSMQ隊列之間的關係。的文檔狀態：NServiceBus - 兩個發佈者，一個訂閱者，相同的消息接口

「在用戶的總線訂閱發佈者的方法是將消息發送到已在其部被配置的隊列」

我是在認爲每個校正訂戶必須包含 MessageEndpointMapping，才能返回到可能發佈訂閱服務器處理的消息的每個發佈服務器的端點（或隊列）？

如果是這種情況，那麼如何爲同一消息類型配置多個 MessageEndpointMapping？你不能有重複的值。

例如，給定MyAssembly.IDoStuff，假設我有兩個出版社出版這 IDoStuff和一個訂閱者：

<UnicastBusConfig> 
    <MessageEndpointMappings> 
     <add Messages="MyAssembly" Endpoint="Publisher1" /> 
     <add Messages="MyAssembly" Endpoint="Publisher2" /> <-- runtime exception 
    </MessageEndpointMappings> 
</UnicastBusConfig>

的商業案例，這是簡單的。說訂閱者是一個FTP過程，它將文件和FTP發送出去。很明顯，你想要從整個企業的許多地方使用該功能。因此，有一個處理ISendFile的FTP訂閱服務器，然後讓每個需要FTP功能的發佈服務器進程發佈ISendFile消息是很有意義的。這是我遇到的確切情況 - 我沒有看到解決方法。

請指教 - 謝謝！

來源

2012-08-04 znelson

正如Kijana在nsb列表中提到的，pub pub的核心假設之一是發佈者不應該瞭解其訂閱者。甚至可能有0個用戶，在你的例子中，這將無法執行ftp傳輸。這表示你應該做一個總線。發送（SendStuffUsingFtpCommand）代替。 NServiceBus試圖通過只允許一個邏輯發佈者爲給定的消息類型來引導你。從技術上講，這意味着只有您注意到的每個消息類型的消息映射條目。

來源

2012-08-04 20:41:32

bus.Send 完成工作，但感覺不對。它解決了多個發佈者針對一個訂閱者的問題，但是當您需要多個訂閱者時會發生什麼？然後你必須恢復到巴士。發佈並使用經銷商。我想，這很有道理。但發送與發佈構造感覺太複雜了。 – znelson 2012-08-06 21:54:20

我相信你在考慮你有多個物理髮布者的場景，以獲得相同的邏輯消息。想想舊的+新的CRM系統發佈相同的CustomerStatusUpdated事件。這是受支持的，只是共享端點之間的訂閱存儲，並讓您將訂閱者分配給其中一個（可能是新的CRM） – 2012-08-07 19:58:21

NServiceBus - 兩個發佈者，一個訂閱者，相同的消息接口

回答

相關問題