I am trying to use asyn CTP with WCF, but I have problems because Task is not serializable.
I have installed CTP v3.
Is it possible to use asyn CTP with WCF? is it need to configure something more than install only the CTP?
I am thinking that if is not possible to use async CTP jet, perhaps instead of using async CTP in the service side, I can implement async method with async CTP that call to the normal methods (not async methods) of the service. is this a good option? In this case the service does not implement async methods.
Other option is in the service side, implement the async methods with the begin/end methods, wrapping this two methods in a task using Task.Factory.FromAsync method. But this is more work.
So My question is, if I want that the client is not blocked while it waits for the service response, I can use two solutions. First use async CTP in the client that call normal methods of the service, or use async methods in the service using Task.Factory.FromAsync. Which is the best option? Why?
Thanks.
Daimroc.
I'm not sure about VS 2010 with Async CTP, but with VS 11 Beta (which you should probably use anyway), you can simply define an operation that returns a Task:
[OperationContract]
Task<string> GetData(int value);
And then implement it using async:
public async Task<string> GetData(int value)
{
return await …;
}
I would assume the same approach would work with Async CTP, but it's just an assumption.
The simplest way to achieve a non-blocking client call is on the client side, for two reasons:
Client side asynchronous methods can be generated by the existing VS tools
Passing Task over service boundary would require you write your own synchronization functionality.
To generate client-side Task<> based (and therefore async/await compatible) methods for a service:
In VS11, a new checkbox exists: "Generate Task-based methods" under "Allow generation of asynchronous operations" in the Configure Service Reference dialog. (I believe it is not yet documented)
For the CTP you can use the extension described here to generate Task based methods.
Related
I'm working on a project that is consuming SOAP services via WCF. Initially, we used generated service references because it was easy to get started. This provides ChannelFactory caching and task-based async methods out of the box, which is clearly desirable.
We've recently switched to using service interfaces and instantiating our own ChannelFactory. We treat the ChannelFactory as a singleton object to cache it. On caching the ChannelFactory -- I've been told that a ChannelFactory can go bad if, for example, one of its channels fault. Is this a real concern?
My second question is in regards to using task-based async calls like the ones generated when using the service reference. How is this done when using a ChannelFactory<T>? I understand that you can annotate methods on T with [OperationContract(AsyncPattern = true)], but these return IAsyncResult and not Task.
Any help would be appreciated.
How do we integrate custom async code in the WCF pipeline, either with await/async or IAsyncResult?
Basically I'm considering the possibility of doing possibly blocking operations during message processing. Two areas for now:
Logging, where we may want to write to a file / database that exposes async versions (granted, this could be done with a queue and a writer thread)
Authorization, where we may need to query a database and it also provides async methods.
Now I was looking on the WCF extensibility points and I can't find any hooks with async versions. I'm looking for IParameterInspector, IDispatchMessageInspector and the likes.
Even the new ClaimsAuthorizationManager doesn't seem to provide an async counterpart either.
I feel I'm missing some big part of the puzzle here, because I have this project where all the code uses the new async features and now I can't hook it up here without doing a .Wait() call on the Tasks.
Could someone shed some lights here or tell me what's wrong with this?
I believe WCF (like MVC) only supports async at the operation level (for now); the pipeline is not fully async. On the other hand, WebAPI was designed with async in mind and supports it at all stages in its pipeline.
I have created one WCF service which performs a lengthy operation asynchronously using Asynch pattern. I have referred to below link to implement BeginAddNumbers and EndAddNumbers methods in the ServiceContract.
http://aspalliance.com/1335_Asynchronous_Pattern_in_Windows_Communication_Foundation.5
Everything is working fine. But I dont understand why we require this approach?
Even though its asynchronous operation on server, client will still blocked and we
have to invoke this operation asynchornously on client as well.
So instead of implementing operation asynchronously on server it's always
better to invoke operation asynchronously on client side to have responsive UI.
Can anyone help me to understand concept of implementing asynchronous operation on server side? Any practical example where I need to play around AsyncPattern=true in conjunction with OperationContract ?
Adding client code. Client is implemented using WPF application
private void button1_Click(object sender, RoutedEventArgs e)
{
MathOperationClient c = new MathOperationClient();
Task t = new Task(new Action(() =>
{
///Even if AddNumbers is is implemented as asynchronous operation
///second call to AddNumbers get chance only after completing below
///call.
///Note: AddNumbers method takes 10 sec to execute
int nResult = c.AddNumbers(2, 3);
this.Dispatcher.BeginInvoke(new Action(()=>{
label1.Content = nResult.ToString();
})
, null);
}));
t.Start();
Task t1 = new Task(new Action(() =>
{
///Below method is invoked only after executing first call ( above call with parameters 2 and 3 )
///in other words below call is blocked for 10 seconds.
///So what is advantage of implementing asynchronous AddNumbers method on server side?
int result = c.AddNumbers(5,5);
this.Dispatcher.BeginInvoke(new Action(() =>
{
label2.Content = result.ToString();
})
, null);
}));
t1.Start();
}
Thanks, Hemant
this post has some information.
in general:
In case of WCF, the realproxy is of type System.ServiceModel.Channels.ServiceChannelProxy. This proxy implementation calls service method synchronously even if we call it using BeginInvoke.
WCF only issues asynchronous calls if the method that is called on a proxy begins with BeginXXX() and is decorated with [OperationContract(AsyncPattern=true)] attribute.
I like the idea to implement this server side; and clearly indicate this by naming the operation accordingly. After all, if a call is asynchronous in nature, why give the client the choice?
Another reason is scalability: doing it server-side decouples the request from the WCF dispatcher thread. This means that WCF threads will not be blocked.
See here for an example.
You could even decide to make it a one way call; and have the client poll at regular intervals; which is, in fact, my favorite approach.
I am trying to create a WCF service that supports asynchronous calls. I followed all samples and tutorials I could find, and all of them have the customary pattern of one synchronous method, and the async Begin and End such as:
[OperationContract(AsyncPattern = false)]
string GetData(int value);
[OperationContract(AsyncPattern = true)]
IAsyncResult BeginGetData(int value, AsyncCallback callback, object asyncState);
string EndGetData(IAsyncResult result);
However, only the synchronous GetData gets called, no matter what I do on the client side. Fiddler tells me that the message is always the same:
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><GetData
xmlns="http://tempuri.org/"><value>0</value></GetData></s:Body></s:Envelope>
When I remove the synchronous GetData interface, the async method now is properly called.
Is this normal behavior? Is there anything else I should do to support sync and async versions of a method?
This is a common misconception. You assume that you need to make the server asynchronous in order for the client to be able to make async calls. This is not true. Server and client are 100% independent. They are separated by a binary wire protocol.
The message that you see in Fiddler is always the same because SOAP does not know anything about sync or async. At the SOAP level your decision does not manifest itself. For that reason the client cannot observe your server-side decision, either.
This means you can just make the server synchronous in still have a truely async client, or the other way around.
In any case, you should only implement one pattern on the server: Either sync or async. Never both. Get rid of one of your implementations. From a functional standpoint it doesn't matter which one stays.
I'm pulling up important information from the comments here:
It is hard to fit an explanation about when to use server-side async
into this comment box. In short, don't use it on the server by
default. Use it if special circumstances make it attractive or
necessary.
On a meta-level let me point out that async IO has become
a fad that should not be followed lightly. The community is in a very
unfortunate state of misinformation about this right now.
I'd like to be able to create a WCF service that the client see as synchronous, but is implemented server side as asynchronous. I know that ASP.NET allows me to do this by implementing the IHttpAsyncHandler, but can't seem to find the equivalent in WCF.
This is a service that exists already and we'd like to move over to an asynchronous implement server side, without changing the client. Is this possible?
If you are on .Net 4.5 change the OperationContract methods in service contract interface to return Task<type> instead of type. In the class that implements the interface use the async modifier on the methods and use await inside following the Task based Asynchronous Pattern
See http://msdn.microsoft.com/en-us/library/ms734701
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DEV326