1. July 7-11, 2003  Portland, Oregon JDO (Java Data Objects) What It Is And Why It Matters Ron Hitchens ron@ronsoft.com http://www.ronsoft.com JavaPolis 2003 - Antwerp, Belgium Dec 3, 2003 JavaPolis 2003 © 2003, Ronsoft Technologies

2. http://www.ronsoft.com Purpose of this Presentation To give you an introduction to JDO and show that it represents a significant change in the way that Java applications will manage their data.

3. © 2003, Ronsoft Technologies http://www.ronsoft.com Speaker Info  25+ years industry experience  6+ years using Java  Not a database expert  Built a website with JDO (www.europeasap.com)  O’Reilly author (Java NIO)  Tech reviewer on JDO book (Russell & Jordan)

4. © 2003, Ronsoft Technologies http://www.ronsoft.com Bye bye SQL JDO (or something like it) could revolutionize the way applications are created in the future.

5. © 2003, Ronsoft Technologies http://www.ronsoft.com What is JDO?  Recently finalized Java standard extension JSR 12 (http://jcp.org)  Transparent object persistence No code changes to persisted objects Standardized API Vendor neutral Datastore neutral  Not an object database May use conventional RDBMS, OODB or other means to store object data - datastore

6. © 2003, Ronsoft Technologies http://www.ronsoft.com JVM Datastore POJO SPI PM: Persistence Manager POJO: Plain Old Java Object* API: Application Programming Interface SPI: Service Provider Interface PM Persist Query JDO API JDO Impl * Implements PersistenceCapable at runtime

7. © 2003, Ronsoft Technologies http://www.ronsoft.com How JDO Works  Transparent Persistence  Persistence by Reachability  Object Lifecycle  Inheritance  Identity  Queries  Metadata  Restrictions

8. © 2003, Ronsoft Technologies http://www.ronsoft.com Transparent Persistence  Transparent to Persisted Objects No source code changes to needed to make objects persistent Clients are unaware an object is persistent Persisted objects are auto-loaded when referenced  Not Transparent to Entire Application JDO APIs are used to manage and query for objects Transaction boundaries affect persistent object state Object instances are per-PM – collisions in the datastore are possible at commit

9. © 2003, Ronsoft Technologies http://www.ronsoft.com Transparent Data Access  Objects and object fields are lazy-loaded when referenced  Changes to object state result in eventual updates to datastore without explicit saves (subject to transaction boundaries)  PersistenceManager instances maintain object caches, datastore access is optimized where possible

10. © 2003, Ronsoft Technologies http://www.ronsoft.com PersistenceCapable  The interface that all persistent objects must implement at runtime Byte code enhancement Source code pre-processing Direct implementation by programmer  PersistenceManager Primary access point to the JDO framework Operates on PersistenceCapable objects Maintains transaction context  StateManager Set per-object through the PersistenceCapable interface Manages an object’s state while persistent Mediates access to an object’s fields SPI hook into runtime JDO Implementation

11. © 2003, Ronsoft Technologies http://www.ronsoft.com Mediated Object Access client:PersistenceManager myObject: PersistenceCapable implSM: StateManager makePersistent(myObject) jdoReplaceStateMananger(implSM) setFoo(12) setIntField (this, n, foo, 12) makeTransient(myObject) jdoReplaceStateMananger(null)

12. © 2003, Ronsoft Technologies http://www.ronsoft.com Persistence By Reachability  A PersistenceCapable object instance is either persistent or transient at any given point in time  All objects referenced directly or indirectly by a persisted object are automatically made persistent at transaction commit. Persistence applies to the entire object graph Referenced non-PersistenceCapable objects are serialized to the datastore  Deletion from datastore is done per object, not by reachability No datastore garbage collection

13. © 2003, Ronsoft Technologies http://www.ronsoft.com Simple JDO Example PersistenceManagerFactory factory = JDOHelper.getPersistenceManagerFactory(props); PersistenceManager pm = factory.getPersistenceManager(); Transaction trans = pm.currentTransaction(); User user = new User ("ron", "Ron Hitchens", "ron@ronsoft.com"); Address addr = new Address (“123 Main St.”, “Somewhere”, “CA”, “12345”); user.setAddress (addr); trans.begin(); pm.makePersistent (user); trans.commit(); pm.close(); Two objects were persisted: The instance of User explicitly made persistent The Address instance reachable from user

14. © 2003, Ronsoft Technologies http://www.ronsoft.com JDO Object Lifecycle (1) Persistent New Transient Persistent New Deleted Persistent Deleted Hollow Persistent CleanPersistent Dirty deletePersistent() Modify a fieldRead a field deletePersistent() Object retrieved from datastore, instantiated by JDOPOJO object instantiation Modify a field makePersistent() deletePersistent()

15. © 2003, Ronsoft Technologies http://www.ronsoft.com JDO Object Lifecycle (2) Hollow Transient Persistent Clean Persistent Dirty Persistent New Persistent Deleted Transaction Completion commit(), rollback() commit() rollback() commit()

16. © 2003, Ronsoft Technologies http://www.ronsoft.com Lifecycle Callbacks  An object may optionally implement the InstanceCallbacks interface jdoPostLoad(), jdoPreStore(), jdoPreClear(), jdoPreDelete()  May be used to release resources when an object is going hollow  May be used to reconstitute transient values that can be recalculated from persisted fields.  May be used to do cascading deletes  Couples the object to JDO

17. © 2003, Ronsoft Technologies http://www.ronsoft.com Inheritance  Polymorphism is supported Base type must be PersistenceCapable Persistent super classes must be listed in metadata definition Queries may return subclasses, if requested  Implementation defines table mapping strategy Single Table, Class Table, Concrete Class Table  Interfaces may not be directly persisted

