One NServiceBus.Host for one EndPoint, what is the recommended approach

Question

I'm trying to understand NServiceBus given the online documentation. What I can't wrap my head around is the overall recommended setup of the infrastructure. Our app is supposed to be able to run both a single machine and across multiple (logically different) sites (n stores-1 headquarter). As for NServiceBus (I am using v5 through NuGet), I don't fully understand the notion of a host and endpoints.

Lets say we have 15 services (order service, item service, etc.).

1. Do I need 15 clients (15 class library projects with code sending messages over the bus), and 15 servers (one or more receiving messages handler classes that handle service specific messages/commands)? So 30 total.

2. Should each service use its own separate MSMQ?

3. For those 15 "server" projects, in a production environment I need to install the NServiceBus.Host 15 times (hence creating 15 Windows service instances). During debugging in VS, the NSerivceBus.Host.exe will be started when you start debugging.

So you effectively "host" only one endpoint for each host/server project. Or can I have a single host and 15 endpoints inside of it?

You can tell I am new to this ESB pattern, so thanks for your input.

Answer 1

1. You don't need 15 class libraries. NServiceBus can router the messages based on their namespace/type. eg: all namespace messages of "Message.Orders" can be routed to "Orders" queue.

2. in production possibility.. but it really depends on the volume of messages and the logical grouping/partitioning. in development, I would have one queue for all messages.

3. again, this is a deployment issue that is dictated by logical partitioning. usually you would have this scripted to handle the installation/un-installation of these services. I have mine in powershell script.

NServiceBus is really flexible on how and when you partition your messages. it is usually done at the configuration level in UAT or Production and outside the development lifecycle. keep in mind, one NServiceBus host == 1 MSMQ

I started with one service first, then start partitioning based on volume/priority messages.

Also, the only reason you would breakdown the messages to 15 classes, if you want to expose these assemblies to external solutions without exposing the other message types.

Answer 2

A Service (capital s :-) as in SOA Service definitions) is a logical grouping of business capabilities

An Endpoint is a physical process, for example, in your ECommerce Endpoint (web site) you can have handlers (assemblies) form many Services deployed in your host process.

You can start off with a small number of endpoints deployed on a small number of machines, however, as you scale you will find you will want to extract handlers to their own endpoint as they process important data and you don't want "un-important" messages in the queue to delay the "important" messages form being processed.

As for Queues, each endpoint has it's own private queue.

When you get to high scale you might end up with an Endpoint per handler scenario, but that might be a while before you need to do so, however, i would go with one handler = one assembly from day one and make sure no inter dependencies are introduced between these assemblies...

Take a look at Udi's Blog

Dose that make sense?