views:

10

answers:

0

Consider a LOB site, where users work on a large shared dataset.

Using Wcf Data Services on the server side and the DataContext and DataView from the AJAX 4.0 client library on the client side to enable CRUD operations. Getting the data on the initial load is straight forward, just query the server and display the data (in a table for example).

Things get interesting when multiple users can change the same dataset concurrently. The AJAX client needs to check the server for changed content at an appropriate interval, and remove deleted entities, update existing entities and insert new entities.

The easy solution is just to do a full load of all data again on each “update check”, but that would be very wasteful of both resources and bandwidth. The obvious solution is to just query the server for the changed entities since the last time the client asked (the server could keep a track of that in the session state).

Allowing concurrent updates to the same dataset obviously presents issues like concurrency control (optimistic, pessimistic) which could be handled in many different ways depending on the requirements of the project.

One could build a custom javascript "data access layer" for the client, which would handle the synchronization and communication with the server. On the server, custom WCF/asmx services could be used. While both are non trivial to develop, they are not impossible.

It would however be fantastic to be able to reuse some of the great features already in Wcf Data Services and the AJAX 4.0 client library.

If I am not mistaking, it is possible to write a custom data provider for Wcf Data Services that could act as a layer on top of database and server side synchronization.

With that done, the AJAX client libraries DataContext would need to be updated as well to perform regular callbacks to the server to check for changes and perform the appropriate action based on whether the changes received contains updates, deletes or inserts.

Looking into the future, when WebSockets get broader browser support (currently only the beta version of Chrome has it, IE9 and the next version of Firefox should get it), the server will be able to push changes to the client, instead of the client pulling for changes.

My question is: Are the basic outlined solutions solid – i.e. are there any pitfalls or similar I should be aware of?

Any articles, blogs, etc. related to the topic is also much appreciated.

Regards, Egil.