none
Should a good business tier provide async methods? RRS feed

  • Question


  • Hello Forum

    I have developed a business tier that in some cases is located remote and sometimes located on a web server with the web frontend.

    I have frontend developers requesting that I make async versions of all methods or at least of some in the business tier. They want to use this so they can use with the new "Asyncronous Pages" in ASP:NET 2.0. (See links - the last one includes an impressive benchmark)

    I'm not experienced in providing async methods from a business tier. I have 2 questions.

    Should a good business tier provide async methods?

    I'm wonding what issues there can be?

    My setup is like this:

    - The business tier can sometimes be located remote using single call remoting.
    - The identity must be on the thread at all times. Either on HttpContext.Current.User on Thread.Current.Principal. All method calls to the business tier transfers the identity and sets it on the business tier thread. (only if remote)

    I hope someone can help me get my head around this.

    Here are some links for information about Async Pages in ASP.NET 2.0

    Asynchronous Pages in ASP.NET 2.0 - MSDN Article
    http://msdn.microsoft.com/msdnmag/issues/05/10/WickedCode/default.aspx

    Blog entry - Intresting example, benchmark and discussion.
    http://pluralsight.com/blogs/fritz/archive/2004/10/19/2892.aspx

     

     

    Tuesday, November 21, 2006 8:58 PM

All replies

  • Providing async methods depends on the business requirements.

    if not immediate result is expected from the operation its always recommended to provide async method as it is more sclalable.

    but for an operation like funds transfer where immediately success/failure repsonse is required providing an async method me be an overhead.

    http://DotNetWithMe.blogspot.com
    vikas goyal

    Wednesday, November 22, 2006 4:41 AM
  • Asynchronous operations are the key to any highly scalable system.  For example, pretty much all IO in operating systems and databases is asynchronous.  ASP.Net pages aslo execute asynchronously.  An incoming http message is taken off the queue processed on a thread and a response is put on an outgoing queue.  While waiting for the next message in the session, a web app instance exists only as a piece of state information.  It is reinstantiated for each user interaction.  This is the only way you can support thousands of simultaneous users on a few server threads.

    You can obviously extend the same principles to business services running in the background.  If a web page or web service can start a bunch of things simultaneously on asynchronous background threads and then return control to the ueser, the user will perceive the application to be very responsive.  While the user is thinking about what to do next, the business services are executing in the background. 

    A good example of this is the checkout process for most online retailers.  When you complete your purchase the site doesn't say your order is complete - it says it has been accepted and a confirmation will be sent later.  After this, the real order processing happens asynchronously and when it's done it sends you an email.  Sometimes something bad happens - maybe your item turns out to be out of stock - and the response email says your order will be delivered later than you originally thought.  If the business server is down, the order is still recorded and the email response just comes a little late.

    Anyway, asynch business services are a good thing but they're generally significantly harder to write than synchronous code.  When you call an asynchronous method, you don't get a return code other than an indication that the method started.  Success or failure happens sometime later and you may not find out what happened until much later - perhaps a different method running on a different thread will process the result.  This isn't super hard to do but it's different than most programmers are used to dealing with.  The good news for you is that the services aren't significantly different if they have an asynch interface.  The hard part is doing the asynch calls and handling the results.

    While this isn't exactly what you're going to do, there are some ideas about asynchronous programming here:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sql2k5_SrvBrk.asp

    http://msdn2.microsoft.com/en-us/library/aa964144.aspx

     

     

    Thursday, November 23, 2006 4:16 AM
  •  

    VikasGoyal  said "Providing async methods depends on the business requirements."

    Roger_Wolter_MS said "Asynchronous operations are the key to any highly scalable system"

    Both are bang on here - the question you have is "do you have any non-functional requirements for scaleability and performance", and how do those relate to the volumes supplied to you by the business. 

    If you have the above information then you can probably answer your question yourself - if you haven't got that information go back to the business and get it.

    Avoid doing technology for technology sake as I suspect the UI developers are wanting - your PM will thank you in the long run.

    Thursday, November 23, 2006 3:13 PM