Service Data Objects
I have been reading the specs for the Service Data Objects (here and here) a bit puzzled. The scope of the spec is daunting: "You need to know only one API, the SDO API, which lets you work with data from multiple data sources, including relational databases, entity EJB components, XML pages, Web services, the Java Connector Architecture, JavaServer Pages pages, and more." One API to rule them all. All laughing aside I really do not understand the effort: don’t we already have JCA, JDO and JPA? Who needs another persistence API? Who needs this persistence API to be platform-agnostic, so that your JEE app can use a .Net app as data repository?
The only interesting thing about it is the disconnected data graph, but I think you could abstract this behavior in JDO or in a DAO. One thing I find odd about this implementation of a disconnected data graph is the fact that it comes with a locking strategy built in (namely optimistic-locking) when it would have made sense to be able to specify this declaratively or at least provide for ways to plug in your own data layer. If you have 2 sales reps working remotely on the same purchase order you should provide for collision detection or resolution if one tries to override the other’s order when it re-commits it.
What I find the worst in this spec is granularity of access between 2 applications tied together thru SDO. SDO’s purpose is to abstract the data layer to the level that you can plug in any data source, including another application. This in turn means that an application has access to another application’s data layer. Access to an external application data layer is a very fine grained access to another application, which is a big no-no. Think just about the amount of coupling that you create between 2 applications, or services if we want to use the buzzword du jour. Access between applications should be coarse-grained, not fine-grained. An application should publish its coarse-grained behavior (which should not be prone to change) not its data layer. A data layer that gets published and used by external applications will evolve with great difficulty because the dependencies involving it are enterprise-wide and not application-wide.
SDO appears as the data layer of a client-server application in heteregenous environment, however I am skeptical about how useful or how needed it is. You could say that it is tied to the re-emergence of the rich client, but I am neither sure that this rich client is really needed nor that it needs these capabilities.
I don’t know. The more I read about it, the less I like it. I’ll be watching it with interest, but I am betting against it. The main reason for betting against it is that the effort for implementing SDO is huge (implementing the Data Mediator and the Data Graph in a heterogeneous environment is not trivial at all) while the benefits really modest. I would be surprised if it achieves any penetration in the enterprise space.
