Как реализовать общение в Интернете с возможностью публикации / подписки

Question

У меня есть служба .Net, размещенная на сервере, и клиенты .Net, подключающиеся к этому серверу через Интернет.

Я хочу реализовать модель подписки на публикацию, когда клиенты могут подписываться на события в службе иотправлять им данные по мере их поступления.Альтернативой может быть то, что клиенты опрашивают сервер на наличие данных, однако это, вероятно, будет слишком медленным для того, что требуется.Отсюда необходимость в типе связи «публикация / подписка».

Я понимаю, что привязка WCF WSDualHttpBinding делает это возможным, однако имеет свои недостатки.По словам автора "Programming WCF Services" Джувала Лоуи,

... WSDualHttpBinding в основном непригоден, поскольку практически невозможно туннелировать через различные коммуникационные барьеры, отделяющие сервис от клиента, и необходимостьнайти конкретный веб-сервер делает это непрактичным.

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

Итак, суть моего вопроса в том, как мне достичь типа публикации / подписки / обратного вызова через Интернет, без необходимости открывать порты на клиенте.машина?Открытые стандарты в порядке, но не нужны, так как клиент и сервер оба .Net, Windows Azure не вариант.

Answer 1

Вы упоминаете большинство опций в своем посте.

Существует 3 варианта:

• Клиент опрашивает сервер.Не требует открытых портов, но слишком медленный.
• WSDualHttpBinding требует открытия портов
• Azure Service Bus, будет делать это, но это не вариант.

На самом делеспособ сделать это.Если вы посмотрите, как работает служебная шина Azure, то это заставит клиента думать, что он находится на исходящем порте, когда он действительно используется для отправки сообщений клиенту.Вы можете попробовать реализовать эту функцию.

Другая вещь, которую вы можете попробовать, - это nservicebus на http://nservicebus.com/,, это сервисная шина с открытым исходным кодом .net.

Answer 2

Internet Communication Engine (ICE) предлагает IceStorm, сервис публикации / подписки .

с открытым исходным кодом, и если вы загружаете установку, существует пример проекта Visual Studio, демонстрирующийреализовать публикацию / подписку (посмотрите файл .zip «demos» и каталог «IceStorm» с демонстрацией часов).

ICE сделает всю тяжелую работу за вас, кривая обучения удивительно короткая,прежде всего потому, что документация обширна, доступна и хорошо написана.

Answer 3

WSDualHttpBinding содержит два канала, один от клиента к серверу и второй от сервера к клиенту.Последний действительно требует настройки брандмауэра и NAT.Что насчет Net.Tcp?Он использует только один канал и поддерживает обратные вызовы (дуплексная связь) по этому каналу, инициируемые от клиента к серверу.Вы упомянули, что и клиент, и сервер будут .NET-приложением, поэтому это должно быть возможно с некоторой конфигурацией брандмауэра на сервере.

Answer 4

Я настоятельно рекомендую вам DDS (служба распространения данных от OMG) через Интернет http://www.omg.org/news/meetings/workshops/Real-time_WS_Final_Presentations_2008/Session%203/03-02_Bertocci_et_al.pdf

От OMG это все, что я должен сказать.Да, я знаю, вы можете подумать, что OMG закончилась.Я не знаю, и как правительственный советник я действительно настаиваю на стандартах.Имейте в виду, что, помимо либеральной идеологии и кризисов, правительства по-прежнему являются огромными клиентами, и взаимодействие является обязательным.Хорошо, хорошо, это нормально, но не слишком ли сложно начать прямо сейчас?Кривая обучения слишком ... крутая?Наверное, нет, но проще?

ЛЕД - хороший выбор.ребята из мира CORBA пытаются улучшить ситуацию.Не сомневайся, используй, пробуй!Просто ощущение: даже с помощью штормовой службы вы можете чувствовать, что все еще находитесь в мире запросов / ответов ... но разве это обман?

---

Но если вы предпочитаете коммерческое, но открытое решение, подумайте о публикации подписки с использованием буферов протокола (поиск буферов протокола Google) ... просто первый подход http://protocolbus.casessite.org.Это моя работа ... извините, это только начальный проект, но я работаю с дистрибутивом центрального брокера в качестве альтернативного транспорта (по умолчанию многоадресная рассылка, но широковещательная рассылка и udp также доступны).Открытый исходный код, так что будьте свободны ...