Basically you want to use RPC when you are going to consume and send data on initialization and based on user interaction (ie: pull). You want to use FDS when you need to notify a client to update its data based on a server event, or keep data synchronized between clients (ie: push). There are other reasons why you might want to use FDS, like recordset paging and whatnot, but as a rule of thumb, use RPC (esp. Remoting) for pull and FDS for push.
Of course, you can simulate push in Remoting using polling, but you will find that it's a pain to keep everything in sync for more than basic functionality. And of course, you can do pull over FDS, but it has a major learning curve, requires knowledge of Java as opposed to <your favorite language>, and is a bitch to deploy, compared to, say, using amfphp or Fluorine. Patrick jeofmoyster a écrit : > > I'm looking for any information on why FDS is better than HTTPService > or WebService. Or better phrased, WHEN would one prefer FDS over the > other two for reasons other than publish/subscriptio n? > > I'm working on determining the best way to go with an architecture. I > can tie Flex applications to Java, .NET or PHP API's for our back-end > systems, but I'm wondering whether to go with a home-grown > approach/WebORB vs. FDS? Does serving Flex apps from the FDS server > reduce bandwidth or make for more efficient delivery? Is polling > really terribly detrimental compared to data pushing? Is FDS amazingly > faster, better, stronger than going with a free option. How much can > an FDS server take before we need to build out the architecture? > > Basically I need to have a good list of WHY we should use Flex Data > Services before I start dropping hundreds of thousands of dollars on > the architecture. > > thanks, > /j > >
