Comparing SDO (JSR-235) to Detachment in JDO 2.0 (JSR-243)
Nadav Wiener: My take on SDO
Simplify and unify data with a Service Data Objects architecture
SDO is not meant to replace existing persistence mechanisms, but instead to leverage their use providing a uniform programming interface. Instead of learning multiple APIs and frameworks, a programmer will typically concentrate on one unique programming model (SDO). Behind the scenes, SDO-capable tools and DMS will deal with all the specific and cumbersome data source semantics. So without even knowing it, an SDO client, through DMS, could interact with JDBC, Java Data Objects (JDO), Hibernate, Entity Enterprise JavaBeans (EJBs), Web Services, or any other data source.
You're right, there's not that much material out there.
So to answer your question, I (quickly) written a blog entry comparing SDO with EJB 3 (which largely based Hibernate ORM because they seem to have ignored the lessons learned with JDO, so it should answer your question).
It's really a chalk and cheese comparison. ORM technologies are for Java developers that don't/can't/won't like to deal with relational databases.
SDO is really just a simply XML API for accesses
Both are data persistence technologies, but that's about all they have in common.
I hope this helps.
You might also find this comparison of SDO and DAO to be useful:
For other data persistence technology comparisons, you can look here
DAO versus ORM
JDBC DAO versus SDO versus EJB CMP
I think the general answer is that it is impossible to say that one particular data persistence technology is 'the best' and that the appropriate choice depends on your particular requirements.
Originally posted by M Burke:
I have been asked to discover the pros and cons of using SDO.
I forgot to provide a link to a list of pros (sorry no cons, I'll do the pros and cons in a blog when I've got time)
And in the interest of vendor neturality, you can find a good feature list for an SDO product here: