Архитектура WCF: использование обратных вызовов, событий, 2x сервис-клиент? - PullRequest
Новая
       10

Архитектура WCF: использование обратных вызовов, событий, 2x сервис-клиент?

1 голос
/ 23 февраля 2011

У меня установлено основное приложение (ServerApp) на сервере локальной сети (который находится за брандмауэром, поэтому сервер может получить доступ к Интернету, но к нему нельзя получить доступ напрямую из Интернета (без статического IP-адреса)), а также мониторингприложение (MonitorApp) на моем компьютере, которое находится за пределами локальной сети и напрямую подключается к Интернету.

ServerApp должен отправлять некоторые события уведомлений (в основном некоторую статистику) на MonitorApp своевременно (каждые 1-2 секунды).

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

  • Как установить связь между этими двумя приложениями?Смогу ли я использовать обратные вызовы WCF в этом сценарии?(учитывая, что я не могу видеть сервер непосредственно из моего MonitorApp).
  • Есть ли предпочтение в производительности при использовании службы WCF и клиента на одной стороне и другой службы WCF и клиента на другой стороне в противоположностьк контракту обратного вызова WCF.Я предполагаю, что я должен использовать 2x client-services с обеих сторон, потому что мне нужно использовать базовую HttpBinding для прохождения брандмауэра.
  • Какие-нибудь общие рекомендации о том, как это реализовать?
  • Если я планирую написать приложение типа MonitorApp, но также смогу отправлять команды на ServerApp (для пояснения, назовем его ControlApp), должен ли я использовать другой подход?

Извиняюсь за несколько вопросов.И спасибо.

1 Ответ

1 голос
/ 23 февраля 2011

Похоже, трудно достичь решения.

У меня установлено основное приложение (ServerApp) на сервере локальной сети (который за брандмауэром, поэтому сервер может доступ в интернет, но это не может быть доступ из интернета напрямую (нет статический IP))

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

Для меня правильный дизайн состоит в том, что ServiceApp размещает службу, которая может предоставлять данные мониторинга, и вторую службу для выдачи команд. В вашем сценарии это невозможно. Частично решить проблему мониторинга можно с помощью услуги хостинга в MonitorApp:

Вы можете выставить договор на обслуживание как 

[ServiceContract]
public interface MonitoringAppContract
{
  [OperationContract(IsOneWay=true)]
  void SendMonitoringData(MonitoringData data);
}

ServerApp будет регулярно вызывать эту операцию и передавать данные мониторинга в MonitorApp. Из-за одностороннего вызова он не будет заблокирован обработкой данных в MonitorApp, но он также не будет уведомлен об исключениях. Проблема здесь в том, что служба WCF, предоставляемая в MonitorApp, должна быть доступна, или ServerApp будет ожидать истечения времени ожидания Open.

Дуплексная связь также не будет решением, потому что снова ServerApp придется установить соединение - опять же проблемы с тайм-аутами, более того, дуплексная связь является сессионной, и она требует другой заботы о таймаутах неактивности и т. Д.

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

...