WCF Web Services and Clients

Question

I have a few questions about WCF services that I would appreciate comments on. I have read a lot of material on how to apply WCF services to real-life scenarios, but there are a lot of contradictory opinions.

We have a data service which is intended to be nothing more than an interface to a back-end data storage. There are a number of clients to this data service which should be notified when data held by the data service changes. These clients subsequently may request data from the data service based on these notifications. We would like to support up to say 2000 clients (not a web-based solution, but could be a large dispersed network).

My concerns:

· If the connection is lost between service and client, the client should know immediately.

· The service should notify the client of data changes within a short amount of time. The notification cannot be queued and received much later on.

· We do not want a heavy amount of configuration work at the client end to get it to work with the service.

· We do not want a permanent connection between the service and client if it does not scale well.

The approaches we have looked at:

· MSMQ

· Duplex Binding

· Polling for events (including Silverlight 3’s new polling binding)

· Subscribe/publish approach.

We have found drawbacks with all of these, and there does not appear to be one optimal way of doing what we want.

Any help would be appreciated.

Thanks Ian

Answer 1

This isn't exactly what you are looking for, but when it comes to event-based service architecture, the person (or blog) to consult is Udi Dahan.

His article Event-Driven Architecture: SOA Through the Looking Glass provides a pretty good overview on his approach to these matters. Although that article doesn't explicitly discuss WCF, he knows a lot about WCF as well, so I can only recommend skimming his blog to see if something strikes you as useful.

Answer 2

The only way to accomplish your first concern is to violate the fourth: for the client to know that the connection is broken would require either a constant polling mechanism (which defies "immediately") or keep an open connection. WFC doesn't lend itself to open connections, so the first concern will be a point against using it.

Your second concern will introduce scale issues no matter which technology you choose. Stateful connection patterns will be much harder to implement and scale in the long run, so you might want to review whether the concerns are full business requirements or just preferences.