Java Projections in SDO 3.0

Ron Barack - SAP…

Agenda

Pain Points Frameworks and Data

Representations Proposals

Annotations Projections between contexts JavaBean DAS

Pain Point: Defining SDO Types The only comfortable way to use and define SDO types in

an application is to maintain the type definition in the form of an XSD.

The only other standard way to define a type is through the API. How static SDO’s become bound to types is awkward

Relies on annotating the XSDs Is somewhat underspecified

Applications (Business Logic, as opposed to middleman frameworks) want to use type-safe interfaces to access business data. SDO has to move smoothly between these access modes.

For such applications, annotations of the JavaBeans is the most natural way to specify meta-information.

Problem Statement Non-XSD Based Applications cannot easily define SDO Types. Static SDOs must be annotated to be a possible source of metadata.

Defining Types through Side-files

Use-Case: neither Java nor XSD are suitable sources for metadata (e.g., because the Java or XSD cannot be altered).

Types could be serialized as {commonj.sdo}Type DataObjects, using standard XML serialization, but this serialization must be customized for this use case:

XML Serialization of {commonj.sdo}Type and {commonj.sdo}Property require special handling for the references to Type: we want to see the URI#Name of the type, not the XPath.

Should be consistent with reference to standard types. This format is also used in the XML delivered with SDO 2.1 Could be a 2.1.1 Issue.

Pain Point: SCA cross application wiring SCA Cross-Application Wiring

SCA allows calls between co-located applications (i.e., EAR). Each application will have ist own class loader. Static SDOs may be used in method signatures.

Problem Statement The static SDOs may be packaged differently in each application. Even if the packaging is identical, unless the classes are placed in

a common (system) library, the static SDOs will be loaded in different class loaders, and therefore we will not be able to cast from one to the other.

SDO is Service Data Objects, and must support data transfer between applications (without requiring conversion to XML).

Use-Case from SCA

RDB DAS

EJB

On this side, a static SDO is used.

JBPM BPEL

On this side, a DOM Element is

generated. The SDO type is

generated from the XSD. No static SDO

is needed or desireable.

SCA Wiring

SCA Wiring appies the projection, adding the

static SDO like a facade to the SDO Data Object.

Late Binding of static class to SDO type

Pain Point: Harmonizing SDO with Frameworks

Frameworks such as JAX-B and JPA use POJOs as data objects. These POJO classes may be generated or hand written. The frameworks introspect the POJO classes, and typically use injection to

load values into the fields. Injection may be setter or field-based.

JAX-B and JPA are intended to be used throughout the application, not just near the data source (a la EJB 2.x EntityBeans).

Framework POJOs typically do not interoperate – eg, you can‘t use your JAX-B classes as JPAs.

SOA Applications involve multiple frameworks, eg, read data from JPA and use it in a WebService response.

It is impractical to generate separate static SDO in cases where such POJOs already exist.

Domain models tend to be big… this would effectively double the number of classes.

Seems to require a copy step

Agenda

Pain Points Frameworks and Data

Representations Proposals

Annotations Projections between contexts JavaBean DAS

Framework Imposed Programming Models

Frameworks impose Programming Models data type definition language/methodology interface description language/methodology interface implementation requirements framework behavior

Examples: Session Bean with DTOs JPA with persistent classes JAX-WS bean with JAXB BPEL with XSD+WSDL SDO DAS with SDOs (just another framework)

If SDO wants acceptance, it must Simplify transition between domains. Interoperate with existing frameworks

type

sin

terf

aces

imp

lem

enta

tion

fra

mew

ork

use

imp

lem

ent

dete

rmin

es

x.xsd IX.java

pl.wsdl

proc.bpel

IService.java

sdo

gen

define / project

use

DB

DAS/DAO

pass

use

use

BPELengine

use

x.xml

seria

lize

pass

typ

es

inte

rfa

ces

imp

lem

en

tatio

n

serviceimpl

pa

ss

fra

me

wo

rk

Integration in SDO 2.1: SDO-Java/XML

XSD as leading descriptionof domain types

Java interface derived from schema (may require tooling)

SDO type preserves XSD nature

+: prepared for cross-technology use-cases (anything java/wsdl)

+: fully supported today

-: java domain model driven by XSD structure

-: Other frameworks are hidden behind the DAS. Not useful for integrating existing applications, and assumes that we can impose the SDO framework on the rest of the world.

open!

use sdo:<..> attributes to provide additional meta-

data (e.g. interface association)

x.xsd IX.java

pl.wsdl

proc.bpel

IService.java

sdo

gen

use

DB

DAS/DAO

pass

use

use

BPELengine

use

x.xml

seria

lize

pass

type

sin

terf

ace

sim

ple

me

nta

tion

serviceimpl

pass

fram

ew

ork

defin

e/pr

oject

SDO 2.1 + Annotations: SDO-Java/XML

SDO Type derived from Java Interface.

+: prepared for cross-technology use-cases (anything java/wsdl)

+: simple scale-out from Java scenario to XML-based technologies

-: XSD/BPEL model driven by SDO Type system.

