Decoupled asynchronous calls — WCF or WF

Question

I'm developing a client / service project in which the client will be behind a firewall with an IP that will not be static. The client would call into the service. Then the service would, at some later time potentially hours later, contact the client when it had data for the client. There will be many clients per service.

There were a few WCF samples that I looked at that appeared to keep the connection open, which I would prefer not to do. In a few of the WF examples I saw it looks like the service can contact the client after the timeout has expired, presumeably on a different connection.

I'm very new to these technologies, but have spent countless hours researching and testing samples. Seems the more I read the less clear I am about the best solution. Would WF be the best solution for me, or is it possible to achieve my desired results with WCF?

Answer 1

If you want to contact the client, but not leave the connection open, the client is going to have to publish an endpoint for you to use. This may not be the client directly, but rather you might have the client register itself with an internal server, then that server exposes the endpoint, and routes the call to the client when it receives data from you.

But, you're not going to be able to contact the client without them exposing an endpoint somewhere.

Does that make sense?

WF vs. WCF Also, bear in mind that WCF is the communication framework in which endpoints can be exposed and consumed. WF is a workflow framework that can expose itself via a WCF endpoint. They are completely different technologies and one does not depend on the other - as WF can run without WCF.

Answer 2

A better solution would be to use a Queue for this scenario. I would use ServiceBus and post messages to the queue that the client can pick up when they are ready. You could also use MSMQ to do the same or even a database can serve as a queue.

Answer 3

Keep in mind that WF is still exposed to the outside world via WCF. Considering the "hours later" aspect of it, there are really 2 aspects of it: How the back and forth between client and WCF service works and how the process which does the processing itself (the portion that takes a couple hours). The second might make sense with WF, as a long process. The first might be better handled with a framework like SignalR.