Successive Async Call problem

Successive Async Call problem

• Wicket

  Waw :)
  
  Thanks for your great explications.
  
  Just a last question perhaps :p
  
  What about Visual studio with svcutil. Is the add service reference function customizable or is the service reference function do it for you
  
  
  Thanks
  
  
  

• KillerKryptos

  I agree with you except "Your service contract is untouched" because you must define :

  [OperationContract(AsyncPattern = true)]
  IAsyncResult BeginMultiply(double n1, double n2, AsyncCallback callback, object state);
  double EndMultiply(IAsyncResult ar);

  So you must touch your interface.

  I'm sorry but it's not very clear for me
  

  
  
  

• Devin

  Yes, you could also implement a one-way method with a callback, but implementing async better, IMHO, for the following reasons:

  - Your service contract is untouched, i.e., the operation is defined as request-reply and no separate interface for the callback operation contract is needed; svcutil.exe creates the async equivalent of the request-reply but the server side implementation has no clue about the fact that the client side is implementing the operation as async; the server side implementation of the operation remains request-reply. Compare this with the case of one-way + callback; your server side must know about the callback and have the added logic of calling the callback operation when the one-way operation completes.

  - Async is "cleaner" becasue it's a well-defined design pattern for such long-running method calls. It's always good practice, IMHO, to use well-known and recommended patterns.

  Does this make sense

  Thanks.

  
  

• SPWilkinson

  Hello,
  
  Thanks for your reply.
  
  Do you have any exemple of the suggest #3
  And what is the difference between #3 and One way method
  
  
  

• ahmedWebDev

  For an example of #3, please see the async documentation page at http://msdn2.microsoft.com/en-us/library/ms730059.aspx.

  The difference between #3 and one-way is that #3 gives you more control over the GUI behaviour on the client-side, particularly in dealing with multiple clicks and your original issue of not knowing whether calls were completed or lost when the button was clicked a few times in a row.

  Using the async pattern, you can un-freeze the GUI because the "BeginXXX" (where XXX is the name of your request-reply operation contract) returns immediately on the client-side; at this point you can indicate on the GUI that the call is in progress (e.g., disable the button and perhaps change the button's text). Then, when XXX is really done and the async callback is called on the client side, you can re-enable the button so that it's ready to accept clicks again.

  Please post back if you still need more guidance.

  Thanks.

  
  

• TheGeoff

  You can't; for passing options such as '/a', you'll have to use svcutil.exe directly.

  The '/a' option will generate both, the synchronous and asynchronous methods.

  Thanks.

  
  

• Emanuel Dejanu

  Hello,

  May I suggest the following

  1) Are you sure the calls are lost on the server side Can you put simple trace statements to see how many calls you receive on the service side in response to multi-clicks

  2) If the call takes a long time to process, you may want to consider making the method call request-reply so that your GUI logic on the client side does not enable the button until the call has completed.

  3) If you like the idea in #2 (above), but don't want to freeze the entire client GUI while the call is being completed, you can implement the request-reply as async on the client side and disable the button (but keep the GUI responsive) and re-enable it after the async call completes.

  Thanks.

  
  

• LouArnold

  No, you don't define the async pattern; the async pattern is generated for you by svcutil.exe when you give it the /a option. Thus, you start with a normal (i.e., sync) service contract and implement it on the service side. You then run svcutil.exe with the /a option and it generates the async pattern for you. Your contract remains unchanged; only your client-side implementation is based on the async pattern.

  Hope this is clear.

  Thanks.

  
  

• James A. Gayhart

  Ok for this explication but a oneway method is the sameone for the client as the async call. Because with async the client have directly the process and a hander method will be receive the process completed.
  Oneway with callback this is the same schema or i don't understand that you want to explain
  
  
  

• Hello_Yo

  Yes am am also woundering this.
  
  When i choose Add services reference in Visual studio 2005(with orcas) how can a costumize this so i get a proxy that can handle async calls, will it also generate simple sync calls to
  
  
• Successive Async Call problem