为什么需要SDO？

很多朋友对于SDO这个名词已经耳熟能详了，然而对于SDO解决什么问题，具体包括什么内容，可能还没什么概念，所以我从SDO白皮书和标准中摘录了部分内容，翻译成中文，放在这里，供大家参考。

页134 页135 页136 页137 页138 页139 页140 页141 页142 页143 页144 页145 页146 页147 页148 页149 页150 页151 页152 页153 页154 页155 页156 页157 页158 页159 页160 页161 页162 页163 页164 页165 页166 页167 页168 页169 页170 页171 页172 页173 页174 页175 页176 页177 页178 页179 页180 页181 页182 页183 页184 页185 页186 页187 页188 页189 页190 页191 页192 页193 页194 页195 页196 页197 页198 页199 页200 页201 页202 页203 页204 页205 页206 页207 页208 页209 页210 页211 页212 页213 页214 页215 页216 页217 页218 页219 页220 页221 页222 页223 页224 页225 页226 页227 页228 页229 页230 页231 页232 页233 页234 页235 页236 页237 页238 页239 页240 页241 页242 页243 页244 页245 页246 页247 页248 页249 页250

　　SDO简介

　　Service Data Objects (SDO) 是一种编程模型的规范，它统一了访问不同类型数据源时的数据编程，为常见应用模式提供全方位的支持，允许应用、工具和框架等更加容易的查询、展示、绑定、更新和检索数据。

　　SDO关键特性

• 　　动态数据API(Dynamic Data API).

　　数据对象通常都有对应的Java接口。然而有时候开发者无法或者难于为一些数据对象创建Java接口，常见的情况是被传输的数据是通过查询的输出来定义的。比如以下场景：

• 　　对关系型数据库的一次查询.
• 　　使用EJBQL查询EJB实体Bean.
• 　　Web服务(Web services).
• 　　对XML资源进行的XML查询.

　　在这些情况下，我们需要使用动态的存储和相关API。SDO有能力支持通过标准的、动态的数据API来表示数据对象。

　　静态数据API支持(Support for Static Data API).

　　对于那些在应用开发时元数据已经明确的数据对象(比如XML Schema定义或者SQL关系Schema已经确定的情况)，SDO支持使用接口来处理. 在使用静态API时，动态API仍然有效. SDO支持从多种元数据模型中生成静态数据API，包括:

• 　　通常的XML Schema.
• 　　在代码生成时能够确定的关系型数据库Schema.
• 　　那些通过XML Schema定义了消息接口的Web services.
• 　　JCA连接器(JCA connectors).
• 　　JMS消息格式(message formats).
• 　　UML模型(models)
• 　　复杂数据对象(Complex Data Objects).

　　我们经常需要处理"复杂"或者"复合"数据对象,这类数据对象可能是数据树的根节点或者是数据图(DataGraph) .比如一个订单对象中引用了多个订货信息就是数据树的例子，如果每一个订货信息还引用了货物详细信息，这些对象就组成了数据图.当处理复合数据对象时，数据对象的变更摘要是非常难于实现的，因为数据对象的简单变化或者是插入、删除、增加、移除和重新排序动作都要被记录下来. SDO支持任意的数据图和它的变更摘要。

　　变更摘要(Change Summary).

　　一种很常见的场景是从另外一个构件中获取数据对象，对该数据对象进行更新，然后将更新过的数据对象传递给另外一个构件。为了支持这种场景，接收被修改后的数据对象的构件必须知道该数据对象的那些内容被修改了. 简单情况下，只要知道数据对象是否被修改就足够了，另外一些情况下，必须知道(或者最少想要)数据对象的那些属性被修改过.一些标准的乐观冲突检测算法不仅知道哪些列被修改过，还可以知道被修改之前的值是什么，SDO支持完整的变更摘要.

　　遍历数据图(Navigation through graphs of data).

　　SDO支持通过动态数据API遍历整个数据图，所有的数据对象通过广度优先遍历(breadth-first)或者深度优先遍历(depth-first)可以被访问。或者直接使用XPath 1.0的子集进行访问.

　　许多应用中数据被返回数据的范围都是编码在程序中的，他们知道要调用哪个方法，要访问数据对象的哪些字段。但是为了支持泛型、框架代码中数据对象的访问，必须能够反射访问数据对象的元数据，这些元数据暴露了数据对象的数据模型。由于Java反射没有返回足够的信息，SDO提供了元数据访问的API，SDO元数据可以从如下方式获得：

• 　　XML Schema
• 　　EMOF(Essential Meta Object Facility)
• 　　Java
• 　　关系型数据库
• 　　其他结构化表示方法

　　校验和约束(Validation and Constraints).

　　支持在元数据中设置的一组标准约束条件的校验。元数据获取使用XMLSchema和关系型模型中表示的普通约束条件。

　　提供了约束和校验的可扩展机制，可以提供自定义的约束、校验。

　　关联关系完整性(Relationship integrity).

