How are callbacks implemented in WCF?
When making async WCF service calls, the service is able (and must) execute the callback received. This makes sense in general APM, but in the WCF case the callback is in fact executed on the client side which means the server in essense was able to execute client side code.
Can someone shed some light on how this is implemented? For instance, 开发者_开发问答when using an http binding, when the service executes the callback, does it begin sending back an http response which the WCF client deserializes as a message to execute the callback and the response is completed with the return of the End method of the async operation? Can the service call the callback twice
Thanks!
Edit: Just to make sure their isn't confusion, I am not asking about callbacks with duplex contracts, but the AsyncCallback passed in a contract like the following (http://msdn.microsoft.com/en-us/library/ms731177.aspx):
[OperationContractAttribute(AsyncPattern=true)]
IAsyncResult BeginServiceAsyncMethod(string msg, AsyncCallback callback, object asyncState);
// Note: There is no OperationContractAttribute for the end method.
string EndServiceAsyncMethod(IAsyncResult result);
Callbacks with HTTP protocol are implemented as composite duplex communication (WS-DualHttpBidning). It means that both sides are calling each other on different transport connection. When the client calls the service it sends HTTP request. The service processes the request and stores a callback channel for later use. Then it returns HTTP response which only confirms initiating request. It does not trigger a callback. The callback is triggered from the service by calling operation on the callback channel. It creates HTTP request which is sent from the server to the client. The client executes callback operation and returns HTTP response to the server.
This communication flow used two way message exchange pattern but duplex communication usually uses one way messaging. The server can call client callback as many times as he need (client's performance and inactivity timeouts affect this).
Composite duplex communication requires both client and server to be accessible (firewall settings for both sides). On HTTP client exposes its own endpoint which behaves like another web service. In contrast net.tcp has full duplex communication channel so both server calls and callback cqlls are performed on the same TCP connection.
Edit:
Sorry, I didn't understand your question. Async operations (AsyncPattern) are implemented on the server - the implematation is completely transaparent from client (wrapped by WCF service architecture). Client communicates in common HTTP request/response pattern and service can send only single response for each request.
WCF supports two levels of async processing - Async calls and Async operations. The former is implemented on client and service doesn't know about it, the later is implemented on the service and client doesn't know about it. These approaches are often combined in examples which can make confusion.
Each approach has its own porpouse. Async calls allow non blocking service invocation where client can execute other operations while service is processing the request (UI does not freeze). Async operations are for better scalability of heavy used services. Sync execution blocks WCF processing thread until execution completes while async execution allows returning processing thread to thread pool (so it can process another request) while operation executes some time consuming operation - usually IO or network communication.
In essence the communication is the same as the server call. The 'client' side basically has an endpoint with the callback contract so that the 'server' can call it. No magic.
The WCF client-side stack calls the callback method when it receives the HTTP response from the server. As Alex Lo said, the server is oblivious to this - it doesn't even know that the client-side code is using async calls: all it sees is an HTTP request.
I haven't studied the gory details but I imagine that the callback is made on an IO completion port.
精彩评论