|
今天粗粗看了一眼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提供一个一致的数据处理方式。
明天继续研究。希望能深化、纠正现在的理解。
|