Input on web service heavy web application

Vote:
 

Hi,

I'm currently designing a web application which relies heavily on a back-end service layer exposed as WCF services. I'm now trying to figure out how to expose the data in the way which will handle the largest number of concurrent requests with shortest possible delay.

Because the data will be both personalized and frequently updated caching is no miracle solution here. We will of course cache data but the design must perform as well as possible even when the cache hit rate is very low.

My first idea was to use async pages but it is a bit cumbersome. Instead I'm thinking of using much more partial page loading by ajax requests from the client. Then each part of the page will be loaded asynchronosly and in parallell on the client which will hopefully improve the users' experience in creating the illusion (kind of) that the page loads faster.

To really improve things server-side though, I would also like to be able to complete the processing of the ajax requests asynchronosly. That is, I don't want to use some kind of asynchronous make-ajax-call-to-start-process-and-then-poll-for-changes client side asynchrony, I just want the server side processing to release it's worker thread while waiting for the WCF service call to complete, much like async pages.

So how do I do this? I looked at implementing the ajax end points using async controllers in MVC (even though the "host page" will be implemented in WebForms - it's an EPiServer site). That model looks easy-enough to use and it is simple to serve json to the client ajax calls.

I suppose there's also a way to create a WCF service so that it processes asynchronously without demanding anything special from the client? In that case it would also be an alternative (building one for the web application that is, the web application can not call the back-end WCF layer directly).

Has anyone done something similar? And even if you haven't what are your thoughts from an architecture point of view?

I'm grateful for all input! Thanks!

#57796
Mar 28, 2012 10:55
Vote:
 

http://nodejs.org/dist/v0.6.14/node-v0.6.14.msi :-)

If you want to remain in the .NET stack, have an absolute requirement to serve fresh data and must proxy the WCF service I think your plans sounds good though. Considering you're in WebForms I might have looked at creating a regular handler (implementing IHttpAsyncHandler) instead of an MVC controller though.

#57802
Mar 28, 2012 12:04
Vote:
 

Node would be cool but I think I need to keep the methods inside the main web application to share authentication, data etc.

Yeah, a custom handler could work too. I just thought it would be easier using MVC since you get routing/parameter handling and json formatting "for free".

the MVC4 WebAPI looks interesting too but I'm not sure how EPiServer would handle MVC4. And I don't know if there's an Async pattern for WebAPI (though I assume there is).

#57805
Mar 28, 2012 13:14
Vote:
 

Frederik has already blogged about using the WebAPI framework in EPiServer so this could be a good starting point:

http://www.frederikvig.com/2012/02/using-the-asp-net-web-api-framework-with-episerver/

Did the EPiBorg miss this one ;)?

#57806
Mar 28, 2012 15:00
Vote:
 

Yada yada... ;) From time to time I actually have to do some work and that could mean I miss a post or two :) Thanks for the link, I'll check it out!

#57817
Mar 28, 2012 18:48
Vote:
 

Ah, Web API can run without MVC 4, great! And it seems quite easy to implement async controllers using the task-based programming model:

http://blogs.msdn.com/b/henrikn/archive/2012/02/24/async-actions-in-asp-net-web-api.aspx

Too bad .net 4.5 isn't released, using the async/await style would be some extra sugar. :)

#57823
Mar 29, 2012 8:14
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.