Service Data Objects. Oh my.
Here’s some snippets from a whitepaper;
The core SDO specification provides the base APIs that are applicable to all types of data sources
The SDO architecture is based upon the concept of disconnected data graphs. Under the disconnected data graphs pattern, a client retrieves a data graph (i.e., a collection of tree-structured or graph-structured data) from a data source, mutates the data graph, and can then apply the data graph changes back to the data source. Most commonly, the update is performed with optimistic concurrency semantics, which means that if any of the underlying data was changed before the client applies the changes, the update is rejected and the application must take corrective action. Optimistic concurrency semantics is a natural semantic that serves most business applications well.
“Disconnected data graphs”? You mean like the Web? 8-). And optimistic concurrency? Who knew?.
Ok, come on now, this is just getting silly. A Java API for all this stuff is nice, but we’ve got Servlets, and it’s not nearly as complex as SDO. Compare and contrast DataObject (grr, no direct URI) to HttpServlet; the former is just missing the equivalent of POST (which would make it useful for operating on more than just data), but consider that doGet/GET on a servlet is equivalent to requesting that the state of a DataObject be serialized via Java serialization.
What am I missing? Why can nobody see this?