Java Projections in SDO 3.0 Ron Barack SAP

1
Java Projections in SDO 3.0Ron Barack - SAP

2
Agenda

• Pain Points
• Frameworks and Data Representations
• Proposals
• Annotations
• Projections between contexts
• JavaBean DAS

3
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 SDOs 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.

4
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.sdoType
  DataObjects, using standard XML serialization,
  but this serialization must be customized for
  this use case
• XML Serialization of commonj.sdoType and
  commonj.sdoProperty require special handling
  for the references to Type we want to see the
  URIName 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.

5
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).
6
Use-Case from SCA
Late Binding of static class to SDO type
7
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 cant 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

8
Agenda

• Pain Points
• Frameworks and Data Representations
• Proposals
• Annotations
• Projections between contexts
• JavaBean DAS

9
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 XSDWSDL
• SDO DAS with SDOs (just another framework)
• If SDO wants acceptance, it must
• Simplify transition between domains.
• Interoperate with existing frameworks

10
Integration in SDO 2.1 SDO-Java/XML
use sdolt..gt 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
• - 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!
11
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.
• 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!
12
SDO integrates with existing frameworks
use additional 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 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!

13
SDO Wires Between Frameworks

• 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.

14
Agenda

• Pain Points
• Frameworks and Data Representations
• Proposals
• Annotations
• JavaBean DAS
• Projections between contexts

15
Proposal Classes as Type Descriptions

• Types can be defined by calling
• Type 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

16
API DataFactory.create

• ltTgt T dataObject.create(ClassltTgt 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.

17
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.

_at_XmlType public class RonJaxB _at_XmlElement
public String getName()
_at_SdoType public class RonSDO _at_SdoProperty
public String getName()
DATA OBJECT Name Ron Major Computer Sci Year
Junior
18
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.

_at_SdoTypeMetaData( uri"http//www.sample.org/sh
op/", sdoName"ShoppingCart") public interface
IShoppingCart _at_Id long getId()
_at_SdoPropertyMetaData(opposite"cart")
ListltIShoppingCartItemgt getItems() void
setItems(ListltIShoppingCartItemgt
pItems) Date getCreated()
Date getLastModified() String getUser()
void setUser(String user)
This code mixes JPA and SDO annotations
19
Why not just use JAX-B annotations?

• In some places, JAX-B does not have preserve
  enough metadata. For example, whether a
  propertys type is a user-defined or standard
  type is not surfaced.
• Users will expect that the classs 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.

20
Proposal Harmonizing with JAX-B

• JAX-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

21
Agenda

• Pain Points
• Frameworks and Data Representations
• Proposals
• Annotations
• Projections between contexts
• JavaBean DAS

22
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.

23
Projecting between contexts

• 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.

24
Projecting between Contexts
lttnsSchoolgt ltstudentgt
ltnamegtRonlt/namegt ltcourses nameBasket
Weaving/gt ltcourses nameAlgol 68/gt
lt/studentgt lt/tnsStudentgt
HelperContext xmlContext DataObject cal
xmlContext.getXmlHelper().load() HelperContext
javaContext javaContext.getTypeHelper().getTyp
e(School.class) School projected
(School)javaContext.project(cal) entityManager.pe
rsist(projected)
_at_Entity public class School String
getName() ListltCoursegt 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.
25
Same proposal as for containment

• In SDO 2.1, XML specific information (eg,
  containment) is associated with the SDO type in a
  10..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 10..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!

26
API Applying a Projection with
HelperContext.cast

• DataObject 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.
  

27
Agenda

• Pain Points
• Frameworks and Data Representations
• Proposals
• Annotations
• Projections between contexts
• JavaBean DAS

28
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 SDOs.
• 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?

29
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 args properties are available in
  the returnValue.
• Setters called on returnValue also change the
  value of args properties. Setters called on arg
  directly change the value of returnValues
  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.

30
API DataObject.project

• ltTgt 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 dataObjects 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.

31
Other Static SDO issues

• Enums
• Generics in static SDOs
• Handling Types with unbound parameters
• Collection Types
• Maps
• Representation of any content

32
Summary of Proposals

• Spec should state that static SDOs can be used as
  type description
• Proposed annotations here
• Support for JAX-B annotations
• Since JAX-B ? XSD is defined, as is XSD ? SDO,
  the mapping is clear.
• Optional feature?
• Projections HelperContext.cast()
• JavaBean DAS

33
Thank you!

• Questions?