SOA SDO数据服务规范v2.01：IBM、BEA等巨头联合制定

需积分: 10 50 浏览量更新于2024-08-02 收藏 764KB PDF 举报

"SOA SDO数据服务规范是IBM、BEA等知名厂商共同制定的一项技术规范，主要涉及ServiceDataObjects（SDO）在Java平台上的应用。该规范版本为2.01，发布于2005年11月。此规范的作者包括来自各大公司的专家，如BEA Systems、SAP AG、IBM Corporation、Oracle Corporation等。" SOA（Service-Oriented Architecture，面向服务的架构）是一种设计和构建软件系统的方法，它强调通过提供可重用的服务来实现业务流程。SDO（Service Data Objects）是SOA中的一个重要概念，它提供了一种统一的方式来处理各种数据源的数据。SDO的主要目标是简化数据访问，提高应用程序对数据的灵活性和可操作性。在SOA SDO数据服务规范中，主要涵盖了以下几个关键知识点： 1. **SDO模型**：SDO定义了一个数据模型，它允许应用程序独立于数据源的结构来访问数据。这个模型包括DataGraph（数据图）、DataObject（数据对象）、Properties（属性）和DataTypes（数据类型）等核心概念。 2. **数据绑定**：SDO规范提供了数据绑定机制，使得应用程序可以透明地访问和修改数据，而无需关心底层数据存储的细节。这增强了服务之间的互操作性。 3. **变更跟踪**：SDO支持对数据对象的变更进行跟踪，这使得应用程序能够高效地识别和处理数据的变化，而无需遍历整个数据结构。 4. **事件通知**：当数据发生变化时，SDO可以触发事件通知，让其他组件或服务能够及时响应这些变化，从而实现动态的数据同步。 5. **版本管理**：SDO规范考虑了数据服务的版本管理问题，允许服务提供者更新服务而不影响使用旧版本的消费者。 6. **Java API**：规范中包含了Java API的定义，使得开发者能够在Java环境中方便地创建、管理和使用SDO。 7. **版权与许可**：该规范的版权由参与制定的公司共同持有，并且提供了特定的许可条款，允许用户在遵守规定条件下复制和使用规范。 8. **互操作性**：SDO的一个重要目标是促进不同平台和服务之间的数据交换，通过统一的数据访问接口，提高SOA环境下的系统集成能力。 SOA SDO数据服务规范旨在提供一种标准化的数据服务框架，通过统一的数据对象模型和灵活的数据操作机制，简化了SOA环境中的数据处理，增强了服务之间的互操作性和可维护性。对于开发基于SOA的应用程序和构建分布式系统来说，理解和应用这一规范至关重要。

Page 16

DataObject

DataObjects represent business data. They hold their data in properties.

The DataObject interface is designed to make programming easier because it provides access to

business data of all the common types and access patterns, such as name, index, and path.

The DataObject interface includes methods that:

• Get and set the properties of a DataObject.

• Query whether a Property is set.

• Create a new instance of a contained DataObject.

• Delete a DataObject from its container.

• Detach a DataObject from its container.

• Get the container of a DataObject and the containing property.

• Get the root DataObject.

• Get the DataGraph to which a DataObject belongs.

• Get the DataObject’s Type.

• Get the DataObject’s Sequence (if present).

• Get the DataObject’s additional Properties (if present).

For many applications that do not use generated code, the DataObject interface is the only part of

SDO that is used to write applications. For many applications that use generated code, the

generated interfaces themselves are what is used. The other parts of SDO are primarily use-as-

you-go.

DataObject Concepts

DataObjects can be thought of as falling into the following categories. The open and sequenced

concepts can be used independently or together.

1. Basic. A DataObject is similar to a JavaBean with a field for each Property. The set of

allowed Properties is defined by getType().getProperties(). Values are accessed through

get(property). Order within Properties is maintained but not across Properties.

2. Open. A DataObject is similar to a JavaBean plus it has tolerance for additional

Properties. In XML this is equivalent to open (wildcard) content. It is similar to a

JavaBean with an extra Map to hold the new Properties. The extra Properties are not part

of getType().getProperties(). The Properties actually set in a specific DataObject are

available through getInstanceProperties(). Values are accessed through get(property).

Order within Properties is maintained but not across Properties.

3. Sequenced. A DataObject is similar to a JavaBean plus it has order within and across

Properties. In XML this is equivalent to a DOM. When using XML, a Sequence (see

“Sequence” on page 33) represents the order of all the XML elements in the DataObject.

Values are available through get(property) but order across Properties is maintained

through the Sequence interface. getSequence() returns a Sequence of the XML elements

Page 17

for the case of XML. XML Attributes do not have the concept of order and are accessed

through get(property).

DataObject Values and Properties

DataObjects have data values assigned to Properties. For example, a purchase order DataObject

could have the value 2005-06-30 assigned to the orderDate property. Values for the orderDate

property can be returned or changed using the get("orderDate") and set("orderDate") accessors on

the DataObject. When code is generated, values can also be accessed through getOrderDate() and

setOrderDate() methods on a PurchaseOrder interface.

On the DataObject interface, values can be accessed using the name of the property with

get(String path), with the index of the property, or directly with a Property object. The get(String

path) methods on DataObject work with the alias names as well as the property names names in

