Представьте себе следующую настройку: клиент Silverlight туннелирует сериализованную команду по сети, используя службу WCF, которая, в свою очередь, десериализует команду и отправляет ее с помощью NServiceBus на общий хост, который отвечает за обработку команды. Служба WCF после отправки команды зарегистрировала обратный вызов для вызова. Общий хост проверяет команду и «возвращает» код ошибки (0 == успех или> 0 == сбой).
Примечание. Служба WCF моделируется после встроенной службы WCF. Разница в том, что эта служба WCF получает «универсальную команду» (не IMessage), десериализует ее в реальную команду (которая реализует IMessage) и, следовательно, отправляет десериализованную команду на шину.
При возникновении непредвиденных исключений команда попадает (после определенного количества повторных попыток) в очередь в очередь ошибок. На этом этапе инициирующий сервис WCF бездействует, не подозревая о том, что только что произошло. В более поздний момент клиент Silverlight будет использовать тайм-аут в соответствии с конфигурацией прокси-сервера клиента WCF.
Вещи, которые размыты в моей голове:
- NServiceBus обрабатывает этот сценарий каким-либо образом? Когда генерируется исключение тайм-аута (если вообще)? Или это что-то эксклюзивное для саг?
- Предполагая, что я использую [OperationContract (AsyncPattern = true)], есть ли какие-либо настройки тайм-аута, связанные с WCF, которые убьют операцию службы? Или метод EndXXX будет как-то вызываться? Или он будет сидеть вечно, протекая, ожидая чего-то, что никогда не придет?
Способы продолжить:
- повторно использовать существующие механизмы тайм-аута, при условии, что что-то не происходит.
- создать собственный механизм тайм-аута между службой wcf и nservicebus.
- уведомить службу wcf, как только команда попадет в очередь ошибок.
- создать свой собственный механизм асинхронных уведомлений, используя полнофункциональный обработчик сообщений обратного вызова на уровне службы WCF.
Вещи, которые я сделал:
- запустите пример, предоставленный NServiceBus.
- поднял счастливый случай.
Приветствуются любые инструкции о том, как поступить, будь то запись в блоге, записи в списке рассылки, ...
Некоторые мотивы выбора моего текущего подхода
- Я пытаюсь использовать некоторые из преимуществ масштабируемости (использование дистрибьютора на более позднем этапе) NServiceBus.
- Я не хочу размещать gazillion сервисов WCF (по одному для каждой команды), поэтому я приготовил сервис WCF, похожий на шину.
- Несмотря на то, что это стиль запроса / ответа, меня больше всего интересует изящная обработка ответа на команду, не поступающего.