-: Other frameworks are hidden behind the DAS. Not useful for integrating existing applications, and assumes that we can impose the SDO framework on the rest of the world.

open!

use sdo annotation (proprietary) to provide additional meta-data (e.g. for XML schema)

SDO integrates with existing frameworks

The JPA programming model is used.

The cast operation converts from the persistent object to SDO, not (necessarily) a java cast.

Additional meta information can be provided as annotations, or the cast operation can be used with an additional Type parameter.

Of course, everything is nicer if the objects returned from JPA already implement DataObject!

x.xsd Pojo.java.

pl.wsdl

proc.bpel

IService.java

sdo

gen

use

DB

JPAus

eus

eBPELengine

use

x.xml

ser ia

lize

pass

type

sin

terfa

ces

impl

emen

tatio

n

serviceimpl

pass

fram

ewor

k

cast

use additional annotations to provide additional meta-data (e.g. for XML schema)

SDO Wires Between Frameworks

Pojo.java.

IService.java

sdo

use

DB

JPA

type

sin

terfa

ces

impl

emen

tatio

n

serviceimpl

pass

fram

ewor

k

JaxB.java.

IService.java

use

JAX-WS

serviceimpl

pass

castproject

The JPA & JAX-WS programming models are used side-by-side, but loosely coupled, so they cannot share classes.

The project operation (lazily) creates an entire graph of POJOs.

The DataObject.cast operation creates a facade (proxy) object, that extends the target class and implements DataObject.

If the target class is a POJO, this may involve a copy step, since the fields will need to be filled.

Agenda

Pain Points Frameworks and Data

Representations Proposals

Annotations JavaBean DAS Projections between contexts

Proposal: Classes as Type Descriptions

Types can be defined by callingType t = typeHelper.getType(MyType.class);

To define a type, and create an instance:DataObject o = dataFactory.create(MyType.class);

Of course, only the first call actually creates the type. Assuming containment requirements are relaxed,

unaltered classes will often be enough, otherwise mapping can be tuned with annotations or side files.

Not a change to API, only an additional way to bind Types and instance Classes: fully compatible with SDO 2.1

API: DataFactory.create

<T> T dataObject.create(Class<T> targetClass)

This method is not new, but its signature is made more friendly through generics. It plays an important role in „harmonization of frameworks“, since an SDO-enabled JPA or JAX-B implementation could create an instance of a static SDO wheretargetClass.isInstance(returnValue)and returnValue instanceof DataObject return true.

Loose Coupling of DataObjects with Static SDOs

Static SDOs are „projections“ of SDO DataObjects into Java, similar to how XML documents are „projections“ for SDO DataObjects into XML.

It should be possible to have multiple Java projections of the same DataObject, like multiple views of the same DB table.

These different views can use different „dialects“. One can be JAX-B, another JPA, another can use SDO custom annotations, another can have no instanceClass at all.

