Лучшая практика WCF для клиента/сервера с уведомлениями

Question

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

У нас есть приложение с одним сервером приложений и около 30 - 100 клиентов. Масштабирование сервера не является проблемой. Наиболее важными являются уведомления с сервера клиентам, но, конечно же, есть и сервисные методы, которые вызывают от клиента к серверу.

Что мы делаем сейчас, так это то, что мы создали контракт на обслуживание с каналом обратного вызова, зарегистрируем клиент в сервисе (то есть служба содержит список активных каналов обратного вызова) и отправим уведомления через эти каналы обратного вызова.

Проблема нам нужно перемещаться были:

1. Таймаутов из соединения - услуга теперь содержит некоторый метод KeepAlive, который свистел клиенты о каждой минуте
2. Re-подключениях клиента после сбоя сервера или сети - что является основным моментом, о котором я беспокоюсь. На данный момент у нас есть длительный клиентский объект (служебная ссылка, унаследованная от DuplexClientBase), чтобы вызвать службу и объект обратного вызова для обработки полученных уведомлений. На странице client.Faulted мы пытаемся заменить клиента и объект обратного вызова новым клиентом, пока сервер не будет доступен снова. Этот подход включает в себя некоторые странной обработку исключений ...

Вопрос: Было бы лучше, чтобы запустить службу WCF на каждом клиент и зарегистрировать конечную точку каждого клиента на сервере? Есть ли лучшее решение для двух описанных проблем?

Редактировать: Дело в том, что я что-то упустил? - Я считаю, что описанная архитектура должна быть довольно распространенной, и я ищу «по умолчанию», лучший способ сделать это. Разве нет какой-то выборки для такого рода настроек?

Answer 1

Если ваши проблемы касаются доступности (в данном случае доступности службы -> потребитель и потребитель ->), возможно, вам стоит рассмотреть возможность использования более отказоустойчивого транспорта, такого как MSMQ (возможно, используя netMsmqBinding).

Вы можете заменить сложную инфраструктуру обратного вызова WCF простым и долговечным хранилищем подписки.

Когда вам нужно отправить «обратный вызов», просто получите список потребителей из вашего магазина подписки и отправьте сообщение каждому из них.

Соединения никогда не будут таймизировать, потому что у вас не будет связи с состоянием.

Повторное подключение потребителей к обслуживанию после сбоев сети также решается - на самом деле небольшие сбои в сети не будут заметны.

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