1
votes

I am developing a WCF RESTful web service which only accept HTTP. I have few questions about changing to async pattern.

  1. Almost all examples that demonstrates how to use TPL to implement async WCF operation contract use client based on WCF client proxy, in my case client could be a browser that only support HTTP verbs, so it seems changing my WCF service to async pattern is not so meaningful. Can I say, if a service is RESTful and each request doesn't take very long to process, I will not benefit a lot from changing service synchronized to async?

  2. If my service operation contracts either is a OneWay service or return nothing to client, operation contract should be defined as async Task DoSthAsync() or void DoSth()? What is the difference here? In other words, should I await/return the Task.Run or not.

  3. My service accepts big chunk of data send from client using HTTP POST, suppose the processing would take a while, so changing to async pattern could improve service concurrency and throughput, how to make sure that the pass-in stream object is not disposed by WCF in Task.Run(() => {})delegate?

1
So do you want to use TPL within WCF or use it on the client side? When you say most clients are wcf proxies in examples, that is client side using TPL. What do you mean a browser: will you be using JavaScript or browser as the client? - CodingYoshi
@CodingYoshi I have no assumption on clients. I totally focus on server side here. - codewarrior

1 Answers

0
votes

1.Almost all examples that demonstrates how to use TPL to implement async WCF operation contract use client based on WCF client proxy, in my case client could be a browser that only support HTTP verbs, so it seems changing my WCF service to async pattern is not so meaningful. Can I say, if a service is RESTful and each request doesn't take very long to process, I will not benefit a lot from changing service synchronized to async?

Question 1 is totally out since you said you want to use TPL on the WCF server side and not client side.

@CodingYoshi I have no assumption on clients. I totally focus on server side here.

.

2.If my service operation contracts either is a OneWay service or return nothing to client, operation contract should be defined as async Task DoSthAsync() or void DoSth()? What is the difference here? In other words, should I await/return the Task.Run or not.

You do not specify in your service contract whether a service is async or not. That is internal to your service. Whether your service is doing things asynchronously or not, the client can still call your service synchronously or asynchronously. For example, if your service writes stuff to a file and the writing takes 5 minutes and you have implemented to do this synchronously, the client can still call your service asynchronously (or synchronously). If you have implemented this asynchronously, then the threadpool thread which handled the call will be free to handle other calls. In other words, the changes will only be effecting the server side.

Also keep in mind, if you are doing something which is truly async then doing it asynchronously will be beneficial. If you are doing a CPU intensive operation, then doing it asynchronously will actually hurt performance. Why? Because when a request comes to ASP.NET (WCF, MVC, Web Forms or whatever) the most efficient way to handle the request is to do it using one thread-pool thread. If you are doing a CPU intensive operation then whether that thread does it, or you start a Task and another thread takes over, will be no different. However, you will pay the price for switching contexts.

3.My service accepts big chunk of data send from client using HTTP POST, suppose the processing would take a while, so changing to async pattern could improve service concurrency and throughput, how to make sure that the pass-in stream object is not disposed by WCF in Task.Run(() => {})delegate?

When a request arrives at the WCF gate, whether you handle it asynchronously or synchronously, the response will not be sent unless and until the whole operation is completed. So why would the passed in stream be disposed?

I think you are not clear on the whole async concept. Whether your service is async or not, the client will still need to make sure the calls are not blocking. For example, if the clients calls an operation, they can either:

  1. Wait until they receive a response and do nothing else or
  2. Call the service, do other things and once the response returns, they handle the response.