现状分析

　　随着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)。