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 中的數據應用程序開發。