-
Notifications
You must be signed in to change notification settings - Fork 84
Getting Started With Nimbus
The first step is to get Nimbus from NuGet
Install-Package Nimbus
If you don't want to use an IoC container (but we think you probably should) you can build and configure the bus like this.
//TODO: Set up your own connection string in app.config
var connectionString = ConfigurationManager.AppSettings["AzureConnectionString"];
// Configure a Transport
var transport = new AzureServiceBusTransport().WithConnectionString(connectionString);
// This is how you tell Nimbus where to find all your message types and handlers.
var typeProvider = new AssemblyScanningTypeProvider(Assembly.GetExecutingAssembly());
var bus = new BusBuilder().Configure()
.WithNames("MyApplication", Environment.MachineName)
.WithTransport(transport)
.WithTypesFrom(typeProvider)
.WithDefaultTimeout(TimeSpan.FromSeconds(10))
.Build();
bus.Start();
return bus;
So that's a bunch of stuff there, let's break it down a bit.
var connectionString = ConfigurationManager.AppSettings["AzureConnectionString"];
This is your connection string, the address of your Azure Service Bus namespace. You can get this from the Azure console. You'll need a connection string with Manage permissions. It's going to look something like this :
Endpoint=sb://[your namespace].servicebus.windows.net;SharedSecretIssuer=owner;SharedSecretValue=[your secret]
var typeProvider = new AssemblyScanningTypeProvider(Assembly.GetExecutingAssembly());
Next up is your type provider. This is what Nimbus uses to find all the messages you want to put on the bus and handle from the bus, as well as all your handlers. The default AssemblyScanningTypeProvider is what you most likely what you want here unless you want to do something funky. It will scan all the assemblies you pass in to it for any Events, Commands, Requests and their related Handlers so we can register them. The argument here is a param array of Assembles so you can have your messages and handlers in multiple assemblies (you will want this in any real world app) and pass them in as arguments. Handlers are instantiated through a basic Activator.CreateInstance call. This means your handlers can't have any constructor dependencies (if you don't know why you'd need an IoC container this is probably fine).
var bus = new BusBuilder().Configure()
.WithNames("MyApplication", Environment.MachineName)
.WithConnectionString(connectionString)
.WithTypesFrom(typeProvider)
.WithDefaultTimeout(TimeSpan.FromSeconds(10))
.Build();
bus.Start();
Alright so this is the big one. We have a fluent interface for the configuration and instantiation of the bus. Most of the lines here are going to make sense now. WithConnectionString passes in the addressing of our Azure Namespace, we're passing in our Type Provider as well as our Handler Factory and the Default Timeout should be self explanatory.
The only thing that needs explaining here is the WithNames line.
In order to address the messages properly we have a naming convention based on the application name, and for cases where we have multiple instances of the same app we also use a unique name, usually the machine name. So we're passing those params into the .WithNames arguments
To stop the bus cleanly, simply run bus.Stop(). Or, if using Autofac within an ASP.Net application:
protected void Application_End()
{
var bus = _container.Resolve<IBus>() as Bus;
if (bus != null) bus.Stop().Wait();
}
Azure Service Bus
Windows Service Bus
Redis
In Process
Configuring Nimbus With Autofac
Configuring Nimbus With Windsor
Configuring Nimbus With Ninject
Sending a Command on the Bus
Publishing an Event on the Bus
Request Response
Multicast Request Response
Multicast Request Response - take First
Large Message Support