Transport

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. Generally, Rebus' transport can be considered mature, although transports based on RDBMSes should be used only in scenarios where you do not expect a super-high load.

Configuring it

MSMQ transport

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.

RabbitMQ transport

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. Your Azure Service Bus instance must be on the "Standard" or "Premium" tiers – Rebus will NOT work with the "Basic" tier, because it doesn't support topics.

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.

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:

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.

All transports

Here's the full list of supported transports (with links to their corresponding NuGet packages):

• In-memory transport (comes with the Rebus core library)
• File system transport (comes with the Rebus core library)
• Azure Service Bus
• Azure Storage Queues
• RabbitMQ
• MSMQ
• SQL Server
• PostgreSQL
• Amazon SQS
• Oracle (Devart)
• Oracle
• MySQL

Please note that the RDBMS transport implementations are only meant for low throughput scenarios.