Java Projections in SDO 3.0 Ron Barack - SAP …

Agenda n Pain Points n Frameworks and Data Representations n Proposals l Annotations l Projections between contexts l JavaBean DAS

Pain Point: Defining SDO Types n 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. l The only other standard way to define a type is through the API. n How static SDO’s become bound to types is awkward l Relies on annotating the XSDs l Is somewhat underspecified n 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. n For such applications, annotations of the JavaBeans is the most natural way to specify meta-information. n Problem Statement l Non-XSD Based Applications cannot easily define SDO Types. l Static SDOs must be annotated to be a possible source of metadata.

Defining Types through Side-files n Use-Case: neither Java nor XSD are suitable sources for metadata (e.g., because the Java or XSD cannot be altered). n Types could be serialized as {commonj.sdo}Type DataObjects, using standard XML serialization, but this serialization must be customized for this use case: l 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. l Should be consistent with reference to standard types. l This format is also used in the XML delivered with SDO 2.1 l Could be a Issue.

Pain Point: SCA cross application wiring n SCA Cross-Application Wiring l SCA allows calls between co-located applications (i.e., EAR). l Each application will have ist own class loader. l Static SDOs may be used in method signatures. n Problem Statement l The static SDOs may be packaged differently in each application. l 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 n Frameworks such as JAX-B and JPA use POJOs as data objects. l These POJO classes may be generated or hand written. l The frameworks introspect the POJO classes, and typically use injection to load values into the fields. l Injection may be setter or field-based. n JAX-B and JPA are intended to be used throughout the application, not just near the data source (a la EJB 2.x EntityBeans). n Framework POJOs typically do not interoperate – eg, you can‘t use your JAX-B classes as JPAs. n SOA Applications involve multiple frameworks, eg, read data from JPA and use it in a WebService response. n It is impractical to generate separate static SDO in cases where such POJOs already exist. l Domain models tend to be big… this would effectively double the number of classes. l Seems to require a copy step

Agenda n Pain Points n Frameworks and Data Representations n Proposals l Annotations l Projections between contexts l JavaBean DAS

Framework Imposed Programming Models n Frameworks impose Programming Models l data type definition language/methodology l interface description language/methodology l interface implementation requirements l framework behavior n Examples: l Session Bean with DTOs l JPA with persistent classes l JAX-WS bean with JAXB l BPEL with XSD+WSDL l SDO DAS with SDOs (just another framework) n If SDO wants acceptance, it must l Simplify transition between domains. l Interoperate with existing frameworks

Integration in SDO 2.1: SDO- Java/XML XSD as leading description of domain types n Java interface derived from schema (may require tooling) n 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)

SDO 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 n The JPA programming model is used. n The cast operation converts from the persistent object to SDO, not (necessarily) a java cast. n Additional meta information can be provided as annotations, or the cast operation can be used with an additional Type parameter. n Of course, everything is nicer if the objects returned from JPA already implement DataObject! use additional annotations to provide additional meta-data (e.g. for XML schema)

SDO Wires Between Frameworks n The JPA & JAX-WS programming models are used side-by-side, but loosely coupled, so they cannot share classes. n The project operation (lazily) creates an entire graph of POJOs. n The DataObject.cast operation creates a facade (proxy) object, that extends the target class and implements DataObject. n If the target class is a POJO, this may involve a copy step, since the fields will need to be filled.

Agenda n Pain Points n Frameworks and Data Representations n Proposals l Annotations l JavaBean DAS l Projections between contexts

Proposal: Classes as Type Descriptions n Types can be defined by calling Type t = typeHelper.getType(MyType.class); n To define a type, and create an instance: DataObject o = dataFactory.create(MyType.class); n Of course, only the first call actually creates the type. n Assuming containment requirements are relaxed, unaltered classes will often be enough, otherwise mapping can be tuned with annotations or side files. n 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 dataObject.create(Class 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 where targetClass.isInstance(returnValue) and returnValue instanceof DataObject return true.

Loose Coupling of DataObjects with Static SDOs n Static SDOs are „projections“ of SDO DataObjects into Java, similar to how XML documents are „projections“ for SDO DataObjects into XML. n It should be possible to have multiple Java projections of the same DataObject, like multiple views of the same DB table. n 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 public class RonJaxB public String public class RonSDO public String getName() DATA OBJECT Name: Ron Major: Computer Sci Year: Junior …

Proposal: Native SDO Annotations n Achieve richness of metamodel comparable to what can be achieved using XSD. n Annotate Java classes in a way that is natural when thinking in terms of SDO metadata. n Complement standard annotations (e.g., JAX-B, JPA) l Current proposal complements JPA nicely, but has overlap with uri=" sdoName="ShoppingCart") public interface IShoppingCart long List getItems(); void setItems(List 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? n 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. n 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. n JAX-B uses annotated JavaBean implementation classes, SDO needs to allow interfaces to be used as static SDOs. n Not part of JavaSE until Java 6.

Proposal: Harmonizing with JAX-B JAX-B cannot be ignored, SDO should not compete with JAX-B! n There is a lot of overlap, and definitely cases where JAX-B is sufficient. n 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: n We want to be able to understand JAX-B (and JPA), but not be limited to them. n JAX-B is „just another“ projection

Agenda n Pain Points n Frameworks and Data Representations n Proposals l Annotations l Projections between contexts l JavaBean DAS

The same type, different contexts n HelperContexts may hold contrasting definitions of the same type (as identified by its (URI, Name) pair. n The type definitions may come from different sources. One may be defined by parsing an XSD, the other by inspecting a Java interface. n 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

n 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. n Casting a data object into a different context returns an object with the following characteristics l The type of the created object is the corresponding type from the other context. l Both data objects reflect the same underlying data. Changes to one are visible in the other. No copy step is necessary. l 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 Ron HelperContext xmlContext = … DataObject cal = xmlContext.getXmlHelper().load(…); HelperContext javaContext = … javaContext.getTypeHelper().getType(School.class); School projected = (School)javaContext.project(cal); public class School { String getName(); List 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 n 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. n 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. n The same SDO type can be „projected“ onto any number of XSDs. n 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“. n 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. n The same SDO type can be „projected“ onto any number of Java classes!

API: Applying a Projection with HelperContext.cast DataObject helperContext.cast(DataObject original) n 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. n 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. n 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 n Pain Points n Frameworks and Data Representations n Proposals l Annotations l Projections between contexts l JavaBean DAS

JavaBeans and static SDO We define 2 methods, DataFactory.cast and DataObject.project that effectively constitute a DAS for JavaBeans. n This is not intended as a general mapping framework, only as a data binding. n This functionality is separate from static SDO‘s. l 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 n Question: Do we need JavaHelper?

API: DataFactory.cast DataObject 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 dataObject.project() n 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. n The transitive closure is projected.

Other Static SDO issues n Enums n Generics in static SDOs l Handling Types with unbound parameters n Collection Types n Maps n Representation of „any“ content

Summary of Proposals 1)Spec should state that static SDOs can be used as type description 2)Proposed annotations: herehere 3)Support for JAX-B annotations lSince JAX-B  XSD is defined, as is XSD  SDO, the mapping is clear. lOptional feature? 4)Projections: HelperContext.cast() 5)JavaBean „DAS“

Thank you! Questions?