Может ли конечная точка NServiceBus подписаться на несколько издателей одного и того же сообщения?

Я разрабатываю систему для поддержки получения информации о состоянии от различных типов оборудования. Каждая часть оборудования передает одну и ту же информацию о состоянии (широта, долгота), но каждый тип оборудования использует уникальный протокол для передачи этой информации. По этой причине у меня есть несколько служб, по одной для каждого типа устройства, которые прослушивают и анализируют протокол этого устройства. Я хотел бы, чтобы для каждого из этих сервисов публиковалась информация о состоянии с помощью общего сообщение: 

public interface IPositionMessage : IMessage
{
   string UnitName { get; set; }
   double Latitude { get; set; }
   double Longitude { get; set; }
}
У меня не было проблем с настройкой моей первой службы, но теперь, когда я настраиваю свою вторую службу, я обнаруживаю, что мои подписчики не могут подписаться на одно и то же сообщение от нескольких издателей.

В аналогичном вопросе в группе NServiceBus yahoo рекомендуется преобразовать общее сообщение в команду и использовать шину.Отправить, а не автобус.Публиковать. Я не чувствую, что это имеет смысл в этом сценарии, так как то, что действительно происходит, - это событие (подразделение уже прибыло на позицию и сообщает о новой позиции). Если бы я преобразовал это в команду, мне нужно было бы заранее знать всех потенциальных подписчиков на это событие, чего я не делаю. другим возможным решением было бы создать агрегацию/повторный издатель, который будет шиной каждой службы.Отправить, а затем сообщение будет переиздано от одного издателя. Это кажется ненужным узким местом.

Существует ли какой-либо метод, позволяющий подписчикам подписаться на одно и то же сообщение от нескольких издателей?

2 7
c# publish-subscribe

2 ответа:

Это одна из тех вещей SOA "яма успеха", которые Udi пытается сделать очень трудными для вас, чтобы избежать.

Основная двойственность такова:

    Команды должны отправляться многими клиентами и приниматься одним авторитетным источником. События должны публиковаться одним авторитетным источником и приниматься многими клиентами.
Но этот единственный авторитетный источник является логическим авторитетным источником. Важным моментом является то, что если я заинтересован в все данные IPositionMessage, должна быть только одна логическая точка (queuename@servername), куда я отправляю свои запросы на подписку. Это не означает, что несколько физических процессоров в пределах одного логического сервиса не могут публиковать один и тот же тип событий, пока то, что они публикуют, является авторитетным. Ключ в том, что все ваши физические процессоры должны совместно использовать одно и то же хранилище подписки. На самом деле может потребоваться, чтобы одна физическая конечная точка обрабатывала только запросы на подписку и не выполняла их. обработка вообще. Он просто получает запросы на подписку (QueueX@ServerY заинтересован в IPositionMessage) и обновляет хранилище подписки.

Затем каждый процессор, привязанный к одному и тому же хранилищу подписок, переходит к публикации IPositionMessage и обнаруживает, что QueueX@ServerY заинтересован, и отправляет копию события в это место.

Это будет немного трудно проглотить в среде разработки с NServiceBus.Lite профиль работает, потому что подписка хранения находится в памяти по умолчанию, поэтому очевидно, что он не будет совместно использоваться и не будет работать правильно, так что будьте готовы к этому.

12

Хотя можно подписаться на несколько издателей (это можно настроить в <unicastBusConifg />), я согласен с группой пользователей в том, что это должно стать логической отправкой, а не публикацией.

Я не совсем понимаю, почему я так думаю.
1