Здравствуйте, archytector, Вы писали:
A> Теперь возникла проблема, что совершенно непонятно, как сервису постучаться к клиенту.
Не надо ему стучаться к клиенту.
Просто сделайте на клиенте механизм переодического опроса сервера на предмет наличия результата выполнения операции.
Здравствуйте, vensub, Вы писали:
V>Добрый день,
А>>Поверьте, pulling в 90% случаев — это оптимальная стратегия со всех точек зрения, включая масштабирование и не говоря уже о надежности. А>>Одна только врожденная способность переживать падение канала чего стоит.
А>>Но дело, конечно, ваше.
V>поясните, пжл, что такое pulling? http://en.wikipedia.org/wiki/Pull_technology
Практические везде в интернете располагаются материалы, подробно рассказывающие, как из клиентского приложения, чаще всего консольного, вызвать веб-сервис (смотрел кучу статей на IBM, MSDN — много информации, но всё не то, что надо) С этим проблем нет, я спокойно передаю данные в него из консольного приложения (использовал видео урок Aaron Skonnard из мануалов MSDN на WCF).
В качестве веб-сервиса работает Workflow State Machine на базе .NET 3.0, которая после обработки должна новые данные вернуть клиенту. Время обработки недетерминировано, поэтому по архитектуре возврат данных был сделан отдельным вызовом. Теперь возникла проблема, что совершенно непонятно, как сервису постучаться к клиенту. Подскажите, пожалуйста, идеи, ссылки, примеры.
Использую стандартную поставку Visual Studio 2008, язык С#, платформа .NET 3.0, веб-сервис — Workflow State Machine Library на ASP.NET Development Server.
Здравствуйте, Аноним, Вы писали:
А>Не надо ему стучаться к клиенту. А>Просто сделайте на клиенте механизм переодического опроса сервера на предмет наличия результата выполнения операции.
А>Поверьте, это действительно лучше.
Здравствуйте, archytector, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
А>>Не надо ему стучаться к клиенту. А>>Просто сделайте на клиенте механизм переодического опроса сервера на предмет наличия результата выполнения операции.
А>>Поверьте, это действительно лучше.
A>Мне тут посоветовали вот такой ресурс: A>http://msdn.microsoft.com/en-us/magazine/cc163537.aspx A>На первый взгляд это то, что мне надо. Правда оно потребует нехилого рефакторинга((
Все зависит от того какой тип биндинга используется, если NetTcpBinding или WSDualHttpBinding то проблем с переходом не будет
все что необходимо — использовать на клиенте DuplexChanelFactory и указать объект для работы callback'а.
Мы в проектах используем такой способ обмена, пока проблем не возникало.
Да и причин для "нехилого рефакторинга" не видно, хотя может Вы на клиенте написали кучу врапперов над вызовом сервиса.
Re[3]: Вызов веб-сервисом клиентского приложения.
От:
Аноним
Дата:
04.01.10 21:14
Оценка:
Здравствуйте, archytector, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
А>>Не надо ему стучаться к клиенту. А>>Просто сделайте на клиенте механизм переодического опроса сервера на предмет наличия результата выполнения операции.
А>>Поверьте, это действительно лучше.
A>Мне тут посоветовали вот такой ресурс: A>http://msdn.microsoft.com/en-us/magazine/cc163537.aspx A>На первый взгляд это то, что мне надо. Правда оно потребует нехилого рефакторинга((
Ситуации, в которых имеет смысл поддерживать механизм удаленных callback-ов, имеются.
Но выполнение на сервере долгоиграющих операций к ним не относится. Зуб даю.
Поверьте, pulling в 90% случаев — это оптимальная стратегия со всех точек зрения, включая масштабирование и не говоря уже о надежности.
Одна только врожденная способность переживать падение канала чего стоит.
Добрый день,
А>Поверьте, pulling в 90% случаев — это оптимальная стратегия со всех точек зрения, включая масштабирование и не говоря уже о надежности. А>Одна только врожденная способность переживать падение канала чего стоит.
А>Но дело, конечно, ваше.
