Your SlideShare is downloading. ×
JDO Presentation given at Java User Group Switzerland (JUGS) on 31.03.05
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

JDO Presentation given at Java User Group Switzerland (JUGS) on 31.03.05


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Many applications deal with “data”. It is very natural for both OOP developers as well as for other stakeholders such as subject matter experts to think in terms of objects for that data, a Domain Model, the class “Customer” with a String name and the Collection of associated Order instances etc. But objects “die” when you “pull the plug” – they are in-memory constructs of our software. So the question that invariably comes up is: how do we “keep” those objects? More technically speaking, how and when should we store/save those objects somewhere, how do we find them again, how do we do this transactionally, how do we do all of this efficiently? Of course, we have all seen different approaches to this: Business objects with Save methods and dirty flags, persistence related code more or less intermixed with domain related code (AKA your in-house object persistence layer), or with no real domain model in the application code at all, and natively interfacing with the API of your datastore, only. Transparent, or orthogonal, Object Persistence is a concept in which an application and more importantly the domain model is independent of the underlying persistence infrastructure. Developers are able to work with objects marked once as persistent directly in their code, just like with any other application objects. Create your new Customer, call some persist() method – and you are done. Add a new Order object – it becomes “persistent by reachability”. While that may sound simplistic, conceptually object persistence really doesn’t have to be more complicated. Finding those persistent objects again doesn’t have to be complicated either – think OOP, think Java, navigate through the domain model data object graph: Get the Orders for a Customers by calling something like a getOrders() method on the Customer class, a real and simple plain old java object POJO, implemented simply as a return of some private orders collections. Of course, sometimes you don’t have a reference, e.g. somehow we have to find the Customer first – a chicken and egg problem. Instead of adding all instances [of a certain class] to a big allObjects Collection, which I mention because conceptually I think it’s interesting to think of it that way, all persistence frameworks offer some query language and API; some have a concept called root or named objects in addition. Then there are Transactions and Concurrency… certainly an entire topic on it’s own, but in the context of transparent object persistence, as long as the persistence layer has a way of being informed when we are about to start making changes that are to be considered a “unit” from a functional point of view, and when we are done making those changes (commit) or don’t actually want to make them (abort), then any real persistence layer ensure the ACID [Atomicity, Consistency, Isolation, Durability] transactional properties and handle concurrency issues with one of the known locking approaches etc. Many concerns can conceptually be considered “internal” to a truly transparent persistence layer. For example, while we have spoken about the domain model object graph, and how relationships can be traversed etc, I didn’t mean to imply that the entire graph be physically in memory… indeed all real and scalable persistence frameworks of course provide partial read or updates, loading-as-needed, caches, expirations, etc. But those are essentially “under the hood” and internal issues that you generally should have no interest in from the model and the using application’s point of view. One last note before moving on to the next slide: We haven’t spoken about relational databases so far – I prefer the term “datastore” concerning what we have spoken up here. A datastore can be, and certainly very often is, a relational database. An object database is another form of datastore, agreed historically not very popular, but still something to keep in mind. So is an LDAP directory. A modern content repository is also a datastore..
  • JDO does not require e.g. member variables to be public or package local, or user-written implementation of certain interfaces or superclass extension. Nor does it prevent the same – public member variables can work – if entire code is byte code enhanced.
  • Single-String JDOQL Form: Complete String form, not necessarily String + API calls; e.g. for sorting, and new features Projections: Result is no longer necessarily subset of candidate collection, but could just a few attributes (SQL select like) Aggregates: Allows min, max, avg, sum, count. Group By and Having. More String expressions More numeric, Map functions Paging query results Native SQL User-defined Result Class
  • JDO 2.0 JSR first rejected, I'd say because of "political reasons"
  • Data Transfer Objects, Value Objects
  • Serializable for Remote DTO – JDO will never Serialize
  • Implicit detachment also if the instance or an instance containing a reference to the instance is serialized; or the persistence manager managing the instance is closed and the new DetachOnClose property is true.
  • Outside J2EE container, how to access & use not yet clear, apparently. I asked the question to the EJB Spec Lead at the Server Side Conference, and the response, if I understood it correctly, was something to the effect of ... or Hibernate, or TopLink - more or less ignoring the fact that a JCP approved javax.* API for persistence already existed. Last year, a window of opportunity - It hasn't happened - Point it: That discussion is probably history now.
  • Also Persistence Metadata – separate. JDO2 and EJB3 detachment behavior is also in alignment: This means that semantic behavior of domain model is thesame in both EJB3 and JDO2
  • Oracle apparently already has implementation? Now 2-3y is a LONG time out in this industry... ;-) Personally, I think JDO is going to stick around longer than some people think, but in the end will be replaced by “EJB” 3.x persistence… which will have nothing much to do with “EJB” as we know and think of it today. Interesting what this will mean for the “container” as we know it today… think BEA WebLogic, IBM WebSphere. I’d say they’ll possibly pick up JDO vendors – maybe not. JDO vendors tell everybody who is willing to listen loud and clear. Tough sale, but not unheard of (e.g. a Versant ODB implementation for "1000 times faster" WebSphere EJB 2.1 Entity Beans)
  • Transcript

    • 1. Java Data Objects (JDO) Overview and Future Michael Vorburger, Vertical*i Java User Group Switzerland Zurich, 31.03.05
    • 2. Agenda
      • Object Persistence
      • O/R Mapping (ORM)
      • History
      • JDO Introduction
      • JDO API
      • JDOQL
      • JDO 2.0 (JSR 243)
      • JDO Implementations (Vendors & OSS)
      • Using JDO in EJB 2.1
      • Using JDO in Web Apps
      • Using JDO and/or JDBC
      • EJB 3.0 (JSR 220)
      • Future
    • 3. About Speaker
      • Personal interest in persistence space
      • Culprit for an in-house ORM layer
      • Somehow picked up JDO in 2001
      • Core Java Data Objects co-author
      • For past ca. 3 years user of JDO
    • 4. About Audience
      • How many of you would consider themselves “moderately familiar” with JDO, or another similar persistence framework, anyway?
      • How many of you have read the JDO 2.0 and EJB 3.0 Persistence Specs?
    • 5. Object Persistence Concepts
      • Graph of data objects (“Domain Model”)
      • API: persist(), Persistence by Reachability
      • Transactions
      • Query!
      • Internal: Memory Management, Caching, etc.
    • 6. O/R Mapping (ORM)
      • “ Impedance Mismatch” of OOP & RBDMS:
      • Classes vs. Tables, Inheritance mapping strategies
      • Relationships: Single 1-1 or 1-M, Multiple M-N, “Link with attributes” DBA mixed data and relationship, Inverses/Bi-directionality, Lists, Maps
      • Identity Management, Uniqueness
      • Class Attribute vs. Column Type Mappings
      • More in Core JDO Book Chapter 2, but: Solutions for
      • mismatches exist; see also your ORM Vendor Doc!
    • 7. History
      • Few things fall from the sky… object persistence in general and JDO in particular build upon a “long” history
      • Have you heard of any of these names before?
      • CORBA POS Persistent Object Service
      • Project Forest of Sun Labs (OPJ, PJama)
      • ODMG API
      • Gemstone, O2, …
      • TopLink (15y+)
      • (EJB 2.1 Entity Beans)
    • 8. JDO Introduction
      • JDO is an “interface-based API for selection and transformation of transactional persistent storage data into native Java programming language objects” – Transparent Object Persistence!
      • Various implements for this API exist: Most as ORM for your favourite RDB; some for standalone or built-in OODBMS.
      • JDO 1.0 (JSR 12) in 2003
      • JDO 2.0 (JSR 243) Extension, accepted 1m ago
    • 9. JDO API: PMF & PM
      • PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory(Properties p);
      • javax.jdo.PersistenceManager pm = pmf.getPersistenceManager();
      • pm.makePersistent(customer);
      • customer = pm.getObjectById(oid,true);
    • 10. JDO Metadata & Enhancement
      • JDO XML metadata describes which classes can be persisted (<class name=…>), with relevant options (<collection element-type=…>, <extension …>)
      • JDO implementation run-time needs to interact with persistence instances for lifecycle notification, load, store/flush. Generally, this is achieved by running a build-time tool, a JDO [byte code] enhancer. (It adds the PersistenceCapable interface from SPI API to persistent classes. This is no longer strictly for JDO compliance,see BinaryCompatibility. )
      • Subject of hot debates – strange, think AOP etc.
    • 11. JDO API: Transactions
      • Non-Managed
        • javax.jdo.Transaction jtx = pm.currentTransaction();
        • jtx.begin(); /* Do Stuff */ jtx.commit();
      • Managed (usually in J2EE container)
        • JTA API
          • javax.transaction.UserTransaction ut;
          • ut = {lookup somewhere, e.g. JNDI}; ut = ejbContext.getUserTransaction()
          • ut.begin(); /* Do Stuff */ ut.commit();
        • Declarative EJB container managed transactions
      • Core JDO Book Chapter 11
    • 12. JDO API: Query and JDOQL
      • Query q = pm.newQuery(Customer.class, &quot;customerName.startsWith('Tintin') && lastOrder.price > 100&quot;);
      • Collection results = (Collection)q.execute(); Iterator it = results.iterator(); while (it.hasNext()) { Customer cust = (Customer);
      • Parameters: q.declareParameters(“String variable&quot;) and q.execute(variable) etc. etc. – many many more query facilities!
    • 13. JDO Queries: More of v1.0
      • JDOQL “Filter” can contain almost all Java language operators, and some methods such as Collection.isEmpty() & contains() , String.startsWith() & endsWith() [But not arbitrary other domain model methods!]
      • Ordering
      • Free Variables
      • Compiled Queries
      • Namespaces (packages)
      • Navigation (“dots”) in Filters, Ordering, etc.
    • 14. JDO Queries: More in v2.0
      • Single-String JDOQL Form
      • String.matches(), toLowerCase(), toUpperCase(), indexOf() x2, substring() x2, Map.containsKey() & containsValue(), Math.abs() & sqrt().
      • Paging Query Results with Query.setRange() or “range :start to :end” and java.util.List results
      • User-Defined Result Class, single results, Unique
      • Projections, Aggregates functions
      • Standardized SQL pass-through
    • 15. JDO 2.0 News
      • Disconnected Object Graphs for multi-tier
      • Standardized RDBMS Mapping Descriptors (“just” the agreed upon XML language; many implementations already had possibilities)
      • Can get e.g. a java.sql.Connection from javax.jdo.PersistenceManager
      • More: newNamedQuery , FetchPlan , Sequence , delete by query, Multiple User Objects on PM, etc.
    • 16. JDO Implementations [DISCLAIMER]
      • Open Source
        • JPOX
        • ObjectWeb Speedo
        • TJDO
        • XORM (?)
        • Apache JDO 2.0 RI (?)
        • Orient (ODBMS, OSS is new)
      • Commercial JDO ORM Vendors
        • Solarmetric Kodo
        • Xcalia (formerly Libelis LiDO) .FR
        • Signsoft intellBO .DE
        • Versant Open Access (formerly JDO Genie)
        • Others, e.g. Exadel, ObjectFrontier, ObjectMatter, Spadesoft XJDO, …
      • Commercial non-ORM
        • Versant (incl. Poet)
        • ObjectDB (simple & inexpensive)
      • Non-JDO ORMs
        • JBoss Hibernate
        • Oracle Toplink
        • Castor JDO
        • OJB (?)
    • 17. JDO & EJB 2.1
      • EJB 2.1 CMP Entity Beans mixed persistence and remoting, with a complicated API and development model (container) – sorry, but consider that dead, essentially.
      • Session and Message-Driven Beans however certainly have their place. So JDO inside the implementation logic of those makes a lot of sense!
    • 18. JDO & EJB 2.1
      • When using JDO inside a RPC-like (“SOA”) EJB Session Bean (or RMI, Spring Remoting.. your-favourite-here) :
        • “ Syntax” aspects: About how to get…, when to… etc. For full code details see Core JDO book chapter 9 and/or Vendor Doc.
        • “ Architectural” aspects: How to write your DTOs (AKA VO) here – or do you write them at all?!
    • 19. JDO & EJB: DTO (AKA VO)
      • Either, “traditionally” write dedicated Serializable DTO/VO in addition to PC, maybe per service/use case. Nothing new; see Core J2EE Patterns etc.
      • Or, mark domain model PCs as Serializable (although JDO will never serialize) and use makeTransient (1.0) or detachCopy (2.0)
    • 20. JDO & EJB: detachCopy
      • New JDO 2.0 state: detached-clean/dirty. API:
        • Object PersistenceManager.detachCopy(Object pc);
        • Object PersistenceManager.attachCopy(Object detached, boolean makeTransactional);
      • Scenario: detach/disconnect, close PM, serialize across tier, modify disconnected, send back. New PM, new Tx, re-attach.
      • Keeps original identity and version!
      • Simplifies & makes safer the similar manual makeTransient() approach from Core JDO book chapter 9.
    • 21. JDO in the Web Tier (directly)
      • If your project does not need EJB-like remoting and physical separation of tiers, directly using JDO in the Web Tier (Struts, JSF, etc.) can be very nice, and lead to a simple and efficient development model!
      • Recommended Architecture: One shared PMF (application context) and one PM and Tx per request (context), managed by a Servlet Filter. Better: Enforce Web MVC with “Model 2” View, allowing “pull view” (e.g. JSP) but read-only; allow write changes in “Controller“ only.
    • 22. JDO and/or JDBC?
      • Using JDO (any ORM) does not necessarily mean no JDBC – mixing is possible and may make sense. (Tx safe) [VI LOB]
      • Core JDO Book chapter 12 has analysis – but outdated already because JDO 2.0 addresses some cases.
      • Still, of course, for data-centric, database processing intensive, performance sensitive e.g. batch kind applications, as well as for very complex existing fixed RDB schemas, ORM and thus JDO may not be the appropriate road to go.
    • 23. EJB 3.0
      • EJB 3.0 EG decided to abandon EJB 2.1 Entity Beans, and create new and separate Persistence Doc and API:
      • This will be an ORM not a transparent Persistence API. Some other differences. However, will also be usable in J2SE, outside J2EE container.
    • 24. EJB 3.0
      • Also a POJO-style approach. Many real world domain models will probably be usable with both APIs!
      • Both a similar API, conceptually close for practical purposes, e.g. life cycle aligned. EntityManager.persist() , EntityManager.createQuery() , javax.persistence.Query.getResultList()
      • Query Languages (JDOQL & EJBQL) differ, but maybe JDO 2.1 and EJB 3.1 allow cross-spec query language? (A la SQL in JDO 2.0)
    • 25. Future of Java Persistence
      • Today, the choice is JDO; why wait? A proven JCP standard with many implementations.
      • EJB 3 Final Release supposedly “summer 2005” (?). Requires JDK 5. Slow adoption?
      • Longer Term (2-3 years?) … who knows?
      • Note: All major JDO implementations very likely also EJB 3 &quot;persistence engines&quot;.
    • 26. Q & A
      • Thanks for listening!
      • To play with “running code” after this: – great tutorials!
      • Questions?
      • Drinks.