Вопрос немного в деталях.Выводы (которые могут быть неверными из-за недостатка подробностей) заключаются в том, что у вас есть клиент .NET, выполняющий вызов веб-службы, представленной приложением Classic ASP.
Вы рассматриваете возможность использования BeginInvoke вподкласс SoapHttpClientProtocol, чтобы сделать вызовы асинхронными с точки зрения ваших клиентов.
На основании того, что мои выводы верны, вам не нужно делать ничего особенного для веб-службы ASP, просто добавьте метод службы какнормальный.Фактически, если вы рассматриваете вызов существующего асинхронно, вам вообще ничего не нужно делать с кодом на стороне сервера.«Асинхронность» - это полностью выдумка на стороне клиента, когда клиентские API выполняют обратный вызов после завершения запроса.
Вероятно, лучше понять, как работают синхронные вызовы, потому что на самом деле они более «искусственные», чемвидимо, более сложные асинхронные вызовы.Прежде всего все операции, которые выполняют какой-либо сетевой ввод / вывод , будут по необходимости асинхронными .В какой-то момент текущему выполняющемуся потоку больше нечего делать, пока он ожидает вечность (с точки зрения современного ЦП) для завершения операции ввода / вывода.
Таким образом, все веб-сервисы фактически будут асинхронными, и вам не понадобится ничего особенного с конфигурацией или брандмауэрами.Просто типичный дружественный к разработчику API-интерфейс будет блокировать текущий поток, в то время как IO завершает работу, и часто использует семантическую функцию для возврата ответа.
Единственная реальная разницапри асинхронном вызове поток не блокируется после выполнения операции ввода-вывода, а просто возвращается.Когда операция ввода / вывода завершится, она просто вызовет предоставленный метод обратного вызова.