Agile Ajax

GWT, Remote Models and the Need for Better Replication Algorithms

PESSIMISM, n.
A philosophy forced upon the convictions of the  observer by the disheartening prevalence of the optimist with his  scarecrow hope and his unsightly smile.

-- Ambrose Bierce, The Devil's Dictionary

I frequently crawl through the various GWT project hosted on Google Code, as well as the few that aren't (like the almost venerable GWT Widget Library). One type of solution that is emerging is what I would call model synchronization libraries. These build on top of the GWT-RPC mechanism and allow a synchronization of an object model on the client-side with a corresponding one on the server-side.

Right now there are two major choices available:

  • hibernate4gwt - Number one with a bullet. Elegant and powerful library that allows you to ship domain objects back and forth between the GWT client and the Java server, persisting changes, all at the cost of extending one class: LazyGwtPojo. There are two basic flavors -- stateless and stateful -- with a couple of different subflavors to support a variety of development use cases.
  • Gwittir - Developed by the two dudes who wrote GWT in Practice, this library provides domain object bindings without forcing a dependency on Hibernate (should we add "Hibernate infected" to our lexicon along side "Maven infected?").

It's clear why these libraries are gaining in popularity. The whole idea of writing applications in GWT is to have a commonality of language and domain model. You want to be consistent and not have to navigate the OO/RPC boundary every time you modify or retrieve your client-side model. (An additional alternative worth mentioning is IT Mill Toolkit 5, which as a server-side ajax framework with it's widgets realized in GWT, already has the client-server synchronization baked in.)

My first reaction after running through the code of these two solutions is that they are just begging for a security violation. For example, if you are depending on a version property to implement optimistic locking and this property is exposed in the domain object on the client side, a malicious user could override this safeguard by use of simple browser tools, such as Firebug.

On further reflection it seems that even if the security issues could be overcome, and as long as the users of these synchronization frameworks are not blissfully ignorant of the exposed mechanisms on which they are relying, these frameworks just begin to scratch the surface of what GWT applications will need.

First there appear to be a few simple gaps in these implementations (a penalty of the Asynchronous "A" in Ajax):

  • There is no ordering or reconciliation of synchronization operations. If I have two widgets that rely on two different models that intersect on some subset of domain entities, then it is possible to have underlying XHR requests execute out of order and produce conflicting results.
  • Update won't reconcile or be ordered with periodic "server-push" synchronization activities. In other words, a change and an update from the backend server may pass each other like two ships in the night.

The above problems would clearly be exacerbated in a slow network or server situation.

Second, simple record level optimistic locking is insufficient for many of the more sophisticated applications that GWT applications will eventually support. While I don't require anything as complex as the Bayou Replicated Database, a less simplistic approach to client-server synchronization that takes multiple users into account would be welcome. Yes, that's right. I said "client-server." If you don't recognize that we've left the Kansas of simple CRUD via HTML forms, then you are wandering through client-server Oz with your blindfold on.

For a good survey of data synchronization, see Optimistic Replication by Yasushi Saito and Marc Shapiro, ACM Computing Surveys, Vol. 37, No. 1, March 2005.

Technorati Tags: , , , ,

Comments: 2 so far

  1. Hello Dietrich,
    What do you think about this project : XSTM is an open source library which enables high performance object replication between processes. It is an object oriented Distributed Shared Memory, or a Distributed Object Cache.
    It has a GWT implementation.
    http://www.xstm.net/
    Didier

    Comment by dgirard, Thursday, April 17, 2008 @ 4:06 pm

  2. @Didier

    Sounds interesting. I will definitely have a look.

    DJK

    Comment by Dietrich Kappe, Friday, April 18, 2008 @ 2:14 pm

Leave a comment

Powered by WP Hashcash

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics

WordPress

Comments about this site: info@pathf.com