SDO 3.0 Enhancing the API

clumpsmackoverSoftware and s/w Development

Dec 2, 2013 (3 years and 8 months ago)

132 views

<Insert Picture Here>

SDO 3.0


Enhancing the API

Blaise Doughan


Team Lead, Oracle TopLink OXM/SDO/JAXB

Team 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

Document

Relational

DB

Objects

OXM

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

Objects

JAXB

XML

JP
A

SCA

Data

Objects

SDO

SCA

Data

Objects

SDO

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” Concept

customerDO.get(“phone
-
numbers”); // aList.size() > 0

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


SDO Does Not Track an Explicit Clear

customerDO.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 DataObjects

The 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