-
Notifications
You must be signed in to change notification settings - Fork 0
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. In Rebus' current state, the MSMQ and the RabbitMQ transport 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 MSMQ transport like so:
Configure.With(...)
.Transport(t => t.UseMsmqAndGetInputQueueNameFromAppConfig())
// etc
which will make Rebus send and receive messages using MSMQ, getting the names of the input queue and the error queue from the Rebus configuration section of your app.config/web.config. The Rebus configuration section might look like this - first, the <configSections>
element:
<configSections>
<section name="rebus" type="Rebus.Configuration.RebusConfigurationSection, Rebus" />
</configSections>
and then the actual <rebus>
element:
<rebus inputQueue="my-service.input" errorQueue="my-service.error" />
This is the preferred way of configuring Rebus with MSMQ, because it gives you the most flexible way of specifying these very infrastructurey things. You can, however, if you want, specify the queue names directly in the code like this:
Configure.With(...)
.Transport(t => t.UseMsmq("my-service.input", "my-service.error"))
// etc
which will make Rebus send and receive messages using MSMQ, receiving messages from the my-service.input
queue, and using my-service.error
as the error queue.
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 being developed and tested at the moment, so if you include the Rebus.RabbitMQ
package, you can go
Configure.With(...)
.Transport(t => t.UseRabbitMqAndGetInputQueueNameFromAppConfig("amqp://localhost))
// 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.
A transport implementation has been made that uses Azure Service Bus to move messages around. It will automatically create a topic called Rebus
and create subscriptions within that topic - one for each logical input queue.
You can configure Rebus to use it by going
Configure.With(...)
.Transport(t => t.UseAzureServiceBus(connectionString, "my_input_queue", "error")
.(...)
// 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 the preferred way by configuring the shared secret in XML:
Configure.With(...)
.Transport(t => (...))
.Decorators(t => t.EncryptMessageBodies())
// etc
accompanied by something like this (the key can be generated with the RijndaelManaged
class, or you can leave the generation to Rebus by trying to start the bus without it):
<rebus inputQueue="my-service.input" errorQueue="my-service.error">
<rijndael key="oA/ZUnFsR9w1qEatOByBSXc4woCuTxmR99tAuQ56Qko="/>
</rebus>
or, if you prefer, you can specify everything in code like this:
Configure.With(...)
.Transport(t => (...))
.Decorators(t => t.EncryptMessageBodies(keyBase64))
// etc
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!