EclipseLink/UserGuide/SDO/Introduction to EclipseLink SDO (ELUG)
This section introduces EclipseLink implementation of Service Data Objects (SDO) specification, as well as provides information on how you can use it in your application development.
- 1 Using SDO Metadata
- 2 Using Data
Using SDO Metadata
For more information, see EclipseLink examples of metadata usage.
SDO Type acts similarly to a Class in Java, and provides much of the same metadata as the Java Reflection API provides for Java classes.
A Type can have supertypes, which corresponds to the EclipseLink concept of inheritance policy (see Inheritance Policy in Descriptor API).
To create types programmatically, you populate a DataObject with them.
To load types from an XML schema, use the XSDHelper class, as the following example shows:
HelperContext ctx = HelperProvider.getDefaultContext(); FileInputStream is = new FileInputStream("test.xsd"); ctx.getXSDHelper().define(is, null);
For more information, see the default Type API.
What You May Need to Know About Open Sequenced Type
You can define SDO types as open sequenced types. If, when creating a DataObject, you define a Type as a sequenced type (that is, isSequenced is true), then the created DataObject is put at the end of the Sequence.
If you define a Type as open (that is, its open is true), it will have to accept additional DataObject's properties (the ones not specified by their Type).
For more information, see EclipseLink OpenSequencedType API.
What You May Need to Know About DataObjectType for Data Types
For information, see EclipseLink SDODataObjectType API.
A DataObject is made up of Property values. SDO Property acts similarly to a property in Java and provides much of the same metadata as the Java Reflection API provides for Java fields or methods.
- DataType=true + isMany=false - corresponds to EclipseLink OXM direct mappings and OXM binary mappings.
- DataType=true + isMany=true - corresponds to EclipseLink OXM direct collection mappings and OXM binary collection mappings.
- DataType=false + isMany=false + containment=true - corresponds to EclipseLink OXM composite object mappings.
- DataType=false + isMany=true + containment=true - corresponds to EclipseLink OXM composite collection mappings.
- DataType=false + isMany=false + containment=false - corresponds to EclipseLink OXM reference mappings.
- DataType=false + isMany=true + containment=false - corresponds to EclipseLink OXM collection reference mappings.
For more information, see the default Property API.
You can use the following helper classes to define and access SDO metadata:
How to Define Metadata with XSDHelper
You use the XSDHelper to do the following:
- Define SDO metadata, where SDO metadata is derived from XML schemas.
- Generate XML schemas from SDO types.
You can obtain the default XSDHelper from the INSTANCE field or from the getXSDHelper method of the default HelperContext.
You can customize metadata by using the following annotations that you apply to the XML schema:
- Standard annotations:
- Information pending
- EclipseLink annotations:
- Information pending
You can also use various APIs to determine the XML representation about the SDO metadata.
For more information, see the following:
How to Define Metadata with EclipseLink TypeHelper
You use the TypeHelper to do the following:
- Look up SDO metadata.
- Programmatically define SDO metadata (note that this is not the typical usage for the TypeHelper).
You can obtain the default TypeHelper from the INSTANCE field or from the getTypeHelper method of the default HelperContext.
For more information on how to use the TypeHelper in your application, see TypeHelper examples.
For more information, see EclipseLink SDOTypeHelper API.
Use the following SDO classes to work with data:
A DataObject is the central concept in SDO. It represents business data and corresponds to an Object in Java (POJO). To define object-XML mappings, you map the DataObject to XML. You can create your data object as either dynamic (see Dynamic DataObject Examples), or static by applying a type-safe interface to it (see Static DataObject Examples).
The DataObject provides an XPath-like (see Mappings and XPath) means of data access. For example, the following code is valid in SDO:
The standard JAXB, however, would require the following:
Note that you can use the EclipseLink XPathHelper to query data objects using an XPath expression.
For more information, see EclipseLink SDODataObject API.
What You May Need to Know About Serialization in SDO
SDO has its own Java serialization format that contains all of the information in a DataObject but does not write anything that is tied to a specific Java implementation of SDO into an ObjectOutputStream.
The format supports one or many data objects from one or many trees of data objects, possibly intermixed with any other serializable Java objects, in the same stream.
When you marshall (save) a DataObject to XML, or unmarshall an XML document into objects, the XMLDocument class contains information about the root of the XML document.
The XMLHelper creates and serializes XMLDocument objects. The XMLDocument does not change the state of any input DataObject and ignores any containers.
For more information, see EclipseLink SDOXMLDocument API.
What You May Need to Know About Sequence, ChangeSummary, and DataGraph
The following SDO classes allow you to obtain additional information about data objects:
- Sequence -- provides a list of properties and their corresponding values. It represents the order of all the XML elements in the DataObject. Each entry in a Sequence has an index, with the order of settings being preserved, even across different properties. The same properties that appear in a Sequence are also available through a DataObject, but without preserving the order across properties.
You should use sequences when dealing with semi-structured business data, for example, mixed text XML elements.
- ChangeSummary -- records changes to data objects, therefore reducing the amount of data that needs to be transmitted between collaborating SDO applications.
The ChangeSummary only tracks modifications that have been made to a tree of data objects starting from the point when logging was activated. If logging is no longer active, the log includes only changes that were made up to the point when logging was deactivated. Otherwise, it includes all changes up to the point at which the ChangeSummary is being interrogated. Although change information is only gathered when logging is on, you can query change information whether logging is on or off. All of the information returned is read-only.
Use the ChangeSummary's beginLogging method to clear the List of changed DataObjects and start change logging; use the endLogging method to stop change logging; use undoChanges to restore the tree of data objects to its state when logging began. Note that undoChanges also clears the log, but does not affect isLogging.
Note that the DataGraph class has been deprecated.
For more information, see the following EclipseLink APIs: