BEA的
中討論了SDO設計的動機并從動態數據API、數據類型自檢API、數據跟蹤變化API三個角度展開。
動態數據API主要是因為Java是靜態（強類型）語言，不能在運行時將額外的字段或者方法添加到對象的實例中。
==============
針對這個問題其提出DataObject概念 DataObject do = new DataObjectImp(); do.set("name","tester"); do.get("name"); 這個實際上可以對應成Map的功能;
Java的動態數據API包括ResultSet、DOM等API，其對取的值應該具備類型自檢的功能
==============
這個功能在JDK5.0中已經具備，自動解箱功能（待確定），而且Spring中已運用的得心應手，因為Java本身提供了java.beans包。
數據跟蹤變化
==============
這點在Hibernate模型中已經有實現，通過新對象和原有的快照的對比
懷著這些疑問，繼續查閱了相關資料和規范，其中在DeveloperWorks的“服務數據對象簡介”給出了解釋，雖然文章屬早期系列
為什么要使用 SDO？
對
于服務數據對象（SDO），大多數開發人員要問的第一個問題就是為什么要使用 SDO。難道 J2EE
本身還不夠龐大、不夠復雜（而且難以掌握）嗎？Java 環境中不是已經有其他支持 XML
的框架了嗎？所幸的是，該問題的答案能夠讓我們多數人感到滿意：SDO 是作為簡化 J2EE 數據編程模型的方法出現的，它能夠讓 J2EE
開發人員把更多的時間用于應用程序的業務邏輯。
服務數據對象框架為數據應用程序開發提供了統一的框架。通過
SDO，您不需要熟悉特定于技術的 API，就能訪問和利用數據。您只需要知道一種 API，即 SDO
API，它允許您處理來自多種數據源的數據，其中包括關系數據庫、實體 EJB 組件、XML 頁面、Web 服務、Java Connector
Architecture、JavaServer Pages 頁面等。
并展開了各種技術在"撥開SDO(Service Data Object)唬人的光環"中各種技術的對照.這個文章可謂是非常及時和有力的.
其中提到的DMS（數據中介服務）、Data Graph（數據圖）、DataObject（數據對象）等概念對于前邊提到的Hibernate也有很大的規范指導作用。DMS從DataSource(數據源)獲得到數據,將數據以Data Graph(數據圖)的形式存在,即是數據對象樹,SDO客戶端遍歷Data Graph獲得Data Object使用.DMS直接屏蔽了數據來源,所以SDO客戶端看到的數據可能來自多個數據源（這點從語義上和Hibernate對應部分好像沒有什么大的區別）。SDO客戶端從DMS取數據，也可以把修改體現在DMS中，并通過DMS進行保存,具體保存的形式也被DMS屏蔽，也就是數據源的形式，可以是DBMS、XML等。