　　约束的重要应用就是定义对象之间的关联关系，保证约束的完整性，包括集合(cardinality，一对多)、所有者语义和反转(双向关系)等。比如一个雇员(employee)和他所在的部门存在关系，相反地，他的部门有一些雇员。如果一个雇员的部门发生了变化，那么这个雇员就必须自动地从原来的部门中移除，同时，这个雇员必须被加入到新的所属部门的雇员集合中去。数据对象关联关系使用正常的java对象表示，而不使用带有外部关系的主键、外键。

　　内容包容树的完整性也非常重要。

　　为什么是SDO

　　Java平台和JavaEE中提供了非常多的数据编程模型和API，这些技术都片面的解决一部分问题，而且对工具和框架的支持不够友好。此外，一部分技术非常难于使用，支持通用应用时在功能上也不够完善。SDO的目标是创建一个统一的数据访问层，通过简单易用的形式提供对异构数据源的数据访问解决方案，而且对于工具和框架是友好的。SDO并不是为了取代底层的数据访问技术(请参考后面的SDO与其它技术的关系)。SDO的目标如下：

　　对异构数据源的统一访问,现有的数据编程技术或多或少的针对特定数据源类型而设计。但是现实世界的应用中，数据往往都来自于多种数据源中，包括关系型数据库(用JDBC、EntityEJB或者其他持久化框架访问)、客户数据访问层(通过众所周知的设计模式实现)、Web Services(通过JAX-RPC或其他方式访问)、XML 数据存储、JMS消息和企业信息系统(通过JCA ResourceAdapters或者客户API访问)。这些异构数据源的存在使应用开发者面临很大的挑战，因为他们需要学习的编程模型非常多。过多的数据访问API也是那些希望自动化一些常见编程工作的工具和框架需要面临的巨大挑战，比如如何将UI组件绑定到后台数据资源。因此，可以忽略数据来源的普通数据的表达集可以为应用开发者提供一种简单、统一的编程模型，同时为工具和框架提供对异构数据源的一致支持提供新的机会。

　　对静态和动态数据API的统一支持。静态、强类型接口为应用开发者提供了一种简单易用的编程模型。比如Entity EJB、JDO、Hibernate以及其他对象/关系持久化机制，他们提供了访问数据的强类型Java接口，这些接口为开发者提供了简便的编程模型(比如,account.getFirstName()或者account.getBalance())。相反，JDBC的ResultSet和RowSet接口，仅仅提供了动态的、没有类型的数据接口(比如rs.getString(“FIRST_NAME”)或者rs.getFloat(“BALCACE”))。同样的，JAXB提供了访问XML数据的Java接口，让XML数据的编程比如直接使用Dom和SAX更加简单。单独的静态或者动态API都是不够的，两者都是必须的。静态API是简单易用应用开发者们需要的数据API，但是在另外一些情况下，数据的静态Java接口既不可行也不是所想要的。比如，一些动态查询生成的结果数据的范围是不确定的，这种情况下，静态Java接口是不可行的。因此，对于一种统一的数据编程技术而言，需要同时无缝的支持静态和动态数据API。

　　支持工具和框架。现有的编程技术对于使用工具和框架访问异构数据源。工具和框架需要一些一些关键特性：

• 　　统一访问跨异构数据源的数据。因为现实世界中的应用使用的数据来自于不同数据源，框架需要依赖于一种统一的数据表示。
• 　　动态数据API。按照上面讨论的，对于那些框架来说，使用动态数据API是更合适的方式。因为框架中的数据都是泛型的，那些生成了代码的接口通常是不合适的，或者是不可行的。
• 　　简单的反射(或者元数据)API.框架为了完成数据修饰、可更新的表单、数据绑定等功能，通常需要反射数据的范围(“Shape”)。

　　支持离线编程模型。许多应用都天然需要一种离线数据访问模式。应用中读取一组数据，短时间内保留在本地，操作这些数据，然后将这些修改提交到数据源中。比如，在Web应用中，经常需要处理这样一种模式：Web客户段通过表单获取数据，Servlet或者JSP用一种本地读的事务获取数据并且显示在HTML表单中，Web客户段提交表单的更新，Servlet或者JPS使用一个新的事务去更新数据。最佳实践说明乐观并发语义可以应用于这种场合，它提供了支持合适的业务层次语义的并发的更高层次。今天还没有数据访问技术能提供这种离线的、乐观的模型和上面提到的其他特性。JDBC的扩展模型(JSR-114中的CachedRowSet)提供了这种离线模型，但是前面已经提到，JDBC无法满足对异构数据源访问的需求，也无法满足简单易用的需求。同样的，那些对象/关系持久化机制(比如，一些Entity EJB实现，JDO，Hibernate等)支持乐观并发语义，但是他们无法支持必须的通用数据访问特性。

　　支持基于常见设计模式的客户数据访问层。许多应用使用众所周知的设计模式(比如Transfer Object、Transfer Object Assembler, Data Access Objects, 和 Domain Store)来构建客户化的数据访问层。这些模式在那些要求应用和物理数据源无关时经常被使用。实现这种客户数据访问层通常需要非常多的客户化代码，其中的一些代码可以被自动化生成。而且，这些客户化数据访问层必须可以被工具和框架集成。

　　降低应用代码和数据访问代码之间的耦合度。为了让代码可以重用和可维护，应用需要和数据访问分离。数据访问技术必须友好的支持这种分离。