How to perform message queuing and processing in AWS using NServiceBus

Question

I am creating a new ASP MVC ordering application on Amazon Cloud (AWS) with a persistence level in my on-premises data center. I will use the CQRS pattern. The goal of the project is high availability with Queue (s) to store and forward records (commands / events) that can be collected and processed asynchronously in my local data center. Then, if the WAN or my on-premises data center fails, my cloud-based MVC application can still take orders and simply queue them until processing resumes.

My first thought was to use AWS SQS for the queue and create my own consumer / dispatcher / queue processor in my own C # application to handle incoming messages / events.

MVC (@Amazon) -> Event / POCO -> SQS -> QueueReader (@my datacenter) -> DB

Then I found NServiceBus. NSB seems to handle a lot of details: message processing, retries, error handling, etc. I don't like reinventing the wheel, and NServiceBus seems like a full-featured and mature product that would be ideal for me.

But with further research, it does NOT look like NServiceBus is really intended for use in a WAN in physically separated environments (Cloud to my Datacenter). Google and SO do not actually paint a good picture of using NServiceBus through the WAN, as I need.

Can I do it?

MVC (@Amazon) -> Event / POCO -> NServiceBus via WAN -> NServiceBus Handler -> DB

How can I use NServiceBus through the WAN? Or is there a better solution for queuing and message processing between Amazon and my local data center?

Answer 1

Using SQS as a transport for NServiceBus is an option, however you should be aware of compromise as described here . This was done with the Azure Queue repository, although I am not aware of any large SQS implementations.

Another option is to create a VPN between your data center and AWS VPC . This will allow MSMQ to be directly connected between the AWS servers and your data center, provided that you open the appropriate ports in the appropriate security group. There are some caveats with this approach. Firstly, it concerns the names of the endpoints. NServiceBus version 2.6 and below uses Environment.MachineName as the name of the endpoint for which you will need to configure the correct DNS. I believe that later versions use the IP address of the device. Perhaps more importantly, the VPN makes your systems more connected.

Another way is to use the concept of NServiceBus gateway . This, however, should be a logical business decision. The gateway is very similar to regular transport, but usually has a different business context.

Answer 2

NServiceBus includes a gateway component that handles bridges of physically separated data centers.

http://docs.particular.net/nservicebus/gateway/

It basically moves messaging to the HTTP channel and handles the re-logic and deduplication logic that you usually use with the web service.

If you download the full NServiceBus package (and not just enable it through NuGet), you will see a sample folder and one of these coatings using Gateway, and this is a great way to get started.