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

Question

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

Это можно сделать в автобусе nservice и носороге? Может ли кто-нибудь привести примеры?

Answer 1

Lars-Erik,

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

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

Answer 2

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

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

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

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

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

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

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

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