Reputation: 2703
I found this documentation that explains how to implement an asynchronous WCF service operation:
https://msdn.microsoft.com/en-us/library/ms731177(v=vs.110).aspx
This makes me wonder why (or when) would I want to make my service operations asynchronous, when the client can generate asynchronous versions of the operations himself. When a client generates asynchronous versions of the operations, is it the same as if the service already implemented asynchronous operations itself?
Also, in the sample code in the documentation, there is no OperationContractAttribute for the end methods. Why?
Upvotes: 1
Views: 469
Reputation: 523
I think the answer to your question is right after the link you have provided. Here (https://msdn.microsoft.com/en-us/library/ms734701%28v=vs.110%29.aspx) you can see:
Use an asynchronous approach in a service operation implementation if the operation service implementation makes a blocking call, such as doing I/O work. When you are in an asynchronous operation implementation, try to call asynchronous operations and methods to extend the asynchronous call path as far as possible. For example, call a BeginOperationTwo() from within BeginOperationOne().
So when your service consumes some another service, for instance Redis, or downloads anything, that makes absolutely perfect sense to implement those operations also in async way and not to block working threads of your server. The number of working threads is limited and at some point your server would simply get stuck, because all of them are serving calls. In case of async implementation you can take advantage of usin I/O completion port and appropriate I/O threads from separate thread pool. I/O completion ports is very efficient mechanism in Windows, which helps to avoid resource wasting.
Upvotes: 4