Asp.Net - асинхронный вызов веб-службы из другого уровня приложения, а не самой страницы

Я читал на странице Async, и ее использование выглядит просто:

[ОБНОВЛЕНИЕ] Взято из здесь:

protected override void OnInit(EventArgs e)
{
    base.OnInit(e);

    var task = new PageAsyncTask(BeginRequest, EndRequest, null, null);
    RegisterAsyncTask(task);
}

IAsyncResult BeginRequest(Object sender, EventArgs e, 
                          AsyncCallback cb, object state)
{ 
    return _service.BeginHelloWorld(cb);
}

void EndRequest(IAsyncResult asyncResult)
{
    var answer = _service.EndHelloWorld(asyncResult);
    // do something with answer
}

Но я не могу понять следующую проблему:

Что, если я хочу вызвать асинхронную операцию / веб-службу из моего бизнес-уровня, а не прямо из кода программной части моей страницы? Кажется, я не могу найти никакой информации об этом в сети.

Сценарий в двух словах:

Request --> Page handler --> Business layer service - || -> External webservice

Одно из решений проблемы, о котором я могу думать, - это асинхронный вызов службы бизнес-уровня с использованием второго потока из пула потоков только на время, необходимое для вызова внешней веб-службы: Request -> Page handler - || -> Business layer service - || -> External webservice. [ОБНОВЛЕНИЕ ->] Итак, я задумал распространить описанный выше подход на мою службу бизнес-уровня, используя тот же самый шаблон. [‹- END] В этом случае оба потока будут выпущены в пул потоков (или я так полагаю) и смогут обрабатывать другие входящие запросы. Когда возвращается ответ от веб-службы, сначала связывается поток для обработки службы бизнес-уровня, а затем другой поток для завершения рендеринга страницы. Но это звучит как много накладных расходов - как при кодировании, так и, возможно, даже во время выполнения.

Другим решением может быть модификация первого, а именно, возврат незавершенного ответа клиенту после того, как мы инициируем вызов внешнего веб-сервиса, и обработка его результата не в контексте запроса, а просто внутри приложения. Тогда, конечно, клиенту нужно будет опросить сервер, чтобы узнать результат, который нужно было где-то сохранить. По сути, это идея @emfurry, изложенная в вызовах асинхронных веб-служб.

Есть ли другие жизнеспособные варианты, которые я не рассматривал?


person Oliver    schedule 22.06.2011    source источник
comment
Ваше первое решение невозможно, поскольку оно нарушает фундаментальную архитектуру цикла HttpRequest / HttpResponse. Вам следует выбрать второй вариант, так как он является единственным жизнеспособным. Помните, что запрос / ответ - это 1 вопрос, 1 ответ. Вы не можете отключить его и возобновить, и вы не можете продвигать его с сервера на клиент, вы можете только ВСЕГДА тянуть. Только представьте, что между мной (клиентом) и вами (сервером) есть брандмауэр, так что только я могу дотянуться до вас, а не наоборот - обычно это так. ;)   -  person The Evil Greebo    schedule 22.06.2011
comment
Спасибо @Greebo. Я не собирался подталкивать что-либо к клиенту, наверное, я не выразил себя четко. См. Мое ОБНОВЛЕНИЕ для дальнейшего объяснения.   -  person Oliver    schedule 22.06.2011


Ответы (1)


Вы можете рассмотреть возможность обмена сообщениями или использования служебной шины.

У меня есть FOSS ESB здесь: http://shuttle.codeplex.com/

Это позволяет выполнять асинхронную обработку.

person Eben Roux    schedule 22.06.2011
comment
Спасибо за подсказку и ссылку, @Eben. Я не совсем знаком с целями и задачами проектирования служебной шины и сейчас не знаю, как бы я решил свою проблему с ее помощью. Так что пока это вне моей досягаемости. - person Oliver; 22.06.2011
comment
С помощью ESB вы в основном отправляете сообщения (простые классы со всеми вашими соответствующими данными) в некоторый механизм очередей (например, msmq). Очередь контролируется системой (обычно службой), которая обрабатывает любые полученные сообщения. Это позволяет асинхронно передавать работу другим компонентам. Вы также можете публиковать события, на которые может подписаться любая из этих конечных точек (служб) (pub / sub). Другая парадигма, но она работает довольно хорошо, когда вы начинаете разбираться в вещах. - person Eben Roux; 22.06.2011
comment
Спасибо за обзор. Я понимаю, но не уверен, как это впишется в мой жизненный цикл асинхронной страницы. Похоже, мне оставят некоторый опрос от клиента для результата длительной операции. - person Oliver; 25.06.2011
comment
np :) --- небольшой опрос, наверное, никого не убьет - person Eben Roux; 25.06.2011