1

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?

Daniel
  • 33
  • 4

3 Answers3

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.

Mike Perrenoud
  • 66,820
  • 29
  • 157
  • 232
  • Would a static IP be necessary for exposing endpoints? As a last resort would keeping the connection alive such as DurableDuplex be an option? – Daniel Jun 19 '12 at 21:42
  • I would depend on how "mission critical" these client endpoints were. For example, I can expose a WCF endpoint from my computer at home over the IP my ISP leases me. That IP is "static" for the timeframe it's leased. If these client endpoints were "mission critical" then I would recommend getting static IP's for them OR you could write a .NET program on the client that ran and verified the IP on a schedule and sent that information to the server so you could keep you clients IP addresses updated. – Mike Perrenoud Jun 19 '12 at 23:38
  • Thanks for the input. I may be able to just use the wcf duplex to keep probably 30 maximum connections open and just push data when needed. – Daniel Jun 22 '12 at 12:47
1

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.

Ron Jacobs
  • 3,279
  • 2
  • 18
  • 16
  • Ron, I've viewed a few videos and articles of yours -- very informative. The queue setup may be the way to go, but I'm trying to cut down on all the polling to the server and queries to the db to see if there's data available for the client. – Daniel Jun 20 '12 at 14:05
  • @RonJacobs Now that's an interesting approach and would be really light weight honestly. I'm going to be keeping that in mind. – Mike Perrenoud Jun 22 '12 at 16:32
0

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.

Rich
  • 2,076
  • 1
  • 15
  • 16