Skip to content


Mogens Heller Grabe edited this page Oct 28, 2015 · 12 revisions

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.

Configuring it

MSMQ transport

Using the Configuration API, you may configure your Rebus to use the MSMQ transport like so:

    .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.

RabbitMQ transport

A transport implementation for RabbitMQ is also available, so if you include the Rebus.RabbitMQ package, you can go

    .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:

  1. 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
  2. one that only uses Azure Service Bus' queues - works with Azure Service Bus Basic tier

You can configure Rebus to use it by going

    .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.

Encrypted 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:

    .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.

Other transports

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!

Clone this wiki locally
You can’t perform that action at this time.