Я хочу добраться, обновления прогресса о методе обратились к WCF.
Например, я выполняю 1 000 запросов и хочу знать текущий статус.
Если дуплексный контракт не работает в вашей среде, вам придется прибегнуть к опросу. Ваш первоначальный метод может возвращать идентификатор (возможно, GUID), а затем вы можете выполнять последующие вызовы другого метода для проверки хода выполнения и передавать идентификатор.
Это, очевидно, потребует от вас где-то хранить информацию о ходе выполнения (например, сеанс или базу данных), что не очень хорошо.
Да - используйте дуплексный контракт и периодически сообщайте о ходе выполнения, используя обратные вызовы.
Это сильно зависит от вызываемых вами сервисов и от того, как долго вы ожидаете выполнения операций.
Если вы запускаете 1000 запросов на одном сервисе, то, скорее всего, вы столкнетесь с дросселированием сервиса до того, как все звонки в сервис будут приняты.
Есть похожее явление и на стороне клиента. WCF допускает только такое количество одновременных вызовов. Это в некоторой степени настраивается, но я был бы удивлен, если бы 1000 одновременных вызовов работали без подсказок или двух.
Если бы вызовы в конечном итоге были более или менее синхронными, я бы поставил все запросы в очередь и обрабатывал бы каждый вызов поочерёдно. Затем вы можете следить за состоянием очереди из вашего пользовательского интерфейса для обновления по мере завершения звонков в службу.
Если ваша архитектура поддерживает 1000 одновременных звонков, то дуплексная привязка подойдет. Вы можете просто опрашивать для завершения.
Кроме того, вы можете создать службу паба / подслужбы, которая будет обновлять целевую службу по мере выполнения запросов. Ваш клиент будет просто ловить события из паба / подслужбы, как результаты запросов становятся доступными.
.