Несколько конечных точек, NServicebus против Rhino Bus
Я довольно новичок в NServiceBus и Rhino Bus - и мне интересно, решат ли мою проблему несколько конечных точек. Я хочу следующее: 1. Иметь конечную точку для сообщений Invoicing, которая одновременно запускает только 1 поток. 2. Иметь другую конечную точку для сообщений EDI (~ чтение входящих файлов для электронного обмена данными), здесь также только 1 поток. 3. Все остальные сообщения должны отправляться в конечную точку "по умолчанию" с несколькими потоками. 4. Клиенты не должны знать о конечных точках. Они должны просто публиковаться на "шлюзе" (unicastbus?) 5. Я не хочу регистрировать обработчики сообщений по соглашению. Все регистрации должны быть сделаны явно в коде.
Можно ли это сделать в nservice bus и rhino bus? Кто-нибудь может привести примеры?
2 ответа
Ларс-Эрик,
В NServiceBus вам необходимо настроить клиенты для отправки соответствующих сообщений в соответствующие конечные точки. "Шина" не является центральной физической конечной точкой, с которой все разговаривают (иначе это был бы брокер).
Что касается регистрации обработчиков сообщений, NServiceBus делает это автоматически. Можете ли вы объяснить больше, почему вы должны зарегистрировать их вручную? При этом, если вы хотите зарегистрировать их самостоятельно, вы можете - перед вызовом NServiceBus.Configure.With() и затем явно передать сборки или типы, которые вы хотите сканировать NServiceBus (по крайней мере, передать сборки NServiceBus поскольку есть обработчики сообщений и другие вещи, которые должны быть загружены для работы NServiceBus).
Спасибо, что нашли время ответить. Я постараюсь объяснить, почему я хочу явную регистрацию:
1. Наше программное обеспечение имеет набор стандартных MessageHandlers. Часто нам нужно сделать "поверхностную" настройку для клиента. В сервисной шине эта настройка фактически означала бы замену MessageHandlers по умолчанию на настроенную. Это делается в загрузчике на стороне сервера. Если NSB просто сканирует сборки на предмет соответствующего обработчика, существует риск, что два обработчика будут зарегистрированы для одного и того же сообщения.
2. Я хочу на 100 % быть уверенным во время компиляции, что загрузчик действительно регистрирует правильные обработчики ответов. Я добьюсь этого с помощью регулярных юнит-тестов - муравей полагается на фальшивый экземпляр автобуса.
3. Нам просто не нравится программирование в нашей компании. Конвенциональное программирование усложняет понимание, особенно для новых разработчиков. Это немного похоже на "волшебство происходит здесь".
Вы, возможно, не согласны со мной по поводу явного и условного программирования. Но в нашей компании традиционное программирование - это антишаблон.
О, конечные точки. Я получаю это сейчас. Наличие web.config для конечных точек (или в коде) подойдет нам идеально - потому что все запросы от клиентов к серверу в любом случае направляются на один и тот же "wcf-шлюз".
(Между прочим: я наблюдал за вами на NDC2009, "Создание шаблонов завершено", я думаю, это называлось. Это действительно было для меня откровением - особенно в части о явном определении ролей.)
(Я должен был ответить на свой вопрос, потому что в комментарии в стеке есть ограниченное количество символов)