Service Data Object (SDO): with rich DAO/DTO featureset, a standardization efforts, and support from J2EE AS vendors, ready to take off?

Service Data Object (SDO) specification provides a uniform access to heterogeneous data sources like XML, database, web services etc. Even though there are already plenty access mechanisms and specifications like JDBC, JAXB, JDO, ADO, Entity EJBs, etc, SDO still stands out due to some useful features.

SDO specifications provides:

• Uniform access APIs to heterogeneous data sources
• Multi-language
  
• Maintains a disconnected data graph.
• A dynamic APIs
• Generate static APIs from the data source’s schema or UML.
• Xpath based navigation through data graph
• Change summary
• Validations and constraints
• Metadata access which is useful for tool builders.

SDO comparision with other data programming technologies
(table source Ref . 2 Next Generation Data Programming http://www.osoa.org/download/attachments/287/Next-Gen-Data-Programming-Whitepaper.pdf?version=1)

	Model	API	Data Source	Metadata	Query language
JDBC Rowset	Connected	Dynamic	Relational	Relational	SQL
JDBC cached Rowset	Disconnected	Dynamic	Relational	Relational	SQL
Entity EJB	Connected	Static	Relational	Java introspection	EJBQL
JDO	Connected	Static	Relational + Object	Java Introspection	JDOQL
JCA	Disconnected	Dynamic	Record Based	Undefined	Undefined
DOM & SAX	NA	Static	XML	XML Infoset	Xpath, XQuery
JAXB	NA	Static	XML	Java Introspection	NA
JAX-RPC	NA	Static	XML	Java Introspection	NA
SDO	Disconnected	Both	Any	SDO	Any

These rich features offer several benefits to different players:

For software architects and programmers it is useful to have a uniform representation of various data sources. As many other APIs a separation of data source specific APIs and business logic is highly desirable. With SDO, the interaction with data source is abstracted from application developers. Those who handle the persistent layer or provide a mediation framework would deal data sources.

A uniform access, metadata and dynamic APIs are very useful features for tools developers.

A disconnected data graph, a data change summary and optimistic concurrency would help application builders to build SOA oriented applications where disconnected client can manipulate data and then save to the data source.

Standardization of SDO:

In Nov 2003, JSR 235 was filed to standardize SDO in JCP. Unfortunately, due to some legal issues this JSR never made any progress.

However, in addition to BEA and IBM, many other firms like Oracle, SAP, etc joined the efforts to develop SCA and SDO specifications. As a result of this collaboration, Open Service Oriented Architecture (OSOA), a much mature version 2.0 was introduced in 2005. While this collaboration made a very good progress, the specification would not be standardized immediately. It would need to be submitted to some standardization body like OASIS, which would follow its own process to standardize. However, with the agreement of all the collaborating companies, the specification would serve as an intermediate but ‘de facto’ standard.

With Sun Microsystems joining the SDO and SCA efforts in July 2006, I hoped a revival of JSR-235. However, the SDO 2.0 was never submitted to JSR 235. Moreover, with multi-language support, the SDO 2.0 specification differed from SDO1.0.

Implementations of SDOs: In WAS6.0, IBM converted its WDO to SDO 1.0, while BEA added a SDO 1.0 based implementation in its Liquid Data. Some other vendors like Rouge Wave (HydraSDO) and Xcalia (XIC), SAP (NetWeaver J2EE 5 AS) introduced products supporting SDO1.0 while Oracle and others announced works based on OSOA’s latest specifications of SCA and SDO. Oracle added SDO support in its recently announced opensource Toplink.

Though SDO 1.0 introduced basic architecture and interfaces like DataObject, datagraph, it was incomplete due to a lack of specifications for Data mediation Services, a key architecture module, and other features. Thus it lost some portability across the implementations.

An Open source community is currently working on a project named Tuscany that would provide an implementation of SCA and SDO. Though there are high hopes about this effort, it still has a lot to be added.

Industry adoption of SDO:

For many reason’s SDO took a long time to gear a momentum. Most importantly it is a specifications, which did not get immediately standardized when it was introduced. Moreover, in the initial period, not all J2EE application vendors supported it. So the implementations based on the SDO were not portable across the J2EE application servers. Since the JSR-235 was stalled, the SDO lacked a wider visibility in Java community.

SDO: A plane ready to take off?

SDO version 2.0.1 is much more mature. It has added more languages like C++, PHP etc. There are plans to support C and Cobol too. However, there are some pieces in SDO architecture that are still scoped out of specifications. Most important scoped out feature is Data Access Service. If different vendors implement the DAS in making SDO importable on other application server, there would be roadblocks in its momentum. The success of SDO depends on its support on all J2EE Application servers.

SDO offer richer functionalities like change summary, dynamic APIs and metadata however these rich features should be implemented so that a performance of SDOs in access, updates and serializations is not affected.

As we already know, there are a lot of competing technologies and alternatives to access Data. Microsoft has ADO in its stack. WCF specific implementations may continue with the same. Many applications in Java spectrum may still prefer POJO,JDO, JDBC, JAXB for optimal direct access. However, features like disconnected model, change summary, multi-datasources would provide a sweet spot to SDO in the SOA world. SAgain, in that case, SDO need to have proper integration story working with current popular frameworks like Axis, WSIF, JAX-WS.

SDO may see a better support in SCA based solutions. Specifically some SCA implementation and ESBs may increase the adoption of SDOs. BTW, SCA itself does not strongly advocate SDO. One can have an implementation of SCA without SDO. However, within a SCA composite, one may find optimal use of SDOs as a DTOs transferring data on 'wires'.

Since applications leaders like Oracle and SAP are on board of SCA and SDO, if their applications also get aligned with these technologies, there would be a boost in arm.

Today, SCA and SDO have received a wide support from all major vendors of J2EE Application Server. If they deliver on their promises by adding SCA & SDO in their stacks, usage of SDO itself proves a "practical" advantage over other DTO/DAOs and SCA-SDO specifications get standardized, we would see a wide availability of products, tools and resources that would enable a large pool of developers and architects to develop solutions and products based on SDO. Finally, it seems that most of the stars are getting aligned! Hope for the best.

References:

[1] SDO2.0 specifications

http://osoa.org/display/Main/Service+Data+Objects+Specifications

[2] SDO whitepaper

http://www.osoa.org/download/attachments/287/Next-Gen-Data-Programming-Whitepaper.pdf?version=1

[3] SDO1.0 specifications:

http://xml.coverpages.org/IBM-BEA-SDOv10.doc

SDO
JSR-235