WCF Pub / Sub с кэшированием подписчиков

Проблема: как предоставить распределенный, масштабируемый и устойчивый к бедствиям паб / суб сервис с WCF.

Подробности:

Обратите внимание, что этот подход рассматривается в дополнение к решениям для обмена сообщениями / промежуточного программного обеспечения, таким как Tibco EMS.

Я смотрел в WCF, в частности, как он может быть использован, чтобы предложить паб / саб. На эту тему эта статья очень хороша:WCF Pub-Sub.

В этой статье автор пытается решить проблему наличия нескольких издателей (как это было бы с уровнем обслуживания, распределенным по нескольким блокам). Проблема заключается в том, что если клиент A регистрируется в издателе A, но издатель B желает опубликовать событие, то издатель B не будет знать о клиенте A. То есть никто не сказал издателю B, что клиент A хочет получать уведомления о событиях. Автор предлагает паб / суб-сервис в качестве решения. Служба pub / sub будет централизованно хранить подписки. Тем не менее, если я хотел сделать службу паб / суб-сервис устойчивой к бедствиям, имея вторичный / двойной паб / суб-сервис, у меня возникла та же проблема.

Итак, я думаю, что есть несколько вариантов решения проблемы:

Храните данные подписчика в распределенном кэше (см. Вопросы:q1 а такжеq2).Храните данные подписчика в базе данных / центральной файловой системе.

Может кто-нибудь придумать какие-нибудь другие решения (т.е. я не пропустил какую-то фантастическую магическую особенность WCF?) Любые комментарии приветствуются.

Ответы на вопрос(2)

Ваш ответ на вопрос