多端点，NServicebus 与 Rhino Bus
我对 NServiceBus 和 Rhino Bus 都很陌生 - 我想知道多个端点是否可以解决我的问题。 我想要以下内容： 1. 有一个用于发票消息的端点，该端点当时仅运行1个线程 2. EDI 消息有另一个端点（~读取电子数据交互的传入文件），这里也只有1 个线程。 3. 所有其他消息应发送至具有多个线程的“默认”端点。 4. 客户端不应该知道端点。他们应该只发布到“总线网关”（unicastbus？） 5. 我不想按照惯例注册消息处理程序。所有注册都必须在代码中显式完成。
这可以在 nservice 总线和 rhino 总线中执行吗？ 谁能给我举个例子吗？
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 ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Lars-Erik，
在 NServiceBus 中，您需要配置客户端以将适当的消息发送到相关端点。 “总线”并不是每个人都可以与之对话的中央物理端点（否则它就是一个代理）。
关于注册消息处理程序，NServiceBus 自动执行此操作。您能详细解释一下为什么需要手动注册它们吗？话虽这么说，如果您确实想自己注册它们，您可以在调用 NServiceBus.Configure.With() 之前，然后显式传入您希望 NServiceBus 扫描的程序集或类型（至少，传入 NServiceBus 程序集）因为 NServiceBus 需要加载消息处理程序和其他东西才能工作）。
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).
感谢您抽出时间来回答。我将尝试解释为什么我想要显式注册：
1. 我们的软件有一组默认的MessageHandler。通常，我们需要为客户进行“表面”定制。在服务总线中，这种定制实际上意味着用定制的 MessageHandler 替换默认的 MessageHandler。这是在服务器端的引导程序中完成的。
如果 NSB 只是扫描程序集以查找适当的处理程序，则存在针对同一消息注册两个处理程序的风险。
2. 我想在编译时 100% 确定引导程序实际上注册了正确的响应处理程序。我将通过常规单元测试来实现这一目标 - ant 依赖于总线的假实例。
3. 我们只是不喜欢公司里按惯例编程。基于约定的编程使事情变得难以理解，尤其是对于新开发人员而言。这有点像“魔法在这里发生”。
您可能不同意我关于显式编程与基于约定的编程的看法。但在我们公司，基于约定的编程是一种反模式。
关于，端点。我现在明白了。为端点（或代码）提供一个 web.config 将非常适合我们 - 因为从客户端到服务器的所有请求无论如何都会发送到同一个“wcf-gateway”。
（顺便说一句：我在 NDC2009 上看过你，“让模式变得完整”，我认为它被称为。这确实让我大开眼界 - 尤其是关于使角色明确的部分。）
（我必须回答我自己的问题，因为 stackoverflow评论中的字符数有限）
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)