使用服务 DataObjects API V1.0 和 V2.01 进行数据访问
服务数据对象 (SDO) 框架是以数据为中心、断开连接的 XML 集成数据访问机制,它提供了独立于源的结果集。
- SDO 以数据为中心,因为它使客户机应用程序不再需要处理特殊格式的数据,如 Enterprise JavaBeans (EJB) API 的对象表示。客户机转而使用易于否认的数据对象图。
- SDO 是断开连接的,因为检索到的结果独立于任何后端数据存储连接或事务。
- SDO 集成了 XML,它提供的服务可以轻松地将检索到的数据进行 XML 格式转换。
- 简化 Java™ Platform, Enterprise Edition (Java EE) 数据编程模型。
- 抽取面向服务的体系结构 (SOA) 中的数据。
- 统一数据应用程序开发。
- 支持和集成 XML。
- 合并 Java EE 模式和最佳实践。
服务数据对象框架为数据应用程序开发提供统一的框架。使用 SDO,您不需要熟悉特定于技术的 API 就能访问和使用数据。您只需要了解一个 API (SDO API),通过它您可以使用来自多个数据源的数据,这些数据源包括关系数据库、实体 EJB 组件、XML 页面、Web Service、Java 连接器体系结构和 JavaServer Pages 等。
与一些其他数据集成模型不同,SDO 不会在数据抽取时停止。SDO 框架还合并了许多 Java EE 模式和最佳实践,以便可以轻松地将已认可的体系结构和设计合并到应用程序中。例如,现在多数 Web 应用程序不会(也不可能)一直连接至后端系统;所以 SDO 支持断开连接的编程模型。同样,许多应用程序变得相当复杂,包含多个需要关注的层。那么,将如何存储数据?又如何发送数据?如何在 GUI 框架中将数据显示给用户?SDO 编程模型规定了一些使用模式,将这些问题一一分开解决。
SDO 组件
SDO 的体系结构概述部分描述了构成框架的每个组件并说明它们如何一起工作。列示的前三个组件是 SDO 的“概念性”功能部件,它们在 API 中没有对应的接口。
- SDO 客户机
SDO 客户机使用 SDO 框架来处理数据。它们使用 SDO 编程模型和 API,而不使用特定于技术的 API 和框架。SDO 客户机对 SDO DataObject 进行工作,而不需要知道它们处理的数据是持久的还是序列化的。
- 数据介体服务
- 数据介体服务 (DMS) 负责从数据源创建 DataGraph,并根据对 DataGraph 所作的更改更新数据源。(DataGraph 是包含服务数据对象的包络对象。)
DMS 提供在客户机与数据源之间移动数据的机制。它是通过特定于后端的元数据创建的。元数据定义 DMS 生成的 Datagraph 的结构以及用于后端的查询。当请求 DMS 生成 Datagraph 时,DMS 查询它的目标后端,并将本机结果集转换为 Datagraph 格式。一旦返回 Datagraph,DMS 不再具有对它的任何引用。对于 Datagraph,DMS 是无状态的。当请求 DMS 刷新现有 DataGraph 对后端的修改时,它将抽取从 DataGraph 的原始状态进行的更改并将这些更改刷新至后端。DMS 通常使用某种格式的乐观并行控制策略来检测更新冲突。
WebSphere® Application Server 提供用于两个不同的数据介体服务的功能。 如果您只需从关系数据源检索数据并返回 DataGraph,那么使用 Java 数据库数据介体服务是好的选择。但是,如果您有业务逻辑,那么您可能想要以面向对象 (OO) 的方式将数据呈示到实体 Bean 中。您可将 SDO 视作类似于实体 Bean 的数据对象呈示。但是,实体 Bean 包含更好的对象关系 (OR) 映射工具,并且实体 Bean 的 EJB 容器和持久性管理器提供了更复杂的高速缓存策略。这样,最好的选择就是 EJB 数据介体服务。EJB 介体可以使用这些高速缓存。而且,实体 Bean 编程模型是单级别存储模型。可在实体之间浏览,并且容器和持久性管理器会在必要时预取数据或迟缓地访存数据。更新时,程序员会落实事务,而容器和持久性管理器会跟踪更新过的 Bean 并将它们写回数据存储器和内存高速缓存。
- 数据源
- 数据源不仅仅限于后端数据源(如持久状态数据库)。数据源包含使用自己格式的数据。对于 SDO 1.0 API,只有 DMS 访问数据源;SDO 应用程序不访问数据源。应用程序仅处理 SDO 1.0 DataGraph。
- DataObject
作为 SDO 的主要组件,DataObject 提供了 SDO 客户机的结构化数据的公共视图。DataObject 可能包含任何可序列化类型(如字符串或整数)的多个不同属性;较复杂的 DataObject 还可包含较简单的 DataObject。DataObject 在属性中保存其所有数据。
SDO V1.0 DataObject 始终链接在一起并且包含在 DataGraph 中。V1.0 DataObject 接口 提供简单的创建和删除方法(带有各种特征符的 createDataObject() 和 delete()),以及用于获取其类型(实例类、名称、属性和名称空间)的反射方法。该接口还支持从外部代码生成者创建的静态对象类型。有关更多信息,请参阅“JDBC DMS 的动态和静态对象类型”。
- DataGraph
Datagraph 是响应服务请求而返回的结构结果。DMS 将本机后端查询结果变换为 DataGraph,DataGraph 独立于原始后端数据存储。这使 Datagraph 能在不同的数据源之间轻松转换。Datagraph 由互相连接的节点组成,每个节点都是 SDO DataObject。它与始发数据源的连接和事务无关。DataGraph 会记录从其原始源开始,对它所作的更改。DMS 可以使用此更改历史记录将所作的更改反馈给原始数据源。可以轻松地将 DataGraph 转换为 XML 文档(或从 XML 文档转换过来),这使这些 DataGraph 可以在多层系统体系结构中的层之间转换。可以按宽度优先或深度优先的方式来访问 Datagraph,而且 Datagraph 为 Web Service 提供了可被序列化的、断开连接的数据高速缓存。
由介体返回的 Datagraph 可以包含动态的或生成的静态 DataObject。使用生成的类可为类型安全接口提供更轻松的编程过程并带来更好的运行时性能。EMF 所生成类的名称和类型必须与为动态 DataObject 创建的模式一致,但可以定义其他属性和引用。仅在查询中指定的那些属性和引用中填充数据。不设置剩余属性和引用。
- 更改总结
DataGraph 包含 SDO 1.0 更改总结,可使用这些总结来表示对由 DMS 返回的 DataGraph 所作的更改。它们一开始是空的(当 DataGraph 返回至客户机时),并且在修改 DataGraph 时会填充它们。更改总结由 DMS 在后端更新时用于将更改应用至数据源。通过提供已更改属性(及其旧值)以及 DataGraph 中创建和删除的 DataObject 的列表,更改总结使 DMS 能够有效地以递增方式更新数据源。仅当激活更改总结的记录功能后,才会将信息添加至 DataGraph 的更改总结。更改总结为 DMS 提供用于打开和关闭记录功能的方法。
注: SDO 1.0 更改总结不是客户机 API;它仅供 DMS 使用。- 属性、类型和顺序
DataObject 将其内容保留在一系列属性中。每个属性都具有类型,它可以是原始节点之类的属性类型(如整数)、常用的数据类型(如日期),或另一 DataObject 的类型(如果是引用)。每个 DataObject 提供其属性的读访问和写访问方法(getter 和 setter)。还提供了这些访问程序的若干重载版本,它们允许通过传递属性名称(字符串)、数字(整数)或属性元对象本身来访问属性。字符串访问程序还支持类似 X 路径 (XPath) 的语法以访问属性。例如,可在公司 DataObject 上调用 get(“department[number=123]”),以获取编号为 123 的第一个部门。顺序就更加高级了,它们允许在不同种类的属性-值对列表中保留顺序。
有关更多介绍信息
有关还包含小型样本应用程序的 SDO 1.0 的详细介绍,请参阅 IBM® developerWorks® 文章“服务 DataObject 简介”。