Tech Off Thread

13 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Asynchronous or Synchronous WS calls

Back to Forum: Tech Off
  • User profile image
    Gravy

    Hi, I posted this question on a newsgroup a couple of days ago but there has been very little response.

    What do people think when they want to call a web service from a winforms presentation layer? What I'm asking is how many people out there automatically think asynchronous web service calls when doing a Windows forms UI talking to a web service backend?

    I would be interested in hearing your views on this,
    does everyone still use an RPC style when calling to a web service, even when the web service is your own??

    I have an application that is designed to be istributed, it has a windows forms UI and uses web services for the 'middle tier'. At present I'm trying to do all 'service' calls asynchronous. Am I making more work for myself?

    Do Microsoft have a best practise for this?

    Can there be any justification in calling a web service synchronously (apart from it makes the client UI code simpler!)?

    I'm not asking how do make asynchronous calls, more are they worth it?

    Comments welcome.

    Graham

  • User profile image
    Minh

    If you don't make it async, your app will become non-responsive during your ws call. Since it's a WinForms app, people expect more out of it than a browser. They don't like seeing their desktop app blanked out when they click a button.

    Luckily, .NET makes async calls almost trivial. I think the effort is well worth the benefit.

  • User profile image
    Gravy

    I agree with you. I haven't actually written to large winforms app that wasn't async so I don't really know how bad it is calling things on the UI thread.

    Anyone else had experience of this?

  • User profile image
    Minh

    It's been a while (.NET 1.0) and I'm going off memory, so consider the source. But VS studio will generate the async method for you, and when you call this async method, you provide a callback. Your UI thread returns right away, of course, & the async method will spawn a new thread to call the ws & wait for the result, then call your callback.

    The tricky part is, when your callback is called, it's not by the UI thread, so you'll have to use Control.Invoke (this.Invoke) in your form to call yet another function. That last function is guaranteed to be called by your UI thread so you're set to update your UI.

    I remember reading somewhere that this processed is simplified, but I'm not sure.

  • User profile image
    Xipetotec

    Hi Gravy,

     

    Doing possibly lengthy (anything over the internet) operations are justified by asynchronous calls when it comes to winform application. People simply expect their applications to stay responsive. You will really make a better product when your app stays responsive when it’s waiting for a webservice to complete. So to answer your questions asynchronous calls are worth the effort.

    By implementing the simplified service agent pattern you can write very responsive winform applications.


    Here is an interesting read for you http://weblogs.asp.net/dphill/articles/43260.aspx

    Kind regards,

     

    Marcel van den Hof

  • User profile image
    Gravy

    Thanks Guys.

    Up to this point my winforms app WS calls have all use the Async Beginxxxx methods that exist in the proxy generated code. Can you think of anything wrong with this? Is there a better way?

    cheers

  • User profile image
    Sven Groot

    That's the recommended solution, me thinks. Of course, remember that if you want to access any UI code from the asynchronous callback, you'll need to use Control.Invoke to marshall it back to the UI thread.

    Alternatively, you could create a new thread yourself and call the webservice methods synchronously in that thread. If you need to make a bunch of web service calls in sequence this approach could simplify your code a bit. You still need to use Control.Invoke when accessing UI stuff from this new thread.

  • User profile image
    Gravy

    Phew.

    I have found the UI handling is becomming the harder part of the application. Marcel kindly pointed me to a blog that described a way of automatically switching to the UI thread once the web service call completed, however, this doesn't work that well for me because it relies on the class calling the web service to be a UI control. In my situation I have a 'controller' class that separates the form logic from the UI form handling. It is this controller that communicates with the 'serviceagent'. I must admit, I might change this serviceagent class to look for a specific interface that my controllers implement as well as the callers base class being Control.

    All this means that my UI code has to deal with two extra things above what is would have to in the sync world.

    1) I must ensure the application features that may interfear with the current async operation are disabled.

    2) I must make sure all my UI classes have thread safe (read thread switching) public methods if an update is to be made on the UI.

    Don't get me wrong, I'm all for async message based programming, I'm just explaining my experience.

  • User profile image
    Sk4rlath

    If you're worried about polluting your class library with references to Control, you can always use ISynchronizeInvoke instead. That's the interface that provides the Invoke method - Control implements it. Plus, if you have any other thread-sensitive systems (maybe ones communicating with legacy single-threaded code?) later on that you want to use, just implement ISychronizeInvoke and you're gold.

  • User profile image
    Gravy

    Thanks for all yor comments.

    I think I'll look in  to this interface.

  • User profile image
    object88

    Gravy wrote:
    I would be interested in hearing your views on this, does everyone still use an RPC style when calling to a web service, even when the web service is your own??


    I'm using a synchronous model, mostly because I'm far too lazy at this point to implement the obviously-better asynchronous model.  Once I have a chance to spend some time with it, I'll be checking out asynchronous webservice calls.

  • User profile image
    Catatonic

    Learning to call a service asynchronously is something you just have to deal with. Otherwise, your app's UI can lock up for 30 seconds or more when there is trouble with the network.

    I make sure to keep the result of the "BeginXXX" method and can cast it to a WebClientAsyncResult. This lets you cancel the async method. For example, you can call an async method from a Form, and close the Form before it's finished. If you don't cancel the method, it will try to make a callback to the Form and throw an exception.

  • User profile image
    thebeings

    when it comes to gui coding - i recommend it..

    you can get around it with your threading techniques.. but.. asynch should suffice for most cases.. check it out.. its rather straight forward to use..


    just gets a little tricky when you start going nuts with - like trying to make requests to 100000 of servers at once or something (dont ask where that came from)

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.