Multiple endpoints , NServicebus vs Rhino Bus

I am pretty new to both NServiceBus and Rhino Bus - and I am 开发者_运维知识库wondering if multiple endpoints will solve my problem. I want the following: 1. Have an endpoint for Invoicing messages, that runs only 1 thread at the time 2. Have another endpoint for EDI messages (~reading incoming files for electronic data interhage), only 1 thread here too. 3. All other messages should goe to a 'default' endpoint with multiple threads. 4. The clients should not be aware of the endpoints. They should just publish to a 'bus gateway' (unicastbus ?) 5. I do not want to register messaghandlers by convention. All registering must be done explicitly in code.

Is this possible to do in nservice bus and rhino bus ? Can anyone give me examples ?

Lars-Erik,

In NServiceBus, you'd need to configure the clients to send the appropriate messages to the relevant endpoints. The "bus" is not a central physical endpoint that everybody talks to (otherwise it would have been a broker).

With respect to registering message handlers, NServiceBus does this automatically. Can you explain more why you need to register them manually? That being said, if you do want to register them yourself, you can - before calling NServiceBus.Configure.With() and then explicitly pass in the assemblies or types you want NServiceBus to scan (at the very least, pass in the NServiceBus assemblies as there are message handlers and other things that need to be loaded for NServiceBus to work).

Thanks for taking the time to answer. I will try to explain why I want explicit registration:

1. Our software has a set of default MessageHandlers. Often, we need to do "surface" customization for a customer. In a servicebus, this customization would actually mean to replace the default MessageHandlers with a customized one. This is done in the bootstrapper on the serverside. If NSB just scans the assemblys for an appropriate Handler, there is a risk that two Handlers will be registered against the same message.

2. I want to 100 % sure at compile-time that the bootstrapper actually registers the correct Responsehandlers. I will acheive this by regular unit tests - ant relying on a fake instance of the bus.

3. We just dislike programming by convention in our company. Convention based programming makes thing hard to understand, especially for new developers. It's a bit like "magic happens here".

You, might disagree with me about explicit vs. convention based programming. But in our company, conventioned based programming is an anti-pattern.

About, the endpoints. I get it now. Having a web.config for the endpoints (or in code) will suit us perfectly - because all requests from clients to server go to the same "wcf-gateway" anyway.

(By the way: I watched you at NDC2009, "Making patterns complete" I think it was called. It really was an eye opener for me - especially the part about making roles explicit.)

(I had to answer my own question because stackoverflow has a limited number of characters in a comment)