Choosing a transport, i.e. which mechanism will actually transfer your messages, has a great impact on the characteristics you can expect from your service bus. In Rebus' current state, the MSMQ, Azure Service Bus, and the RabbitMQ transports can be considered fairly mature, as there are people using these two for critical stuff out there.
Using the Configuration API, you may configure your Rebus to use the MSMQ transport like so:
Configure.With(...) .Transport(t => t.UseMsmq("inputQueueName")) // etc
which will make Rebus send and receive messages using MSMQ, using the queue "inputQueueName" as its input queue (i.e. this particular endpoint will start receiving messages from the queue named "inputQueueName", which will automatically be created).
No matter how you specify the queue names, the queues will automatically be created if they do not already exist. They will automatically be made transactional, and the owner will be the current user, and local administrators will be granted full rights to the queues.
A transport implementation for RabbitMQ is also available, so if you include the
Rebus.RabbitMQ package, you can go
Configure.With(...) .Transport(t => t.UseRabbitMq("amqp://localhost", "inputQueueName")) // etc
as well. As RabbitMQ is a totally different beast compared to MSMQ, there's some other really interesting options available for the RabbitMQ transport as well. Please check out the RabbitMQ transport for more information.
Azure Service Bus transport
A transport implementation has been made that uses Azure Service Bus to move messages around. The Azure Service Bus transport comes in two flavors:
- one that fully utilizes Azure Service Bus' capabilities, i.e. uses topics and subscriptions for pub/sub messaging - requires Azure Service Bus at least on the Standard tier
- one that only uses Azure Service Bus' queues - works with Azure Service Bus Basic tier
You can configure Rebus to use it by going
Configure.With(...) .Transport(t => t.UseAzureServiceBus(connectionString, "my_input_queue") .(...) // etc
including several other
UseAzureServiceBus... variants. If you're curious, read more about the Azure Service Bus transport.
If you're worried that someone might eavesdrop and read the messages that your applications are sending and receiving, you can enable encryption as a decorator on whichever transport you've chosen. It can be done like this:
Configure.With(...) .Transport(t => (...)) .Options(t => t.EnableEncryption("someKey")) // etc
The key can be generated with the
RijndaelManaged class, or you can leave the generation to Rebus by trying to start the bus without a valid key (i.e. use
null or some other gibberish).
The encryption relies on the same key being configured in all Rebus apps that should be able to communicate.
A transports implementation exists for Azure Queues as well, but it's to be considered very immature! If the Azure Queues transport divorces you from your wife, eats your sandwich, pisses in your coffee, and just generally ruins your life, don't say I didn't warn you!