the path. The path can be just the name of the property, or it can be a path expression based on a

subset of XPath.

Type Conversion

Sometimes the Type of a Property is different than the most convenient type for use in an

application program. For example, when displaying a integer quantity in a user interface, the

string representation is more useful than the int. The method getString("quantity") for accessing

an int quantity property conveniently returns the value as a String. This simplifies a common

task in many applications.

When a DataObject’s typed accessors get<T>() and set<T>() are invoked, a type conversion is

necessary if the value is not already an instance of the requested type T. Type conversion is

automatically done by a DataObject implementation. An implementation of SDO is expected to

convert between any data type and the set defined in DataObject, with possible loss of

information. The supported data type set is defined in the SDO DataTypes section. These types

include:

• Java primitives

• object wrappers of Java primitives

• String

• Date and time types

•URI

• byte[]

• BigDecimal

• BigInteger

Conversions are specified in Java [6] and the DataHelper. The supported conversions are

specified in “DataType Conversions” on page 145.

Page 18

Many-valued DataObject Properties

A Property can have one or many values. If a Property is many-valued then property.many is true

and get(property) always returns a List.

DataObject methods with a return type of List, on the DataObject interface or generated, return

empty lists rather than null when there is no value. Returned Lists actively represent any changes

to the DataObject's values.

The getList(property) accessor is especially convenient for many-valued properties. If

property.many is true then set(property, value) and setList(property, value) require that “value” be

a java.util.Collection and List respectively. These methods are equivalent to

getList(property).clear() followed by getList(property).addAll(value).

For many-valued Properties, get() and getList() return a List containing the current values.

Updates through the List interface operate on the current values of the DataObject immediately.

Each access to get() or getList() returns the same List object.

Determining whether a Property is Set

For many-valued properties, isSet(property) returns:

• True, if the List is not empty.

• False, if the List is empty.

For single-valued properties, isSet(property) returns:

• False, if the Property has not been set(), or has been unset().

• True, if the current value is not the Property's default.

• For the remaining cases the implementation may decide between either of the following

policies:

• Any call to set() without a call to unset() will cause isSet() to return true. After

set(property, property.getDefault()), isSet(property) returns true.

• The current value is compared to the default value and isSet() returns true when they

differ. After set(property, property.getDefault()), isSet(property) returns false.

The unset(property) accessors can be thought of as clearing out a single property, so that

isSet(property) returns false and get(property) returns the default. The delete() method unsets all

the DataObject’s properties except for those marked read-only. After unset(), get(property)

returns the default; which in the case of a many-valued Property is an empty List.

Note that attempts to modify read-only properties (using set, unset or delete) cause an exception.

Page 19

Containment

DataObjects in a data graph are arranged in a tree structure. One DataObject forms the root of the

tree and the other DataObjects make up the nodes of the tree.

The tree structure is created using containment references which start at the root DataObject. The

root DataObject refers to other DataObjects, which can refer to further DataObjects. Each

DataObject in the data graph, except for the root DataObject, must have a containment reference

from another node in the tree. Each DataObject in the graph keeps track of the location of its

containment reference.

It is possible for a data graph to have non-containment references. These are references to

DataObjects which are part of the same data graph, (the referenced DataObjects must be part of

the same tree), but these references do not affect the tree structure of the data graph.

Both containment and non-containment references are Properties of a DataObject. The Type of

the Properties is any DataObject Type.

Whether a particular DataObject reference Property is a containment reference or a non-

containment reference is defined by the data model for the data graph, for example the XSD

which defines the data types for an XML document. This cannot be changed once the data model

has been defined. You can query whether a particular reference is a containment reference

accessing property.containment.

A container DataObject is one that contains other DataObjects. A DataObject can have a

maximum of one container DataObject. If a DataObject has no container, it is considered to be a

root DataObject.

Simple navigation, up and down the DataObject containment tree, is provided by getContainer()

and getContainmentProperty(). The getContainer() method returns the parent DataObject and the

getContainmentProperty() method returns the Property of the container that contains this object.

A DataObject can be removed from its container, without making any other changes, using the

detach() method.

Containment is managed. When a DataObject is set or added to a containment Property, it is

removed from any previous containment Property. Containment cannot have cycles. If a set or

add would produce a containment cycle, an exception is thrown.

Creating and Deleting DataObjects

The create methods create a DataObject of the Type of the Property, or the Type specified in the

arguments, and add the created object to the Property specified. If the DataObject's Type is a

sequenced type (that is, if getType().isSequenced() is true) then the created DataObject is put at

the end of the Sequence. If the Property is single-valued, the Property is set to the created object.

剩余148页未读，继续阅读

PortalFan

粉丝: 1
资源: 4

SOA SDO数据服务规范v2.01：IBM、BEA等巨头联合制定

服务组件架构SCA与服务数据对象SDO：简化SOA构建

服务构件架构SCA与SOA：核心技术与规范解析

理解SOA：核心技术与WSDL规范解析

SOA编程模型_SCA_SDO

SOA相关标准规范初步整理

SDO的JAVA实现规范

sdo规范及其应用介绍

全部的SCA&SDO中文规范

普元等18家厂商联合制定简化SOA应用开发规范

SDO概述

最新资源