18. © 2003, Ronsoft Technologies http://www.ronsoft.com JDO Identity  Each Persistent Object has a unique JDO Identity Not the same as Java identity JDO Identity is encapsulated as an Object One instance per identity per PersistenceManager Datastore Identity vs. Application Identity -Datastore Identity assigned automatically -Application Identity defined by programmer Persisted objects are retrieved by their identity

19. © 2003, Ronsoft Technologies http://www.ronsoft.com Queries  Three ways of retrieving objects 1.Single object, by identity 2.Objects of a particular type – Extents 3.Objects whose fields contain specific values – Filters

20. © 2003, Ronsoft Technologies http://www.ronsoft.com Queries – Single Object By ID Customer getCustomerByIdString (String idStr, PersistenceManager pm) { Object id = pm.newObjectIdInstance ( Customer.class, idStr); Object customer = pm.getObjectById (id, true); return ((Customer) customer); }

21. © 2003, Ronsoft Technologies http://www.ronsoft.com Queries – Extent  A collection-like object representing a set of persistent objects, of a specified type, in the datastore  May contain subclasses, if requested Extent e = pm.getExtent (Customer.class, true); Iterator it = e.iterator() while (it.hasNext()) { Customer customer = (Customer) it.next(); customer.computeDailyInterest(); }

22. © 2003, Ronsoft Technologies http://www.ronsoft.com Queries – Filters  Filters run against Extents Objects filtered are always of the type in the extent, possibly including subclasses  JDOQL – JDO Query Language Java-like syntax Parameters and variables may be supplied Datastore agnostic, references Java object fields  Filters are applied by the Query class Returns a collection of matched objects

23. © 2003, Ronsoft Technologies http://www.ronsoft.com Queries – Filter Example Collection getCustomersByCity (City city, PersistenceManager pm) { Extent extent = pm.getExtent (Customer.class, true); String filter = “address.city == city”; Query query = pm.newQuery (extent, filter); query.declareParameters (“City city”); query.setOrdering (“name ascending”); return (query.execute (city)); }

24. © 2003, Ronsoft Technologies http://www.ronsoft.com JDO Metadata  Provides mapping information to the JDO implementation about classes and fields  Standardized JDO descriptor (XML) Supplies information that cannot be determined by reflection Allows for override of defaults Provides for vendor extensions  Can be used to automatically generate a schema

25. © 2003, Ronsoft Technologies http://www.ronsoft.com Datastore JDO Metadata JDO Impl Object WorldDatabase World JDO API POJO Object Types and RelationshipsHow and where to store object data

26. © 2003, Ronsoft Technologies http://www.ronsoft.com JDO Restrictions  Not all objects are persistable Streams, Sockets, many system classes, etc  Collections must be homogenous Element type must be declared in metadata  Maps may have restrictions on key types  List ordering may not be preserved  Objects cannot migrate between PersistenceManager instances  Persisted objects cannot outlive their owning PersistenceManager No disconnect/reconnect semantics

27. © 2003, Ronsoft Technologies http://www.ronsoft.com Why JDO Matters [1]  The Object Model IS the Data Model Datastore is one component in the system, not the center of the universe Promotes datastore independence at design, development and deploy times One language - no embedded SQL in the Java code  End-to-end OO design is possible – One system architecture  More agile – Datastore is an implementation detail

28. © 2003, Ronsoft Technologies http://www.ronsoft.com Why JDO Matters [2]  Separation of Concerns Java Guy and DBA Guy do separate jobs No SQL strings buried in the Java code Leverage object persistence expertise of JDO implementors  Cost Standard API – Leverage developers Lightweight – No special container needed Competition among compliant vendors Legacy databases can be wrapped by JDO objects Less work to do overall (“Maximize the work not done”)

29. © 2003, Ronsoft Technologies http://www.ronsoft.com JDO and EJB  Can JDO and EJB Co-exist? JDO can be used as a BMP strategy -Sun’s SunOne App Server uses JDO for CMP JDO can plugin to any JCA compliant App Server and participate in managed transactions Layered architecture -One app may use JDO objects directly -Another may use the same objects within EJBs to leverage other J2EE container services Using JDO/BMP may be more cost-effective than paying for full CMP capability Most Entity Beans uses are JDO-like anyway -Aren’t distributed -Don’t need access controls -Aren’t remote

30. © 2003, Ronsoft Technologies http://www.ronsoft.com What’s Similar to JDO?  CMP  Proprietary O/R tools Toplink CocoBase Many others  Open Source O/R tools Hibernate* Torque OJB * Hibernate will have a JDO 2.0 binding

31. © 2003, Ronsoft Technologies http://www.ronsoft.com Where Can I Get JDO?  JDO Vendors Solarmetric (www.solarmetric.com) Libelis (www.libelis.com) JDO Genie (www.hemtech.co.za/jdo/) Poet FastObjects (www.fastobjects.com)  Open Source Options Apache OJB (db.apache.org/ojb/) JORM (www.objectweb.com/  See www.jdocentral.com for more

32. © 2003, Ronsoft Technologies http://www.ronsoft.com Where Can I Get More Info?  Web Resources http://access1.sun.com/jdo/ http://www.jdocentral.org/ http://jdo-tools.sourceforge.net/ http://groups.yahoo.com/JavaDataObjects http://onjava.com (search for JDO) Google “Java Data Objects”  Publications Java Data Objects (Russell & Jordan) -http://www.oreilly.com/catalog/jvadtaobj/ Java Data Objects (Roos)

33. © 2003, Ronsoft Technologies http://www.ronsoft.com Questions? Ron Hitchens ron@ronsoft.com http://www.ronsoft.com

34. © 2003, Ronsoft Technologies http://www.ronsoft.com JavaPolis 2003