orange

拍完饶老师的 mp 了，干点正经事啦。想到仔细看看 SDO 有两个动机：一是我在 Business Modeling 的时候负责的是 Business Item 和 Oragnization ；二是响应 Chuanbo 同志的号召，进一步深入学习 SOA 中的概念 :-) 顺便说一句，大家建模的时候记得把 process 和 Business Item 、 resource 结合起来，不然 WBM 中的 Swimlane mode 岂不是用不到了？

SDO 是一种应用程序编程接口 (API) ，可以简化和统一对异构数据的访问。显然， SOA 的一大目的就是将异构的系统集成起来（就像我们的 project ），那么不可避免地需要接触到不同格式的数据。 SDO 就是用来提供一种独特的访问异构数据源的 API ，同时也可用于数据处理的其他方面。

SCA （ Service Component Architeture ）是一种新的编程模型，它将有相同功能和作用的 Service 封装成 Service Component ，并定义输入（ import ）和输出（ export ）。那么输入、输出以及组件内又如何与 Service Component 通信呢 ？ 答案是 SDO 。之所以采用 SDO 的原因有很多种，很重要的一点是一旦检索到信息后， SDO 会提供一种统一的编程语言进行数据操作，简单的说，就是通过使用 API 及其接口， SDO 客户机可以读取数据和修改数据。

  下图是来自 http://www-128.ibm.com/developerworks/cn/webservices/ws-sdoarch/ 的一幅图，它清楚地展示了 SDO 的总体构架。首先需要解释的是左边的 DMS （ Data Mediator Service ），它并不属于 SDO 的一部分，但是 SDO 需要使用它和数据源进行通信，在这里不赘述。

右边的则是 SDO 的主要部件了。数据对象（ DataObject ） 是保存数据的组件，简单地说，它是由属性的键 / 值对组成的，每个值都可以是原始的数据类型，或者是另一个数据对象。感觉和 Hash table 差不多。据规范上说，这样的设计可以使熟悉 JDBC 的人很方便地通过名称或索引来访问它的属性值。数据对象图（ DataGraph ） 是一个描述数据的分层结构，它包括一个数据对象树和一个更改摘要 (Change Summary) 。更改摘要记录了数据图中所有数据对象的历史更改信息。

数据图中的所有对象扩展了可序列化的 Java 接口，这样，数据对象树的序列化变得很简单。序列化完成后，数据图由三部分组成：模式、序列化的数据对象和更改摘要，数据对象部分包括了树型结构和对象的值，而更改摘要则列出了序列化完成前数据图的所有更改，原始树结构中未更改的数值则被省略了。

一旦构造好一个数据图，我们就可以使用 SDO API 来遍历树结构，并访问其中的元素。规范的作者选择了使用 XPath 语言来完成这一工作。还是回到 http://www-128.ibm.com/developerworks/cn/webservices/ws-sdoarch/ 的链接，上面提供了一个很形象生动的例子来说明 SDO API 的使用，看上去的确和 JDBC 没有什么大的区别哦，但是其中的参数选择又是基于 XPath 的。另外，下面这篇文章也给出了一个很好的例子： http://www-128.ibm.com/developerworks/cn/java/j-sdo/

总之，在我们进行 SOA 设计的时候， SDO 可以提供帮助，它提供了一种独特的模型来存放结构化的和相互关联的复合对象，应用程序可以使用这些对象来保存信息。而且，对种类繁多的数据源和业务， SDO 提供了一个统一的数据访问。它还可以在业务处理和信息源间实现解耦合。从某种意义上讲， SDO 框架可以简化和统一 SOA 中的数据应用程序开发。