Well, I am thinking in a WCF service per call, and use async methods for scalability reasons. Then I am thinking in the following, what is better, to have the async methods in the service or in the client?
All the examples that I see is in the contract of the service implement the begin/end methods and then the client consume this methods.
However, I am thinking in other possibility. is it possible to have normal methods in the service and in the client implement the begin/end methods or use CTP and consume the methods of the service asynchroly? If I use this form, would I loose the scalability benefits?
Thanks.
Daimroc.
I would use the Begin/End pattern in this case - it is an explicit message to the clients that the service is a long-running operation & should expect delays in the processing.
On the other hand, if you have normal methods & if one of the clients did not code the method call properly, all your scalability efforts won't help.
Related
I have a wcf client I generated using SVCUTIL with the /async flag.
The server is syncronic, but I only use the Begin/End methods in my client.
Also, I added the attribute UseSynchronizationContext=false in the CallbackBehavior.
My question is: How does WCF work with threads in this mode?
Or better phrased - Is WCF using the ThreadPool class to acquire new threads for the callback when I call simultanous functions? Or does it have some custom implementation?
I Googled the subject for hours, didn't find anything near an answer.
EDIT: I see I've been a little unclear here - I'm not asking about the server app, I'm asking about the client app - how does it manage the threads on which it returns the callbacks when I set the usesynchronizationcontext flag to false?
Your service's threading is unaffected by how the client calls it. When you use proxy Begin/End methods, the proxy is using a different client thread to make the service call so that your application code does not block.
With .NET 4.5 task based asynchronous calls are now preferred.
See Synchronous and Asynchronous Operations for an overview of the different patterns.
I want to implement a WCF service that responds immediately to the caller, but queues up an asynchronous job to be handled later. What is the best way to go about doing this? I've read the MSDN article on how to implement an asynchronous service operation, but that solution seems to still require the task to finish before responding to the caller.
There are many ways to accomplish this depending what you want to do and what technologies you are using (e.g. Unless you are using silverlight, you may not need to have your app call the service asynchronously) The most straight forward way to achieve your goal would be to have your service method start up a thread to perform the bulk of the processing and return immediately.
Another would be to create some kind of request (e.g. Create an entry in a datastore of some kind) and return. Another process (e.g. A windows service, etc.) could then pick up the request and perform the processing.
Any WCF service can be made asynchronous -
One of the nice things about WCF is you can write a service synchronously. When you add a ServiceReference in the client, you have the option of generating asynchronous methods.
This will automatically make the service call asynchronous. The service will return when it's done, but the client will get two methods - BeginXXX and EndXXX, as well as XXXAsync + an XXXCompleted event, either of which allows for completely asynchronous operation.
In my current web project, we perform a ClientFactory.CreateChannel for every method call to a remote service.
Is this really necessary?
What is the best practice?
This depends to some extent what your requirements are. Opening a channel is expensive, relatively speaking. Best practice is to have the class that is doing the remote calls implement IDisposable, it should make a call to ClientFactory.CreateChannel once, use the channels in all the method calls, and close the channel when the Dispose method is called. That said, if the time between the calls to methods that call to a remote service is long (longer then the default idle timeout on the channel which is 10 minutes) then doing a ClientFactory.CreateChannel isn't particularly harmful, but I would say it would still be better to go the IDisposable route and encapsulate use of the class with the 'using' keyword
creating a new channel for each method call comes in bad practice "generally".
For Duplex WCF Service
creating a single channel and using it until there is no need to communicate with server anymore/ or that channel gets closed.
After creating the channel, before making any call to server, its recommended to check channel's state (Error, opening, closed).
Registering the channel closed/Error events is recommended to get to know immmediatley when it occurs. so you can take necessary actions or/and create the channel again with same object channel object reference.
For Normal WCF service
Create the proxy pattern, to create channel/ to re-use/ re create, error handling and disposing. set the appropiate inactivity timeout along with WCF client's proxy appropiate configuration which suits best with your solution.
Always Load test!!!!
In the project I'm currently working we're using WCF.
Company policy forces us to use async calls and the reason should be security.
I've asked why this is so much more secure but I don't get clear answers.
Can someone explain why this is so much secure?
They are not. The same security (authentication, encryption) mechanisms and considerations apply whether a call blocks until it gets a response or it uses a callback.
The only way someone may be confused into thinking that asynch calls are more "safe/secure", is they think that unhandled WCF exceptions will not bring down the main thread if they are asynchronous, as they will be raised inside the callback.
In this case, I would advice extreme caution when approaching the owner of this policy to avoid career-limiting consequences. Some people can get emotionally attached to their policies.
There is no point why an async call will be more secure than a sync call. I think you should talk to the owner of the policy for the same.
No they are not more or less secure than synchronous calls. The only difference is the client waits for a response on synchronous calls, whereas on async it is notified of a response.
Are they coming from the angle that synchronous calls leave the connection open longer or something?
Just exposing a WCF operation using an async signature (BeginBlah/EndBlah) doesn't actually affect the exposed operation at all. When you view the meta data, an operation like
[OperationContract(AsyncPattern=true)]
IAsyncResult BeginSomething(AsyncCallback, object)
void EndSomething(IAsyncResult)
...actually still ends up being represented as an operation called 'Something'. And actually this is one of the nice things about WCF: the client and server can differ in whether they choose to implement/consume an operation syncronously.
So if you are using generating WCF proxies (eg through Add Service Reference) then you will get syncronous versions of each operation whether they are implemented asyncronously or not unless you tick the little checkbox to generate the async overloads. And when you do you then get async versions of operations that might only be declared syncronously on the server.
All WCF is doing is, on both the client and server, giving you a choice about your threading model: do you want WCF to wait for the result, or are you going to signal it that you've finished. How the actual transport connection is managed is - to the best of my knowlege - totally unaffected. eg: For a NetTcpBinding the socket still stays open for the duration of the call, either way.
So, to get to the point, I really struggle to imagine how this could possibly make any difference to the security envelope of a WCF service. If a service is exposed using an async pattern, and is genuinely implemented in an async way (async for outbound IO, or queues work via the thread pool or something) then there's probably an argument that it would be harder to DOS the service (by exhausting the pool of WCF IO threads), but that'd be about it.
See Syncronous and Asyncronous Operations in MSDN
NB: If you are sharing the contract interface between the client and server then obviously the syncronisity of the two ends match (because they are both using the same interface type), but that's just a limitation of using a shared interface. If you made another equivilent interface, differing only by the async pattern, you could still create a ChannelFactory against it just fine.
I agree with the other answers - definitely not more secure.
Fire up Fiddler and watch a synchronous request vs. an asynchronous request. You'll basically see the same type of traffic (although the sync may send and receive more data since it's probably a postback). But you can intercept both of those requests, manipulate them, and resend them and cause havoc on your server.
Fiddler's a great tool, by the way. It's an eye-opener in terms of what kind of data and how much data you're sending to the server.
I have a silverlight application that is like a portal where user-defined widgets will be calling wcf services. Since these components could be quite chatty I would like to hijack the service calls and have them flow through a single client proxy that could throttle, potentially cache results, etc.
So the idea would be to have the dispatch in the client proxy simply call another client proxy (the master) rather than going over the wire. At least I think that's what I want. The master would return an asyncresult and service the request at its discretion or perhaps return some cached data.
Do the appropriate wcf extension points for something like this exist in silverlight? Is it even possible to accomplish this without using runtime code generation/compilation? I'm a WCF n00b so any help would be greatly appreciated.
I do not think that it is possible to hijack the service calls as you describe. You may get thread problems as you wait collecting the calls.
What may work, is if you had a process that asked each widgit if it had any calls it wanted to make, collected all relevant information, made a single call to the server, then updated the widgits with the results.
I suspect that this opimisation is more work than it is worth. WCF calls from Silverlight are async.
Silverlight WCF Proxy async only?