0

I've read up on the Async Page and it's usage, looks simple:

[UPDATE] Taken from here:

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
}

But I can't get my head around the following problem:

What if I want to call an asynchronous operation/webservice from my business layer and not directly from my page's code-behind? I can't seem to find any info on that on the net.

The scenario in a nutshell:

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

One solution to the problem I can think of would be to call the business layer service asynchronously, utilizing a second thread from the thread pool only for the amount of time needed to call the external webservice: Request --> Page handler - || -> Business layer service - || -> External webservice. [UPDATE ->] So basically I thought of extending the above approach to my business layer service using the exact same pattern. [<- END] In this case, both threads would be released to the thread pool (or so I guess) and could process other incoming requests. When the answer from the webservice returns, at first a thread is bound for processing the business layer service and then another for finishing the Page rendering. But that sounds like a lot of overhead - both in coding and maybe even at runtime.

Another solution would be a modification of the first one - namely, returning an unfinished response to the client once we trigger the external webservice call and processing the result of it not in the context of a Request but simply inside the application. Then, of course, the client would have to poll the server for the result which should have been saved somewhere. This is basically the idea that @emfurry layed out in Async Web Service Calls.

Are there any other viable options I have not considered?

Community
  • 1
  • 1
Oliver
  • 9,239
  • 9
  • 69
  • 100
  • Your first solution isn't feasible because it violates the fundamental architecture of the HttpRequest/HttpResponse cycle. You should pursue the second option as it is the only viable one. Remember, request/response is a 1 ask, 1 answer process. You cannot disconnect it and resume it, and you cannot push from server to client, you can only EVER pull. Just imagine that there's a firewall between me(client) and you(server) so that only I can reach through to touch you, not vice versa - cause thats typically true. ;) – The Evil Greebo Jun 22 '11 at 10:04
  • Thanks @Greebo. I wasn't thinking of pushing anything to client, guess I didn't state myself clearly. See my UPDATE for further explanation. – Oliver Jun 22 '11 at 10:51

1 Answers1

0

You could consider taking a look at messaging or the use of a service bus.

I have a FOSS ESB here: http://shuttle.codeplex.com/

This allows you to do asynchronous processing.

Eben Roux
  • 12,983
  • 2
  • 27
  • 48
  • Thanks for hint and the link, @Eben. I'm not exactly familiar with the design goals and objectives of a service bus and have no clue right now, how I would solve my problem using one. So for now, that's beyond my reach. – Oliver Jun 22 '11 at 18:17
  • With an ESB you basically send messages (simple classes with all your relevant data) to some queuing mechanism (like msmq). The queue is monitored by a system (typically a service) that processes any messages received. This allows you to asynchronously hand off work to other components. You can also publish events that any of these endpoints (services) can subscribe to (pub/sub). Different paradigm but it works quite well when you get into the swing of things. – Eben Roux Jun 22 '11 at 18:24
  • Thanks for the overview. I get the idea, but am not sure how that would fit into my async Page life cycle. Looks like I'll be left to some polling from the client for the result of the long running operation. – Oliver Jun 24 '11 at 21:07
  • np :) --- a little polling probably won't kill anyone – Eben Roux Jun 25 '11 at 06:14