Consider the problem of a group of line-of-business data that is read-only but can shrink, grow and change frequently (think product catalog) that needs to be synchronized with a large number of occasionally connected smart clients. What mechanism could be used to perform the synchronization? You could certainly use some kind of push technology, but that would most likely require the server to track when each client was last updated so that only the appropriate records are pushed when the client connects. You could use some form of queuing to queue each changed record so that the client can fetch the queued changes when reconnecting, but this again requires the sever to have knowledge of each queue for each client and additionally, the order of processing the queued changes becomes important. For purposes of scalability, though, I generally favor pull based technologies.
As an example, consider a service that publishes a "directory" containing a brief synopsis of each valid record in the list of line-of-business data, how to fetch details about the record, when the record was first published and last changed. A client could fetch directory and, knowing when they were last synchronized, could fetch only the records that were new or needed updating, or given the lack of a directory entry those that required removal. Well the directory service that I described sounded a lot like RSS to me. After investigating the RSS and ATOM syntaxes, I found that either was sufficient to meet the needs of my proposed directory service. I built a simple proof of concept RSS feed that would front a data store which was coupled with a REST-like GET only web service to fetch record details. The client would periodically fetch the RSS feed, and then fetch only the new or stale records. The proof of concept indeed worked very well, and although I did not perform any performance testing, I have no doubt that it would scale better than any of the other approaches previously discussed for reasonably sized datasets. The primary issue is that the solution, although it employed standard protocols, involved a lot of custom code and since it used the standard protocols in non-standard ways could (somewhat justifiably) be described as a "hack".
Well earlier this week I heard about Microsoft Live Labs taking the wraps off a new technology that they are calling FeedSync and it sounded like at least half of the solution to my problem. Well today comes word that the MS lab folks and I have some common ideas. The folks behind the Microsoft Sync Framework have blogged about how FeedSync and the Microsoft Sync Framework can be used together to "publish or consume the contents of your data store in the form of an RSS or Atom feed". Whether or not you plan to implement the Microsoft Sync Framework in a smart client project, the fact that it supports FeedSync validates the approach of publishing (mostly read-only) line of business data in the form of RSS and ATOM feeds.