One of the hard problems we need to solve now is how to generate the ChangeSets from our Domain Objects. What I would ultimately like to happen is that there would be a service out there somewhere that I can push RDF/XML to (in an Atom stylee) This service would be clever enough to pull out the CBDs from the graph, see if they exist in a TripleStore and generate ChangeSets for all of the pertinent resources in the XML. If the goal was just to roll back the store to a given point in time this wouldn’t be so tricky, each update to the store would just be modelled in a ChangeSet (which could then be Applied/Reverted). Where the problem lies for us is that we need to be able to roll back the representation of a DomainObject that happens to be represented in our store. To split the changes into meaningful chunks that can be Applied/Reverted independently is tricky. Should we try to decompose the XML received into CBDs and generate a ChangeSet for each of them? Possibly. I think for the time being (time constraints etc) we may take a simple, less service-y route. Our Domain Objects may be self-aware, meaning that they know if and how they’ve been changed during their life. In this scenario, a ChangeSet can be generated using the DomainObject’s inbuilt diff knowledge. It makes for a much tighter coupling between the ChangeSet stuff and our application, but I think in the short term it might be simpler to implement.
License
This work is published under a Creative Commons Attribution-Share Alike 2.5 License.