@XmlTypepublic class RonJaxB { @XmlElement public String getName()

@SdoTypepublic class RonSDO { @SdoProperty public String getName()

DATA OBJECT

Name: Ron

Major: Computer Sci

Year: Junior

…

Proposal: Native SDO Annotations Achieve richness of

metamodel comparable to what can be achieved using XSD.

Annotate Java classes in a way that is natural when thinking in terms of SDO metadata.

Complement standard annotations (e.g., JAX-B, JPA)

Current proposal complements JPA nicely, but has overlap with JAX-B.

@SdoTypeMetaData( uri="http://www.sample.org/shop/", sdoName="ShoppingCart")public interface IShoppingCart {

@Id long getId();

@SdoPropertyMetaData(opposite="cart") List<IShoppingCartItem> getItems(); void setItems(List<IShoppingCartItem> pItems);

Date getCreated(); Date getLastModified();

String getUser(); void setUser(String user);}This code mixes JPA and SDO annotations

Why not just use JAX-B annotations? In some places, JAX-B does not have preserve

enough metadata. For example, whether a property’s type is a user-defined or standard type is not surfaced.

Users will expect that the class’s properties map to the properties defined in the type. This is not the case for JAX-B. For example, mixed content types in JAX-B have a “getContext” method.

JAX-B uses annotated JavaBean implementation classes, SDO needs to allow interfaces to be used as static SDOs.

Not part of JavaSE until Java 6.

Proposal: Harmonizing with JAX-BJAX-B cannot be ignored, SDO should not

compete with JAX-B! There is a lot of overlap, and definitely cases

where JAX-B is sufficient. There are a lot of JAX-B (and JPA)

applications, and we want to use SDO to integrate with them. Requiring custom mappings would defeat the purpose here.

Therefore: We want to be able to understand JAX-B (and

JPA), but not be limited to them. JAX-B is „just another“ projection

Agenda

Pain Points Frameworks and Data

Representations Proposals

Annotations Projections between contexts JavaBean DAS

The same type, different contexts HelperContexts may hold contrasting definitions of the same type (as

identified by its (URI, Name) pair. The type definitions may come from different sources. One may be

defined by parsing an XSD, the other by inspecting a Java interface. The type definitions may vary slightly. E.G, the type defined through

an XSD will always contain containment info, but the type generated from a Java Interface may out leave this information.

Context1

School

Student

Course

Context2

School

Student

Course

DataObject: ron

DataObject: cal

If the types are somehow (to be defined) consistent with each other, it should be possible to cast DataObjects from one context to the other.

Casting a data object into a different context returns an object with the following characteristics

The type of the created object is the corresponding type from the other context. Both data objects reflect the same underlying data. Changes to one are visible in

the other. No copy step is necessary. By inspecting the data objects, there is no way to tell which is the projection, and

which is the original.

Projecting between contexts

Context1

School

Student

Course

Context2

School

Student

Course

DataObject: ron DataObject: projection

Name: Ron

Major: Computer Sci

Year: Junior

…

projection = context2.cast(ron)

Projecting between Contexts<tns:School> <student> <name>Ron</name> <courses name=‚Basket Weaving‘/> <courses name=‚Algol 68‘/> </student></tns:Student>

HelperContext xmlContext = …DataObject cal = xmlContext.getXmlHelper().load(…);HelperContext javaContext = …javaContext.getTypeHelper().getType(School.class);School projected = (School)javaContext.project(cal);entityManager.persist(projected);

@Entitypublic class School { String getName(); List<Course> getCourse();}

The XML based type system does not „know about“ the java based type system, and we can map to (and between) any number of interfaces or classes.

Same proposal as for containment In SDO 2.1, XML specific information (eg, containment) is

associated with the SDO type in a 1:0..1 fashion: each type has at most one set of associated XML data.

In the discussion of containment in SDO 3.0, projections describe the late coupling of SDO metadata with the additional data necessary for XML fidelity, creating a „view“ of the data.

The same SDO type can be „projected“ onto any number of XSDs.

In SDO 2.1, the information specific to a static SDO is associated with the SDO type in a 1:0..1 fashion: each complex type has at most one „instance class“.

In this set of slides, we consider applying the concept of projects to static SDOs, to provide late, potentially temporary coupling of SDO metadata with a specific static SDO.

The same SDO type can be „projected“ onto any number of Java classes!

API: Applying a Projection with HelperContext.castDataObject helperContext.cast(DataObject original)

This method projects a DataObject from one context to another, returning a new DataObject whose Type definition is registered in the TypeHelper associated with the helperContext.

The returned object (returnValue) is an additional view of the same underlying data. Setters called on the original DataObject are reflected in the casted object and vice-versa.

Navigating from returnValue returns objects that are casted, ie, are in the same helperContext as returnValue.

There is at most one „cast“ of any data object into any helper context. Subsequent calls to cast on the same helperContext, giving the same DataObject, or any „cast“ of the the original object, always returns the same object.

The name „Cast“ comes from the Java concept. In both cases, casting returns a reference to the same underlying data, with a different interface.

Agenda

Pain Points Frameworks and Data

Representations Proposals

Annotations Projections between contexts JavaBean DAS

JavaBeans and static SDO We define 2 methods, DataFactory.cast and DataObject.project that effectively constitute a DAS for JavaBeans.

This is not intended as a general mapping framework, only as a data binding.

This functionality is separate from static SDO‘s. Static SDOs inplement both DataObject and the static

interface. The result of a DataObject.project operation does

not implement DataObject. The result of a DataFactory.cast operation does

not necessarilly implement (or extend) the POJO class, unless the POJO class is the instanceClass

Question: Do we need JavaHelper?

API: DataFactory.castDataObject DataFactory.cast(Object arg)DataObject DataFactory.cast(Object arg, Type type)

These methods „cast“ a POJO object, returning a DataObject. The SDO Type of the returnValue is either derived through

introspection of the class, or given as a parameter; its instanceClass could be the same as arg.getClass().

If arg is already castable to a DataObject in the same HelperContext, the same instance will be returned.

The values of arg‘s properties are available in the returnValue. Setters called on returnValue also change the value of arg‘s

properties. Setters called on arg directly change the value of returnValue‘s properties, but these changes will not affect the ChangeSummary, the value of isSet, etc.

Effectively, the entire transitive closure reachable from arg is casted, but implementations may create objects lazily.

API: DataObject.project

<T> T dataObject.project() This method „projects“ a DataObject into a static its

instance class, returning an object where getClass()==dataObject.getType.getInstanceClass().

The state of the created object reflects the current values of dataObject‘s properties.

In contrast to the cast methods, DataObject.project creates an additional, „detached“ copy of the data. Changes to the DataObject are not reflected in the projected object, or vice-versa.

The transitive closure is projected.

Other Static SDO issues

Enums Generics in static SDOs

Handling Types with unbound parameters

Collection Types Maps Representation of „any“ content

Summary of Proposals

1) Spec should state that static SDOs can be used as type description

2) Proposed annotations: here

3) Support for JAX-B annotations Since JAX-B XSD is defined, as is

XSD SDO, the mapping is clear. Optional feature?

4) Projections: HelperContext.cast()

5) JavaBean „DAS“

Thank you!

Questions?