Kirstan Vandersluis wrote: > I thought initially that the cache idea could be valuable in the > integration/mediation layer. But you have to worry about keeping > the cache consistent, which can be complicated and risky. In > addition, a typical RIA environment will let you cache retrieved > data to some extent already. For example, you might call a data > service to retrieve a customer record, which you then display in a > multi-tabbed view. The user sees only a subsection at once, when in > fact the entire customer record is available on the client side. > The cache conherency problem is isolated and manageable in this > case, and a straightforward optimistic concurrency strategy can be > used if updates are required. Seems like a viable strategy to > accomodate RIA without stretching the SOA too much.
We created a distributed data synchronization layer in a recent project that lets everyone have a consistent view of data as it changes over time, without having to "look" for changes. It uses a transactional delivery system that only updates everyone as the transaction on the change commits. It uses a GUID operation identification system that allows things to broadcast around and things only get seen once. This allowed us to use postgres as a backing store, and have clients connect to "any" server to make their edits (and observations) with everyone staying in sync. We have a "key" generation service too for inserts that allows domain tables to be used and the keys into those tables to be guaranteed unique as well. Works flawlessly. It's written in Java and exploits cool features such as InvocationHandlers and dynamic proxies to put the GUID filtering on top of objects without having to redesign everything to make it work. And of course Jini is in the mix for transactions, leasing and service discovery. Gregg Wonderly
