I’m trying to find the best configuration for our services with a new security requirement to move some of our services into a segregated domain.
Currently our endpoints are using a single NServiceBus SQL server transport database with persistence databases of their own. We need to transport messages between the domains which are un-trusted and with MSDTC disabled. This has forced us to modify our transaction scope to (Sends atomic with Receive), after reading the implications of this, I was hoping for some advice on how to change our topology to ensure the same atomicity and consistency guarantees as we have currently, if possible at all?.
You can separate the transport from the persistence. By doing this you can have all queue related tables in a separate database and have each domain store its data in its own database. You could sort of see the queues on top of domain A and B in your diagram.
Within the transport database you can control access to have specific INSERT/DELETE/SELECT permissions per specific user.
Would that work for you?
It is unclear to me if these domains would store that data in different physical instances as in different servers, or different database catalogs on the same database instance/server.
We already have the persistence database and server separate for each endpoint. With a shared transport database, however this does not work across the domain with TransportTransactionMode.TransactionScope as we have no DTC across the domain. We have since change this to TransportTransactionMode.SendsAtomicWithReceive to get our endpoints working but this has implications on our atomicity and consistency guarantees.
That is correct, you are vulnerable to more-than-once processing when not using distributed transactions. You can enable our outbox feature to get similar transactional semantics as distibuted transactions:
I looked into the outbox feature, however I’ve simplified our topology for brevity, endpoint A and B are actually a small collection of endpoints each. I was wondering if enabling this feature on all those endpoints is appropriate or if we should use separated NServiceBus transport databases in each domains with endpoints using full transport transaction scopes and instance mapping. With outbox only on those endpoints which transport between the domains. Its difficult to understand the implications as we’re applying this to a rather large existing application with new security requirements.
You cannot really mix MSDTC and outbox as using outbox can result in sending mutliple copies of the same message. These will not be de-duplicated on endpoints that do not have outbox enabled.
For that reason it is advisable to enable outbox on all endpoints or have idempotent messages processing that can deal with more-than-once processing and especially and resulting messages that would be send to be identical.
More advanced transport options are available for example the usage of the Gateway or the community provided Router package
The router is a community package that replaces the community provide wormhole and bridge packages. These provide advanced routing capabilities and even multi transport support. It is currently lacking some documentation but please see the following links for configuration details:
