<Insert Picture Here>

SDO 3.0 – Enhancing the APIBlaise DoughanTeam Lead, Oracle TopLink OXM/SDO/JAXBTeam Lead, Eclipse Persistence Services (EclipseLink) OXM/SDO/JAXB

Agenda

Java EE

Model Classes

Metadata Classes

Runtime Classes

Error Handling

Java EE – The Competing Technology

XML

DocumentRelational

DBObjectsOXM ORM

JAXB/JAX-WS JPA/EJB

Some vendors are providing extensions to the above specifications to better meet customer needs.

Data

DB

Java EE – The Companion Technology

Java EE

Objects JAXB

Java EE

ObjectsJAXBXML

JPA

SCA

Data

ObjectsSDO

SCA

Data

ObjectsSDO

Data

Graph

Agenda

Java EE

Model Classes

Metadata Classes

Runtime Classes

Error Handling

Object vs. DataObject

JAXB SDO

Primitive Types Supports all Java primitive types.

Supports some Java primitive types.

Portability Portable across all vendor implementations.

Interfaces are portable, and impl classes are not.

Serialization Easily serializable. Easily serializable only when using static INSTANCE helpers

Property Restrictions

Cannot have a property called “class” due to the Java language.

Cannot have an additional 8 properties due to the DataObject interface.

Bytecode Technologies

Easy to use with byte code manipulation technologies.

Difficult to use at least in a vendor neutral way.

Java SE 5 – DataObject get*/set* APIs

Proposed by Ron Barrack, SAP

We could take advantage of Java SE 5 to reduce the number of methods on the

DataObject interface.

get* (Could reduce 39 methods to 3 methods)• <T> T get(Class<T> targetClass, String path);• <T> T get(Class<T> targetClass, int propertyIndex);• <T> T get(Class<T> targetClass, Property property);

set* (Could reduce 39 methods to 3 methods)• <T> void set(Class<T> targetClass, String path, T value);• <T> void set(Class<T> targetClass, int propertyIndex, T value);• <T> void set(Class<T> targetClass, Property property, T value);

Java SE 5 – DataObject List APIs

Proposed by Ron Barrack, SAP

We could take advantage of Java SE 5 to enhance the List methods on the

DataObject interface.

getList• <T> List<T> getList(Class<T> elementClass, String path);• <T> List<T> getList(Class<T> elementClass, int propertyIndex);• <T> List<T> getList(Class<T> elementClass, Property property);

setList• <T> void setList(Class<T> targetClass, String path, List<T> value);• <T> void setList(Class<T> targetClass, int propertyIndex, List<T> value);• <T> void setList(Class<T> targetClass, Property property, List<T> value);

Performance – DataObject.get*(String)

get*(String path)

This API requires that the String be introspected in order to determine how to execute it.getFirstName() not comparable to get(“firstName”)

Performance – Containment (SDO-186)

Section 3.1.6

“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.”

The above spec defined behaviour can be a big performance hit for deeply nested trees.

isSet – isMany == true

SDO Properties Have an “isSet” ConceptcustomerDO.get(“phone-numbers”); // aList.size() > 0

customerDO.isSet(“phone-numbers”); // return true

SDO Does Not Track an Explicit ClearcustomerDO.get(“phone-numbers”).clear();

customerDO.get(“phone-numbers”); // return empty list

customerDO.isSet(“phone-numbers”); // return false

Read Only Properties

Proposal

Change this to be a hint instead of it actually preventing an update of a property.

Sequence (SDO-274)

The add APIs are not consistent:• public void add(int index, Property property, Object value)• public boolean add(Property property, Object value)

Change to remove API:• public void remove(int index)

Change this method to be consistent with java.util.List and return the Object that was removed.

Agenda

Java EE

Model Classes

Metadata Classes

Runtime Classes

Error Handling

Eating our own Dog Food

Why aren’t we using SDO to implement SDO?

• DataGraph (commonj.sdo)• Type (commonj.sdo)• Property (commonj.sdo) • XMLDocument (commonj.sdo.helper) • XMLHelper (commonj.sdo.helper) load & save

• The load and save operations take an java.lang.Object parameter to represent options. Why isn’t this parameter a DataObject?

Type & Property as DataObject

SDO-252 – Clarify behavior when storing Type /

Property as a value in a DataObject• If you mark a Property as Type commonj.sdo.Type

can I store an implementation of commonj.sdo.Type on it and/or a DataObject of Type commonj.sdo.Type?

• If you can create a Data Objects for Type and Property should I be able to use the XML representation to populate TypeHelper?

Type & Property as DataObjectsThe Pain Points

• Conflicts between existing API• Property.getType()

• If the property represented a Customer’s first name, this method would probably return the Type commonj.sdo.Type.

• DataObject.getType()• As a DataObject Property would need to return the Type

commonj.sdo.Property.

• Type & Property are currently read-only. They would need to be read/write to work with TypeHelper.

Property – Namespace URIs (SDO-66)

Oracle Requirements:

1. Loading an XML Schema with no target namespace should result in registered global properties.

2. If no Types or Property objetcs are defined the user should be able to create a namespace qualified XML document.

Common Root Class (SDO-257)

• Impact on Simple Types (SDO-264)

Section 9.10 – XML without Schema

• The algorithm here necessitates a sequenced and open Type with no defined Properties to be used.

• Currently this Type is vendor specific, I propose we add a defined Type to the spec.

Unfinished Items

• Multiple Inheritance• No XML Representation• Cannot be serialized (due to above)

• Helper Context• Added late in SDO 2.1• No standard way to create them• Problems related to serialization

Agenda

Java EE

Model Classes

Metadata Classes

Runtime Classes

Error Handling

JAXB Runtime vs. SDO Runtime

JAXBContext• Fixed• No programmatic way to

generate XML Schema

Marshaller• Multiple marshal targets• Standard options

Unmarshaller• Multiple unmarshal sources• Standard options

XSDHelper & TypeHelper• Dynamic• Programmatic way to

generate XML Schema

XMLHelper• Limited marshal targets• No standard options

XMLHelper• Limited unmarshal sources• No standard options

Specifying Vendor Implementations

Currently in Java there can only be one SDO implementation

available in a VM.

From commonj.sdo.helper.impl:

public abstract class HelperProvider {

static HelperProvider INSTANCE = getHelperProviderImpl(); 

static HelperProvider getHelperProviderImpl() {

return (HelperProvider)

Class.forName("commonj.sdo.impl.HelperProviderImpl")

.newInstance();

}

…

}

Date/Time Handling (SDO-46)

• SDO-214

Agenda

Java EE

Model Classes

Metadata Classes

Runtime Classes

Error Handling

Expected Behaviour (Example SDO-255)

In my opinion we are not consistent with our handling of error

conditions. In some circumstances we throw an exception, and

in other cases we try to continue. In many cases it is undefined.

Option #1 – Throw Exceptions

For example in the case where an undefined property is asked for throw an Exception.

Option #2 – Avoid Exceptions

If an undefined property is asked for assume the user meant to have a property by this name and create one automatically.

Standard Exceptions (SDO-105)

It is common for Java EE technologies to throw a common exception. Clearly identifying the layer that encountered the problem:• javax.xml.bind.JAXBException (JAXB)• javax.persistence.PersistenceException (JPA)

Many SDO runtime methods necessitate vendor specific

runtime exceptions, others mandate confusing Java SE

exceptions.• java.lang.ClassCastException• java.lang.UnsupportedOperationException

Summary

Java EE

Model Classes

Metadata Classes

Runtime Classes

Error Handling

Unfinished Items