Несколько конечных точек, NServicebus против Rhino Bus

Question

Я довольно новичок в NServiceBus и Rhino Bus - и мне интересно, решат ли мою проблему несколько конечных точек.Я хочу следующее: 1. Иметь конечную точку для сообщений выставления счетов , которая одновременно выполняет только 1 поток 2. Иметь другую конечную точку для сообщений EDI (~ чтение входящих файлов для электронных данных)interhage), только 1 thread здесь тоже.3. Все остальные сообщения должны отправляться в конечную точку «по умолчанию» с несколькими потоками.4. Клиенты не должны знать о конечных точках.Они должны просто публиковаться на «шлюзе» (unicastbus?) 5. Я не хочу регистрировать обработчики сообщений по соглашению.Вся регистрация должна быть сделана явно в коде.

Возможно ли это сделать в nservice bus и rhino bus?Кто-нибудь может привести примеры?

Answer 1

Ларс-Эрик,

В NServiceBus вам необходимо настроить клиентов на отправку соответствующих сообщений в соответствующие конечные точки."Шина" - это , а не центральная физическая конечная точка, с которой все общаются (в противном случае это был бы брокер).

В отношении регистрации обработчиков сообщений NServiceBus делает это автоматически.Можете ли вы объяснить больше, почему вы должны зарегистрировать их вручную?При этом, если вы хотите зарегистрировать их самостоятельно, вы можете - перед вызовом NServiceBus.Configure.With () и затем явно передать сборки или типы, которые вы хотите, чтобы NServiceBus сканировал (по крайней мере, передать сборки NServiceBusпоскольку есть обработчики сообщений и другие вещи, которые должны быть загружены для работы NServiceBus).

Answer 2

Спасибо, что нашли время ответить. Я постараюсь объяснить, почему я хочу явную регистрацию:

1. Наше программное обеспечение имеет набор стандартных MessageHandlers. Часто нам нужно выполнить «поверхностную» настройку для клиента. В сервисной шине эта настройка фактически означала бы замену MessageHandlers по умолчанию на настроенную. Это делается в загрузчике на стороне сервера. Если NSB просто сканирует сборки на предмет соответствующего обработчика, существует риск, что два обработчика будут зарегистрированы для одного и того же сообщения.

2. Я хочу на 100% быть уверенным во время компиляции, что загрузчик действительно регистрирует правильные обработчики ответов. Я добьюсь этого с помощью регулярных юнит-тестов - муравей полагается на фальшивый экземпляр шины.

3. Нам просто не нравится программирование в нашей компании. Конвенциональное программирование усложняет понимание, особенно для новых разработчиков. Это немного походит на "волшебство случается здесь".

Вы, возможно, не согласны со мной по поводу явного и условного программирования. Но в нашей компании традиционное программирование - это антишаблон.

О, конечные точки. Я получаю это сейчас. Наличие web.config для конечных точек (или в коде) подойдет нам идеально, потому что все запросы от клиентов к серверу в любом случае направляются на один и тот же "wcf-шлюз".

(Между прочим: я наблюдал за вами на NDC2009, «Создание шаблонов завершено», я думаю, это называлось. Это действительно открыло мне глаза - особенно часть о том, как сделать роли явными.)

(Я должен был ответить на свой вопрос, потому что в комментарии в стеке указано ограниченное количество символов)