Review of SDO for ECMAScript

[barreto@adobe.com]

An initial analysis from my investigation into SDO@ECMAScript. 

Having looked into the possibility of Service Data Objects for ECMAScript, this would implement the SDO framework for representing model objects in the browser/RIA. In ECMAScript environments the model can be provided by delivering the server data model into the browser, with an ECMAScript interface. The client model objects can be introspected and accessed using both strongly and loosely typed methods, and any changes to client data could be stored in the logs of the corresponding SDO data graphs. The view and controller would act against these model objects. 

Model deltas would be serialized into HTML forms which represent a hierarchical view (DiffGrams) of any model objects that have been created, updated, or deleted while the application user was using the browser or RIA to manipulate the data. Only those objects which have been affected are present in this DiffGram. For example, you had one hundred records in the model, and you changed three before submitting to the server, the DiffGram would only contain information about the three modified records. 

The server code would then inspect the DiffGram and update the server model objects accordingly. The business logic responsible for synchronizing the client and server model using such DiffGram would still need to be implemented by the application developer.

Each type of model object would require a handler (DiffHandler) to contain the necessary function to take a model object of that type, the corresponding section of the hierarchical view of the model deltas, and update the model object accordingly. Once all the server model objects have been updated by the DiffHandlers the data is ready to be sent back to the browser for further modification.

Technically this is a straightforward effort. With ECMAScript support for "dynamic" method and field-level interception, this certainly feasible either as an entirely native or delegated (e.g. to Java SDO) implementation. 

However, the use case is one to be argued. The argument for this would be to have the RIA/browser client to use generic datasets from XML, using an object model which the client can manipulate and handle merge and exceptions from concurrency. The RIA/browser client can work with this dataset and reflect changes back to the server.  

The argument against is that there is a strong case to make these interactions much more corse grained, pull messages down from the server, deserialize them as an object graph and inject change tracking capabilities. These then can be manipulated over a session without hitting the server, then queue the DiffGrams and send them to the server.  The server decomposes the queued messages and sends them to appropriate services for handling. This way, the structure of UI flow and pages are decoupled from he server environment.