WCF Web Services and Client communication

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

How about using a RSS/Atom feed to send the notifications back to the client?

Answer 2

Allan,

Can you explain this idea on more detail?

Thanks
Ian

Answer 3

 I would also like to address some of your concerns:

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

[By connection, do you mean network connection, or connection to the service, if network you can always monitor the network card. If to the service, it is pointless, always strive to be stateless and per call, what can the client do anyway if the service is down?, he will do a normal call get a communication exception and deal with it in his own way as he needs to.]

· 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.

[Queued does not mean that it needs to be a period of time between writing and reading the message, it could be instantaneous, the queue is nice because you do not lose any messages if either client and service are offline. A queued pub/sub would be the standard solution for this problem provided you could enforce the clients’ environment, i.e. does the clients policy allow them to add queues on a client machine, firewalls etc.  ]

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

[No more than normal]

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

[A permanent connection would suggest a client/server model and will not scale well.]

The idea is that you create a service that exposes a feed that is based on the events that you wish to notify the clients about, so an event may be “New Client Added” and you can even include an identifier as part of it.

Clients who subscribe to the feed get the updates as per a normal RSS/ATOM feed, and if they decide to take action the call can be redirected to the service that deals with it along with the identifier so the service can get the info it needs to act.

Using new features released with .NET 3.5 developers can easily create WCF services that expose syndication feeds using these standard syndication formats using  WebHttpBinding and WebHttpBehavior.

Windows clients can work with RSS and Atom feeds using the new syndication programming model introduced with .NET 3.5. This model greatly simplifies the development effort for any application working with syndication feeds. Browsers typically have built-in mechanisms for presenting RSS or Atom content, if users browse directly to the address of the feed. Web 2.0 clients working with syndication feeds programmatically may prefer to receive JSON formatted feeds.

Cheers
Allan