SDO 3.0 Virtual F2F – Helper Contexts (Issue 96)

1. SDO 3.0 Virtual F2F – Helper Contexts (Issue 96) Blaise Doughan Team Lead, Oracle TopLink OXM, JAXB, & SDO Team Lead, EPS(EclipseLink) MOXy & SDO

2. Agenda Definitions Requirements • Multiple SDO Implementations • Creating Local Helper Contexts • Serialization Deprecating API Consequences and Implications Future Work?

3. Definitions • Global HelperContext – This is the HelperContext retrieved from HelperProvider.getDefaultContext(). The helpers/factories from this helper context correspond to the corresponding INSTANCE members (I.e. TypeHelper.INSTANCE). • Local Helper Context – This is a HelperContext that implements the HelperContext interface but is not the global HelperContext.

4. Requirements • Make it possible for multiple vendor implementations to co-exist. This should take the following into consideration: • Java SE and EE environments • OSGi environments • Other environments? • Create a standard means of creating local Helper Contexts. • Make it possible to serialize DataObjects between different SDO implementations.

5. Java SE and EE Environments A HelperContextFactory Impl will be looked for: • Allow user to specify the implementation of commonj.sdo.helper.HelperContextFactory they wish to use. • If no implementation is specified, then check if one was specified in the System property “commonj.sdo.helper.HelperContextFactory”. • If the System property is not set or this code does not have permission to read it then the name will be retrieved from the META-INF/services/commonj.sdo.helper.HelperContextFactory resource.

6. Proposed API – Obtain SDO Implcommonj.sdo.helper.SDO New Class – SDO • Responsible for obtaining SDO implementations, these implementations may be from different vendors. • Static API: • getHelperContextFactory(): HelperContextFactory • getHelperContextFactory(String implName): HelperContextFactory

7. SDO Impl Bundle SDO Impl Bundle SDO Public API Bundle SDO Bundle SDO Bundle SDO Impl SDO Impl Client Client Client Client Client OSGi Environments Interest has been expressed in supporting the following OSGi architectures:

8. Proposed API – OSGi Workaroundcommonj.sdo.helper.SDO Modify Class – SDO • In the absence of a pure OSGi solution, make the HelperContextFactory lookup pluggable. This will allow vendors to swap in alternate look up mechanisms. • Static API • getHelperContextFactoryResolver(): HelperContextFactoryResolver • setHelperContextFactoryResolver(HelperContextFactoryResolver) New Inner Interface – HelperContextFactoryResolver • SDO will delegate the implementation lookup to this class. A default implementation (that uses the previous defined rules) will also be provided. • API • getHelperContextFactory(): HelperContextFactory • getHelperContextFactory(String implName): HelperContextFactory

9. Proposed API – Local HC Creationcommonj.sdo.helper.HelperContextFactory New Class - HelperContextFactory • Responsible for getting the global HelperContext, and creating local HelperContexts. • API – The ClassLoader parameter represents the: ClassLoader for static SDOs if required, and the Map is useful for passing vendor specific information. • createHelperContext(): HelperContext • createHelperContext(Map): HelperContext • createHelperContext(ClassLoader): HelperContext • createHelperContext(ClassLoader, Map): HelperContext

10. Proposed API – Local HC Creation The creation of HelperContexts in SDO will feel very much the creation of Entity Managers in JPA. SDO SDO.getHelperContextFactory(String).createHelperContext(); JPA Persistence.createEntityManagerFactory(String).createEntityManager();

11. Standard Serialization in SDO??? Standard • Section 4 of the SDO 3.0 specification contains the recommended algorithm for serializing DataObjects. Not Standard • Section 4 also contains the following:“Using standard java.io.Serialization will ensure a degree of interoperability between different Java implementations. This method for serialization is not mandatory, however. If interoperability is not required, then other proprietary serialization schemes may be implemented. “

12. Proposed API – Serialization Modify Class – HelperContextFactory • Add the ability to create instances of Resolvable. • API – The abstract HelperContextFactory would contain real implementations of these methods. Of course implementers would be free to override these methods with their own proprietary serialization strategies. • createResolvable(): Resolvable • createResolvable(Object): Resolvable Note: If custom serialization is not required then neither are these methods.

13. Deprecation API The following API will be deprecated: • INSTANCE (on all SDO helpers and factories) • HelperProvider • HelperProvider will be modified so that all calls are delegated to the new framework.

14. Consequences and Implications • A user calling the following will not know which SDO implementation they are going to get: • SDO.getHelperContextFactory(); • Changes outside the scope of an application (I.e. Deploying to a different application server, re-ordering the class path, etc) can cause a different SDO implementation to be returned. • Users will expect switching between SDO implementations to be seamless. • As a spec group we will need to focus more on interoperability issues.

15. Proposed API – Are You Standard? Modify Class – HelperContextFactory • A HelperContextFactory will need to report if truly follows the SDO specification. Only SDO implementations that indicate that they are a standard implementation will be considered candidates for the following call: • SDO.getHelperContextFactory(); Of course they can still be obtained using the following API: • SDO.getHelperContextFactory(String); • API • isStandard(): boolean

16. Future Work? • Serialize to/from any Helper ContextIt would be convenient if a local HelperContext could be used to de-serialize a DataObject, currently this can only be done using the global HelperContext. Options for supporting this include: • Serializing HelperContext information (some/all) along with the DataObject. • Deserializing the DataObject into its own HelperContext and providing a mechanism to move it into an existing HelperContext (project operation?). • Removing the Global Helper ContextOnce we are able to deserialize to any HelperContext do we really need a global HelperContext?

17. Summary Definitions Requirements • Multiple SDO Implementations • Creating Local Helper Contexts • Serialization Deprecating API Consequences and Implications Future Work?