#nservicebus #publish-subscribe
#nservicebus #опубликовать-подписаться
Вопрос:
У меня есть требование создать подписчика NSB, который будет подписываться на сообщения, публикуемые службой, которая уже запущена. Этот сервис был создан с помощью сборки messages, содержащей реализации NSB iMessage, на которые я хочу подписаться. Итак, чтобы создать моего подписчика, мне нужна жесткая зависимость от этой сборки.
Когда мой подписчик запускается, он отправляет некоторые сообщения в очередь ввода издателя, в результате чего издатель записывает мои подписки в базу данных. Одна из моих подписок выглядит следующим образом:
MyNamespace.MyMessageType, MyNamespace, Version=1.0.0.0, Culture=neutral, PublicKeyToken=MyPublicKeyToken
К сожалению, издатель публикует сообщения из сборки, у которой нет строгого имени. Таким образом, при публикации процесс оценки подписки не может успешно оценить мою подписку, потому что токен открытого ключа публикуемого сообщения (значение = null) не соответствует моей подписке.
Мой вопрос: могу ли я не подписываться на сообщения только по типу и версии? Еще лучше — могу ли я не подписываться на сообщения на основе какого-либо внешнего контракта (например, XSD) и полностью разорвать эту зависимость?
Заранее большое спасибо.
ОБНОВЛЕНИЕ: Документы NSB намекают на что-то подобное здесь:
Комментарии:
1. Есть ли веское экономическое обоснование, почему сборка сообщений должна иметь строгое имя?
2. Ну, это не бизнес-пример, но в целом безопаснее переходить в производственную среду со строгим именованным кодом. Если бы эта зависимость была сторонней (это не так), тогда у меня была бы реальная проблема, потому что я бы понятия не имел, получена ли сборка из надежного источника или нет. Хотя я понимаю, о чем вы говорите. На самом деле это меня не блокирует, потому что я попросил команду, разрабатывающую сообщения, просто подписать сборку сообщений. Но мой пост все еще действителен. При использовании NSB pubsub у вас всегда будет жесткая зависимость от вашего издателя, которой не существует, если вы просто используете Bus.Send().
Ответ №1:
Для обычных создаваемых вами сообщений вы можете использовать инструмент XsdGenerator в каталоге tools NSB, чтобы сгенерировать схему, которую вы можете передавать другим конечным точкам. Вы захотите использовать этот инструмент вместо инструмента .NET Framework, поскольку он не поддерживает интерфейсы. Оттуда вы можете использовать схему для обработки сообщений.
Для сообщений о подписке, если вы не хотите использовать сборку, вы могли бы указать NSB, чтобы DoNotAutoSubscribe() и подписался вручную (Bus.Subscribe(Type)) передавал тип сообщения, как вы пожелаете. Это может быть не в схеме или какой-либо другой конфигурации.
Комментарии:
1. Спасибо, Адам. Однако это не ответ. Я могу с радостью разорвать двоичные зависимости в решении для обмена сообщениями от точки к точке службы / потребителя, просто сославшись на локальную сборку, определения типов которой допускают чистую десериализацию XML, поступающего по проводам, в данном случае, запустив службу «AsA_Server». Жесткая зависимость создается, когда служба запускает «AsA_Publisher», и подписчик отправляет сообщения о подписке, которые основаны на отражении сборки, на которую ссылается.
2. Если вы не хотите использовать сборку, вы могли бы сказать NSB, чтобы он не выполнял автоматическую подписку () и подписался вручную (Bus.Subscribe(Type)), передавая тип сообщения, как вы пожелаете. Это может быть не в схеме или какой-либо другой конфигурации. Сработает ли это?
3. Привет, Адам. Если вы можете отправить сообщение о подписке, которое действительно для издателя, тогда я не понимаю, почему это не сработает. Это звучит как лучшее решение для полного разрыва зависимости. Пожалуйста, сделайте это правильным ответом stackoverflow, и я поддержу его и отмечу как таковой. Спасибо! TC
4. Однако отправить правильное «действительное» сообщение о подписке может оказаться довольно сложной задачей. Под допустимым в данном случае я подразумеваю, что издатель может успешно выполнить оценку по нему и отправить сообщение в результате оценки. Для этого, конечно, нет встроенной поддержки.
5. Отредактировано, чтобы включить предложение из комментариев.