Java Projections in SDO 3.0 First Draft

1. Java Projections in SDO 3.0First Draft Ron Barack

2. Agenda • Pain Points • Proposal • API

3. 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. 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. Use-Case from SCA Late Binding of static class to SDO type On this side, a static SDO is used. SCA Wiring EJB SCA Wiring appies the projection, adding the static SDO like a facade to the SDO Data Object. RDB DAS

5. 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. 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. Integration in SDO 2.1: SDO-Java/XML use sdo:<..> attributes to provide additional meta-data (e.g. interface association) • 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 • -: 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!

8. SDO 2.1 + Annotations: SDO-Java/XML use sdo annotation (proprietary) to provide additional meta-data (e.g. for XML schema) • 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!

9. gen s x . xsd Pojo.java . e p y t cast e s e u s u sdo s e e c z a i f l r a pl . wsdl e i r t e n s i IService . java e s u x . xml n o i t a t n service e m impl e l proc . bpel p m i p s a s s a e p s s u k r o JPA BPEL w e engine m a r f DB Proposal: SDO integrates with existing frameworks use sdo annotations to provide additional meta-data (e.g. for XML schema) • 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!

10. Proposal: SDO Glues Frameworks Together • 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. s Pojo.java . e JaxB.java . p y t project cast e s e u s u sdo s e c a f r e t n i IService . java IService . java n o i t a t n service e service m impl e impl l p m i p p a s a s s s k r o JPA JAX-WS w e m a r f DB

11. 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. 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. 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. 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. 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. API: DataObject.cast • <T> T dataObject.cast(Class<T> 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. API: DataObject.project • <T> T dataObject.project(Class<T> 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. API: DataFactory.create • <T> T dataObject.create(Class<T> 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. 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. 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.