SDO实践摆脱多种数据访问复杂工作

随着SOA理念的流行和 WebService等技术的广泛应用，我们发现在越来越多的系统中，我们需要访问各种不同的底层数据，这些数据包括关系型数据库，EJB组件，XML文件或数据库，Web服务， JSP 页面数据等等。为了能够访问和操作这些数据，开发人员必须了解针对不同数据源操作的规范和API。SDO(Service Data Object)为我们提供了统一的数据应用开发框架，它提供了对多种企业信息系统 (EIS) 的统一的数据访问，包括数据库、遗留应用程序(使用 JCA)、XML 或者是 Web服务数据源。通过使用 SDO 的一种独特而简单的模型，应用程序摆脱了使用多种 API 和框架进行数据访问的复杂工作。从而使开发人员只需了解一种API便可操作上述数据。下面我们就来了解一下什么是SDO。

　　SDO概述

　　SDO(Service Data Objects)服务数据对象，是BEA 和 IBM 共同发布的一项规范。SDO是Java平台的一种数据编程架构和API，它统一了不同数据源类型的数据编程，提供了对通用应用程序模式的健壮支持，并使应用程序、工具和框架更容易查询、读取、更新和检查数据。

　　这里需要说明，SDO不是一种针对数据访问和持久化的技术，而是一种数据编程架构和一组API。SDO主要用于简化数据编程，让开发人员能集中解决业务逻辑问题而不是底层技术. SDO通过以下手段简化数据编程：

　　统一不同类型的数据源的数据访问编程

　　提供一套一致的应用模式的支持

　　让应用、工具和框架能够更便捷地查询、浏览、绑定、更新和获取数据的元信息。

　　SDO中的设计模式

　　SDO的一个关键目标是鼓励大家采用公用的 J2EE 模式，这也是 SDO 体系结构以一些广为人知的模式为基础的原因，例如传输对象 (Transfer Object)、数据访问对象 (Data Access Object)、传输对象组装程序和 Domain Store等。如果使用了 SDO，应用程序就可以从这些经过了验证的设计策略中受益，从而可以推动分层技术和松耦合的发展。为了更好的理解SDO框架，我们有必要对其中使用到的J2EE模式有所了解。

　　Domain Store 模式:

　　为了从不同的数据源获取和存储数据，我们时常将这样的逻辑封装到业务对象中，这样导致数据与特定的数据源和持久化策略紧密耦合。当我们需要变更数据源或存储方式时，就需要修改所有的业务对象。

　　Domain Store 将持久策略与实现从业务对象中分离出来，使数据的表示独立于其数据源。它利用StoreManager, TransactionManager, StateManager这样的管理类对数据对象进行存储操作，这种级别的数据提取有很多优点，例如当数据源发生改变时，只需增加或修改相应的持久实现即可，从而使数据操作变得更容易，实现了不同层之间的松耦合。SDO正是采用了Domain Store这种 J2EE 模式，将数据与对数据源的存取机制很好的解藕了。

　　Transfer Object 模式:

　　SDO使用了传输对象 (Transfer Object) 和传输对象组装程序 (Transfer Object Assembler) 模式，当数据封装到 SDO 对象中后，它就可以在 J2EE 层间高效地传输。这里需要注意的是，SDO 的动态 API 模式与传统的值对象(Value Object) 模式有所不同，它更像是动态赋值弱类型值对象(Dynamic Create Value Object 模式)。对于熟悉 JDBC 概念和 java.sql.ResultSet 接口的读者来说，SDO 的动态 API 模式是很容易理解的。就像 JDBC 一样，您可以通过名称或索引来访问它的属性值。如果在开发阶段数据结构就可以确定的话，SDO 体系结构还提供了静态 API 功能。例如，如果数据源是一个带有明确定义模式(xsd 文件)的 XML 文件的话，则 SDO 将支持 Java 代码生成和 Java 绑定。虽然这已经超出了 SDO 规范的范围，但是绑定技术可能会集成一些对 SDO 的支持，例如 XML Data Binding的 Java 体系结构 (JAXB)。

　　SDO组件

　　SDO由多种不同组件组成，理解他们的概念和作用是理解SDO框架的基础。

　　数据源(Data Source)

　　数据源不限于后端数据源(如持久存储数据库)。数据源以自己的格式保存数据。只有 DMS 访问数据源，SDO 应用程序不访问数据源。SDO 应用程序可能只使用数据图中的数据对象。

　　Data中介服务(DMS)

　　DMS 是一种组件，它负责提供某些方法来组装数据图，也负责将数据更改保存回数据源。典型情况下，将会有多种不同的 DMS 类型，每种类型对应着一种特定的数据源和技术(XML、JMS、JCA、JDBC 等等)。DMS 总是以同一种格式(数据图)返回信息，它隐藏了实际的数据存储信息，在 SDO 应用程序和 EIS 之间提供了一层数据提取的功能。数据中介框架不属于 SDO 1.0 规范，换句话说，SDO 1.0 没有涉及具体的 DMS。常见的 DMS 有 JDBC DMS、实体 EJB DMS 和 XML DMS 等。

　　数据对象(Data Object)

　　数据对象是 SDO 的基本组件。简单地说，它是由属性的键/值对组成的，每个值都可以是原始的数据类型，或者是另一个数据对象。数据对象提供了易于使用的创建和删除方法(带有不同签名的 createDataObject() 和 delete() )，获得自身类型(实例类、名称、属性和名称空间)的反射方法。数据对象都链接在一起，包含在数据图中。数据对象是可序列化的。

　　数据图(Data Graph)

　　数据图是一个描述数据的分层结构，它包括一个数据对象树和另一个称作变更摘要 (Change Summary) 的结构(如图所示)。变更摘要记录了数据图中所有数据对象的历史更改信息。此外，由于数据图是由数据对象组成的，因此它是可序列化的。

　　数据图由 DMS 生成，供 SDO 客户使用。修改后，数据图被回传给 DMS 更新数据源。SDO 客户机可以遍历数据图，读取和修改数据图中的数据对象。当在应用程序组件(比如服务调用期间的 Web 服务请求者和提供者)之间进行传输、组件到 DMS 的传输(或者保存到磁盘)的时候，数据图被序列化为 XML。SDO 规范提供了序列化的 XML Schema。

　　变更摘要(Change Summery)

　　变更摘要包含在数据图中，表示对 DMS 返回的数据图的修改。变更摘要最初是空的，随着数据图的变化逐渐填充。在后台更新时，DMS 使用变更摘要将修改应用于数据源。变更摘要提供了数据图中被修改的属性(包括原来的值)、新增和删除的数据对象的列表，从而使 DMS 以递增方式高效地更新数据源。只有当变更摘要日志功能被激活时，才会将信息添加到数据图的变更摘要中。变更摘要提供了让 DMS 打开和关闭日志功能的方法。(后面的例子中将会看到)

　　属性、类型和序列(Property, Type, Sequence)

　　数据对象用一系列属性保存其内容。每个属性都有一个类型，该类型既可以是基本类型(如 int )这样的属性类型，也可以是通用数据类型(如 Date )，如果引用的话，还可以是其他数据对象类型。每个数据对象都为属性提供了访问和设置方法(getter 和 setter)。这些访问器方法有不同的重载版本，可以通过传递属性名( String )、编号( int )或者属性元对象本身来访问属性。String 访问器还允许使用类 XPath 的语法访问属性。比如，可以对保单数据对象调用 get("policy[policyNo=20070522]") 来访问编号为20070522的保单。序列更加高级，可以保持不同种类的属性-值对列表的顺序。