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

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

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


nservicebus rhino-commons
person Lars-Erik    schedule 30.08.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Ларс-Эрик,

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

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

person Udi Dahan    schedule 31.08.2010
comment
Я добавил комментарий в качестве ответа из-за ограниченного количества символов в комментарии. Увидеть ниже.. - person Lars-Erik; 02.09.2010
comment
Хорошо - тогда это просто так: NServiceBus.Configure.With (/ * все типы из сборок NserviceBus * /, / * ваш конкретный обработчик и типы саги, которые вы хотите загрузить * /); - person Udi Dahan; 06.09.2010

arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

(Мне пришлось ответить на свой вопрос, потому что stackoverflow имеет ограниченное количество символов в комментарии)

person Lars-Erik    schedule 01.09.2010