Closed KatoStoelen closed 4 years ago
You are right. The connector does not seem to use the non-SQL interface at all. Technically it could use it if you coupled it with MSMQ. Then the incoming interface would be responsible for processing subscribe
messages as MSMQ still uses message-driven pub/sub. But this is a very unlikely scenario as when using MSMQ you would rather use DTC to ensure atomic update and publish.
Currently there is now way to configure Router interfaces to be send-only but I don't see any obstacles in implementing send-only interfaces. That would be a nice addition to the Router.
Thanks for your feedback @SzymonPobiega !
I had a go trying to implement this addition, and got sending of commands to work. For event publishing, however, I stumbled upon this issue: SzymonPobiega/NServiceBus.Raw#10
Figured out that NativePubSubFeature
contained two rules (ForwardSubscribeNativeRule
and ForwardUnsubscribeNativeRule
) not applicable for send-only interfaces. This threw me off, thinking that the subscription manager would be needed. The more correct behavoir, however, would be to make the two rules inapplicable for send-only interfaces. The submitted PR does exactly this.
I have the following setup:
Each service that handles messages has a receive endpoint hosted in a separate process. This is the only place I have message handlers and sagas etc. A pure messaging host of sorts. In addition, each of these services also have a web API and/or a web application. In these web APIs/applications I'm using send-only endpoints to publish events and send commands (to their own receive endpoint).
To ensure that database write operations and message sending will be atomic operations, I plan to use the SQL Server transport with a one-way forward route to Azure Service Bus in my send-only endpoints. Just as demonstrated in NServiceBus.Connector.SqlServer.
The NServiceBus.Connector.SqlServer package works well. However, it seems like all interfaces in NServiceBus.Router are send and receive, requiring queues to exist in all connected transports. This feels a bit unnecessary in the scenario above, where the queues in Azure Service Bus will never be used? It's not a huge pain, but there will potentially be double the amount of queues where only half of them are used.
NServiceBus.Raw contains send-only raw endpoints, but if my perception is correct, there are no way of configuring NServiceBus.Router interfaces to use such raw endpoints?