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
Related
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.
I am designing a WCF service with callback, but my implementation of the callback function never gets called. And I am confused about the generated service proxy, so please help.
Here is the scenario: in the server side, I defined the service interface IMyService and callback interface IMyServiceCallback, I also implemented the IMyService in the server project. Besides the server project, I surely have another client project, to which I added the service reference in VS. And I implemented the IMyServiceCallback interface on the client side. So here comes the problem: when I am debugging it, the function never goes into my implementation of IMyServiceCallback and of course the desired result never comes out.
And this is I where I got confused: when I added the service reference in the client side, it actually generated three interfaces on the local: IMyService, IMyServiceCallback, and IMyServiceChannel plus the client proxy class. And in my local implementation of IMyServiceCallback, I declared the class to implement the local IMyServiceCallback interface, not the one from service side. Could this be the problem? Why is there two declarations of the interface under different projects(and hence different namespaces)? The reason I implement the client side interface is, if I implemented from the server side interface, it would give the error: "InstanceContext provided to the ChannelFactory contains a UserObject that does not implement the CallbackContractType error" when I tried to call the service. And another confusing part is, on the server side if I declare the callback interface name as IMyCallback, or anything else, instead of IMyServiceCallback, the generated interface on the client side would still be IMyServiceCallback, which is the name of the service interface plus the suffix "Callback". And in this situation I also got the "InstanceContext provided to the ChannelFactory contains a UserObject that does not implement the CallbackContractType error".
I guess there is something that I misunderstood about the "add service reference" and how I should implement the interface(which one to implement). Could anyone help me? Thanks!
Updated:
I somehow fixed the problem. Firstly, the two declarations is fine is desired. The local client will need to implement the local interface, which is generated when adding the service reference. And my problem was that I also defined a DataContract but the generated reference file didn't have it. It could either because I had added the assembly of the service project as reference(somebody said in this case add service reference will not generate the Datacontract) or because I was missing DataMember attribute. But anyway, after I fixed both parts, the function is working now.
When you "Add Service Reference" and generate a proxy, it is totally separate from your service implementation. Remember, you may be consuming a service that you have not written and do not have access to the service source code.
The client code should use the client generated interfaces. If you change your service, you need to regenerate the proxy.
If you find this too messy, and you know you will always control both ends, you can share the service interfaces in a common assembly and generate a proxy class at runtime using DuplexChannelFactory.CreateChannel().
As for your problem, I can only assume you are not registering your callback properly. This is covered here.
if you want publish , you must implement IMyServiceCallback and IMyService together in same project.
if only subscribe , you must implement IMyServiceCallback interface
I fixed the issue when my callback instruction was embedded in a function call.
I learned that placing the callback in just a method that does not return a result works fine.
However, when the callback instruction is placed within a function I ran into timeout issue.
I resolved it by using a backgroundworker thread within the function being invoked:
public static IMyServiceCallback Callback;
.
.
.
TaskStateData taskStateData = GetSomeData();
BackgroundWorker backgroundWorker = new BackgroundWorker();
backgroundWorker.DoWork += (se, ev) =>
{
Tuple<OperationContext, TaskStateData> data = ev.Argument as Tuple<OperationContext, TaskStateData>;
var operationContext = data.Item1;
if (operationContext != null)
{
Callback = operationContext.GetCallbackChannel<IMyServiceCallback>();
Callback.OnCallBack();
}
};
Tuple<OperationContext, TaskStateData> payload = new Tuple<OperationContext, TaskStateData>(OperationContext.Current, taskStateData);
backgroundWorker.RunWorkerAsync(payload);
I wrote some WCF server that support SOAP.
Now, i need to add some new request ... to add support in REST in some of the method that are supported SOAP.
I don't know how to do it.
Actually one of those method need to change to support REST.
How to do it ?
Add WebHttpBinding and a new service contract interface with the relevant REST methods annotated with UriTemplate. Encapsulate your business logic in a class that is used by soap service class and the rest service class both.
Is it possible to pass a delegate to a WCF remote object from the client and have the remote object execute the delegate?
I would guess not since a delgate is a function pointer for the client process.
My goal is to have an interface structure that I can "subscribe" to events from a client to the interface. I would pass a delgate from the client to the interface and I want the interface to be able to execute the event.
The idea is to have the ability for the interface to be loaded either the assembly or remotly and have the code work the same.
If I can't pass the delegate how can I implement an event structure?
not a "delegate" in C# per se, but in WCF you have duplex bindings to enable call back from the service side to the client side
http://msdn.microsoft.com/en-us/library/system.servicemodel.wsdualhttpbinding.aspx
I doubt you could come up with a cohesive way to pass a delegate from a C# client to a Java service implementation and have it properly executed......
WCF is not a strict .NET implementation and thus has to deal with interop issues. It cannot rely on the assumption that both ends of the conversation are in .NET - that's why you shouldn't throw around custom exceptions between server and client either (exceptions are a .NET construct) - you need to use SOAP faults instead (which are interoperable).
So I don't think what you want to do can be done with a delegate - you'll have to come up with another way to achieve your goal.
Marc
I have a RESTful WCF service with many different functions. For each function I need to call an authentication method that I have written. I can manually call this method on every request but I was looking for a way to force the WCF engine to call this method before these functions are entered. Does anyone know if this is possible?
Cheers
You could use the "Custom Behavior" approach.
You would need to write a Class that implements IDispatchMessageInspector. The following MSDN magazine article gives a nice explanation of this: Extending WCF with Custom Behaviors (link points to Wayback Machine cached copy; downloads likely don't work).
To force WCF REST Service to first call a method especially if it's for authorization
customize/override CheckAccessCore method of System.ServiceModel.ServiceAuthorizationManager
refer: http://msdn.microsoft.com/en-us/library/ms731774(v=vs.110).aspx
If it's for authorization, can't you use the built in services?
For instance, there is the PrincipalPermission attribute. Does that help in your case?
You could think about creating a WCF routing service. You would call a fixed endpoint - your authentication method - and then from there on, route your calls to the actual methods, based on some indication in the request.
For .NET 4, the Routing Service functionality will be included into WCF out of the box.
What I don't know is how that all matches REST, though.
I came across this post, while searching for the same thing.None of the answer's were simple/quick solution so if you just want a function to be called before every method then you can do what i just did:
I created a zero argument constructor:
public class myService : ImyService
{
myService ()
{
ConnectToDatabAse();
FunctionYouWantToCallBeforeEveryMethodCall();
//Add here more
}
}