|
今天粗粗看了一眼SDO，略有理解。
SDO全稱Service Data Objects，是IBM提出的一個框架規范。SDO框架由三部分組成：DMS（Data Mediator Services），Data Graph和DataObject。DMS負責生成Data Graph，Data Graph包含一系列關聯的Data Object。客戶和DataGraph打交道，而DMS如何生成Data Graph又如何從Data Graph更新后面的數據則無需關心。Data Graph是Disconnected Mode的數據處理方式，即對其進行的修改操作，將不會立刻體現，需要將修改過的Data Graph由DMS來更新到數據源。Data Graph是通過log change summary來實現的。
在Spec中說道，Data Graph被序列化為XML也能從XML中被反序列化。這使得在Services和其Caller之間傳遞DataGraph非常直接。同時也提出了系統內部、系統之間數據交互的一致方式——通過XML序列化過的Data Graph。
Data Object可以被動態實現（程序里將看不見具體的Data Object類，比如Employee類，因此也無需定義XML Schema），也可以被靜態生成（例如預先建模后使用工具生成，目前IBM基于EMF的RI可以使用EMF來生成）。
DMS可以有許多實現方式，在IBm的SDO Specification中并沒有任何關于DMS實現方式的規范。實際上，DMS在SDO Spec V2.0里面已經改稱DAS（Data Access Services），我們發現這命名和DAO（Data Access Object）模式何其相似。不過這里是Service。那么可以想象在SOA中，我們可以提供這樣的DAS來提供數據并作數據更新。難道與DAO類似這將會成為一種SOA模式？
更重要的是，DAS可以在J2EE的各層都能被使用。你可以使用JDBC實現DAS用它做一個持久化服務層，你可以用EJB實現DAS并且暴露成Web Service……你甚至可以使用Hibernate、JDO這樣的持久化工具來實現DAS。
所以我們不可能混淆SDO框架和Hibernate、JDO等工具——因為后者只是持久化工具存在于EIS之上；也無需懷疑SDO的價值——SDO確實可以為整個J2EE應用尤其是SOA提供一個一致的數據處理方式。
明天繼續研究。希望能深化、糾正現在的理解。
|