1. Java Projections in SDO 3.0 First Draft Ron Barack

2.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT Agenda Pain Points Proposal API

3.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT 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 classloaders, 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).

4.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT 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

5.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT Pain Point: Harmonizing SDO with Frameworks Frameworks such as JAX-B and JPA use POJO classes 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 EntityBeans). Framework POJOs typically do not interoperate – eg, you can‘t use your JAX-B classes as JPAs. 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 aready exist. –Domain models tend to be big… this would effectively double the number of classes. –Seems to require a copy step SDO should be the glue for bridging frameworks

6.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT 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

7.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT Integration in SDO 2.1: SDO-Java/XML XSD as leading description of 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 -: 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)

8.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT SDO 2.1 + Annotations: SDO-Java/XML SDO type derived from Java Interface. XML schema generated as needed. +: prepared for cross-technology use- cases (anything java/wsdl) -: currently SAP-only. Proposed for SDO 3.0. -: simple scale-out from Java scenario to XML-based technologies -: 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)

9.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT Proposal: 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 metainformation 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! use sdo annotations to provide additional meta- data (e.g. for XML schema)

10.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT Proposal: SDO Glues Frameworks Together Pojo.java. IService.java sdo u s e DB JPA t y p e s i n t e r f a c e s i m p l e m e n t a t i o n service impl p a s s f r a m e w o r k JaxB.java. IService.java u s e JAX-WS service impl p a s s cast project The JPA & JAX-WS programming models are used side-by-side. The project operation creates a POJO, in fact, 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. Navigating from the projection returns objects that are themselves projections, i.e., implement DataObject as well as extending the target class.

11.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT Proposal: SDO Projections into static Java 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!

12.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT A POJO DAS Integrated into SDO The DataFactory.cast and DataObject.project methods constitute effectively a DAS for POJOs. 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 implement (or extend) the POJO class. Question: Do we need JavaHelper?

13.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT DataObject.cast creates static SDOs Static SDOs Provide type-safe and programmer friendly access to SDO data. Maintain ChangeSummary and other SDO properties. Can be casted (the Java op) to DataObject. Target classes may be interfaces or POJOs Casting to an interface constructs a proxy object…no copy step is involved. Casting to a POJO necessarily involves a copy step, since the fields of the newly created object must be filled...but my be done lazilly. For all properties in the SDO the corresponding setter is called in the constructed POJO The SDO runtime assures data consistency of all projections.

14.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT Special Case: Converting to/ from a JAX-B object The mapping between the methods defined on the target interface and the properties in the DataType is not necessarily „standard“ mapping defined in Chapter 5 of the SDO 2.1 spec. This wrapping could take into account annotations as well as method signatures (eg, JAXB annotations). The logic that does the mapping would also be responsible for any type conversions that are part of the projections, for example, it could wrap values in JAXBElement. A marker (@XmlType) could have to be used to signify which mapping applies. The extended class could be annotated with @XmlJavaTypeAdapter

15.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT API: DataFactory.cast DataObject DataFactory.cast(Object arg) DataObject DataFactory.cast(Object arg, Type type) These methods „cast“ a POJO object, returning an SDO DataObject. The SDO Type of the returnValue is either derived through introspection of the class, or given as a parameter. If arg is already castable to DataObject, the same instance will be returned. In any case, 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.

16.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT API: DataObject.cast T dataObject.cast(Class targetClass) This method „casts“ a DataObject into a static POJO class (or interface), returning a static SDO where both targetClass.isInstance(returnValue) and returnValue instanceof DataObject return true. The values of dataObject ‘s properties are available in the returnValue. Setters called on returnValue also change the value of dataObject ‘s properties. Navigating from returnValue returns objects that are casted, ie, implement DataObject and extend/implement a POJO class/interface. Effectively, the transitive closure is casted, although this may be done lazilly. Question: How is polymorphism handled? How do we know what the projected class should be if reflection doesn‘t tell us?

17.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT API: DataObject.project T dataObject.project(Class targetClass) This method „projects“ a DataObject into a static POJO class, returning an instance of the targetClass. The state of the created object reflects the current values of dataObject ‘s properties. DataObject.cast provides an additional view of the same underlying data. 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. Question: How is polymorphism handled? How do we know what the projected class should be if reflection doesn‘t tell us?

18.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT API: DataFactory.create T dataObject.create(Class targetClass) This method is not new, but it is included since it shows how an SDO-enabled JPA or JAX-B implementierung could create an instance of a static SDO where targetClass.isInstance(returnValue) and returnValue instanceof DataObject return true.

19.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT Type.instanceClass For backwards compatibility, Type still has instanceClass When a call is made to a method that returns a DataObject(eg, getRootObject(), getContainer()) instanceClass defines the „default projection“: the return object is castable to the instance class. But results can still be casted to any appropriate static SDO. Use of „project“ and „cast“ should be prefered over java casts. SDO 2.1 RootObjectType d = (RootObjectType)xmlDocument.getRootObject(); SDO 3.0 RootObjectType d = xmlDocument.getRootObject().project(RootObjectType.class); Calling a getter on a static SDO naturally returns a properly typed object. For set(Object)/ get(Object) where object is a projection, this pattern could be awkward. You set a static SDO, and get back a DataObject that must be projected to the static class. Especially awkward for Lists…every element needs to be casted.

20.  SAP AG 2007, Containment in SDO 3.0 / Ron Barack / First Draft DRAFT Other ideas regarding projections. For casting to or from POJOs, annotations can be either on methods or on fields. Current proposal is that the runtime keeps all casts in sync. Is this really necessary? Should we detach them? The main reason not to is that interface projections do not require a copy step, they can really refer to the same data, so in this case it would be very inefficient to require a copy step.