Java Polis 2003 JDO Java Data Objects What

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

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. http: //www. ronsoft. com © 2003, Ronsoft Technologies

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) http: //www. ronsoft. com © 2003, Ronsoft Technologies

Bye bye SQL JDO (or something like it) could revolutionize the way applications are

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 http: //www. ronsoft. com © 2003, Ronsoft Technologies

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

How JDO Works § § § § Transparent Persistence by Reachability Object Lifecycle Inheritance

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 http: //www. ronsoft. com © 2003, Ronsoft Technologies

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) § Persistence. Manager instances maintain object caches, datastore access is optimized where possible http: //www. ronsoft. com © 2003, Ronsoft Technologies

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

Mediated Object Access client : Persistence. Manager make. Persistent(my. Object) my. Object: Persistence. Capable impl. SM: State. Manager jdo. Replace. State. Mananger(impl. SM) set. Foo(12) set. Int. Field (this, n, foo, 12) make. Transient(my. Object) jdo. Replace. State. Mananger(null) http: //www. ronsoft. com © 2003, Ronsoft Technologies

Persistence By Reachability § A Persistence. Capable 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-Persistence. Capable objects are serialized to the datastore § Deletion from datastore is done per object, not by reachability • No datastore garbage collection http: //www. ronsoft. com © 2003, Ronsoft Technologies

Simple JDO Example Persistence. Manager. Factory factory = JDOHelper. get. Persistence. Manager. Factory(props); Persistence. Manager pm = factory. get. Persistence. Manager(); Transaction trans = pm. current. Transaction(); User user = new User ("ron", "Ron Hitchens", "ron@ronsoft. com"); Address addr = new Address (“ 123 Main St. ”, “Somewhere”, “CA”, “ 12345”); user. set. Address (addr); trans. begin(); pm. make. Persistent (user); trans. commit(); pm. close(); Two objects were persisted: • The instance of User explicitly made persistent • The Address instance reachable from user http: //www. ronsoft. com © 2003, Ronsoft Technologies

JDO Object Lifecycle (1) POJO object instantiation Transient Object retrieved from datastore, instantiated by JDO Read a field Modify a field Hollow make. Persistent() Persistent New Modify a field Persistent Clean Persistent Dirty delete. Persistent() Persistent New Deleted delete. Persistent() http: //www. ronsoft. com Persistent Deleted delete. Persistent() © 2003, Ronsoft Technologies

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

Lifecycle Callbacks § An object may optionally implement the Instance. Callbacks interface • jdo. Post. Load(), jdo. Pre. Store(), jdo. Pre. Clear(), jdo. Pre. Delete() § 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 http: //www. ronsoft. com © 2003, Ronsoft Technologies

Inheritance § Polymorphism is supported • Base type must be Persistence. Capable • 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 http: //www. ronsoft. com © 2003, Ronsoft Technologies

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 Persistence. Manager Datastore Identity vs. Application Identity - Datastore Identity assigned automatically - Application Identity defined by programmer • Persisted objects are retrieved by their identity http: //www. ronsoft. com © 2003, Ronsoft Technologies

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

Queries – Single Object By ID Customer get. Customer. By. Id. String (String id. Str, Persistence. Manager pm) { Object id = pm. new. Object. Id. Instance ( Customer. class, id. Str); Object customer = pm. get. Object. By. Id (id, true); return ((Customer) customer); } http: //www. ronsoft. com © 2003, Ronsoft Technologies

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. get. Extent (Customer. class, true); Iterator it = e. iterator() while (it. has. Next()) { Customer customer = (Customer) it. next(); customer. compute. Daily. Interest(); } http: //www. ronsoft. com © 2003, Ronsoft Technologies

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 http: //www. ronsoft. com © 2003, Ronsoft Technologies

Queries – Filter Example Collection get. Customers. By. City (City city, Persistence. Manager pm) { Extent extent = pm. get. Extent (Customer. class, true); String filter = “address. city == city”; Query query = pm. new. Query (extent, filter); query. declare. Parameters (“City city”); query. set. Ordering (“name ascending”); return (query. execute (city)); } http: //www. ronsoft. com © 2003, Ronsoft Technologies

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 http: //www. ronsoft. com © 2003, Ronsoft Technologies

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

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 Persistence. Manager instances § Persisted objects cannot outlive their owning Persistence. Manager • No disconnect/reconnect semantics http: //www. ronsoft. com © 2003, Ronsoft Technologies

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 http: //www. ronsoft. com © 2003, Ronsoft Technologies

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”) http: //www. ronsoft. com © 2003, Ronsoft Technologies

JDO and EJB § Can JDO and EJB Co-exist? • JDO can be used as a BMP strategy - Sun’s Sun. One 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 J 2 EE 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 http: //www. ronsoft. com © 2003, Ronsoft Technologies

What’s Similar to JDO? § CMP § Proprietary O/R tools • Toplink • Coco. Base • Many others § Open Source O/R tools • Hibernate* • Torque • OJB * Hibernate will have a JDO 2. 0 binding http: //www. ronsoft. com © 2003, Ronsoft Technologies

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

Where Can I Get More Info? § Web Resources • • • http: //access 1. sun. com/jdo/ http: //www. jdocentral. org/ http: //jdo-tools. sourceforge. net/ http: //groups. yahoo. com/Java. Data. Objects 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) http: //www. ronsoft. com © 2003, Ronsoft Technologies