Introduction to Java Data Objects (JDO), Page 2
JDO versus EJB
Since the introduction of JDO, there has been speculation that JDO might replace entity beans. To understand this assertion, let's first examine exactly what an entity bean really is. Entity beans fall into two categories: container-managed persistence, called CMP beans; and bean-managed persistence, called BMP beans. BMP entity beans contain code that can store the bean contents to a permanent data store. BMP beans tend to be independent, and do not form direct relationships with other BMP beans. It is not likely that BMP beans will be replaced by JDO, as a BMP bean makes direct use of JDBC. This violates the design principal of JDO shielding the user from JDBC coding.
CMP beans allow the container to manage persistence. The container is whatever Web or application server is executing the bean. In this model, the bean contains no actual serialization code, such as JDBC. The container handles all actual storage and retrieval. CMP beans can also form the typical many-to-many and one-to-many relationships with other CMP beans.
First, you must look at the actual growth of CMP. CMP entity beans have yet to gain widespread support. Most of the EJB growth has been in the area of session and stateless EJBs. CMP seems to suffer from some of the same issues as JDO when it comes to widespread acceptance. This is that both CMP and JDO separate the programmer too far from what is actually happening at a SQL level. For complex queries, a CMP or JDO programmer may spend much time trying to figure out how the SQL query is being generated. Many programmers would rather have just programmed SQL in the first place.
However, despite any shortcomings of CMP or JDO, JDO may make sense for programmers who have already made the jump to CMP. JDO does many of the same things as CMP, and likely makes sense as a CMP replacement if your project is using JDO overall. Like many debates in the IT industry, the debate of CMP or JDO will likely remain as long as there is CMP and JDO.
JDO versus JDBC/SQL
JDO does not really seek to replace JDBC in the same sense that it might CMP. JDO can really be thought of as a layer on top of JDBC—at least for the foreseeable future. In most instances of JDO, you specify a JDBC data source that references the database that JDO is going be accessing. So, the question of JDO versus JDBC is more a case of whether you should be using JDBC directly or allowing JDO to use it for you.
There is much praise and criticism for JDO replacing JDBC. On one hand, JDO frees the programmer from having to construct SQL statements and retrieve result sets into individual data objects. If you consider that most JDBC queries are executed to populate Java objects, JDO makes a great deal of sense. Rather than executing queries and copying fields from your JDBC result sets into Java objects, this is all taken care of by JDO.
The criticism comes in the amount of overhead that JDO creates to do this. JDO must take a JDOQL query string and convert it into the correct SQL statement. Then, this SQL statement is submitted to the database, the results are retrieved, and then are stored into their respective objects. If there is a large number of relationships among the objects, it is very easy to cause JDO to access considerably more data than you needed. The performance argument will likely never be solved. JDBC is always going to be faster than JDO because it is more direct. It is up to you to decide whether the flexibility of JDO is worth the performance hit.
Another feature of JDO that receives much criticism and praise is the possibility of JDO replacing SQL. When using JDBC, you must use SQL to construct your queries. JDO uses JDOQL. JDOQL is based more upon Java than SQL. On one hand, JDOQL can be much easier to construct than SQL, especially for simple queries. On the other hand, you are not likely to find many programmers who currently know JDOQL. Because JDO does not seem to have caught on industry-wide at this point, this problem may continue for some time. Most programmers are already familiar with SQL and senior-level IT programmers are capable of producing complex, highly optimized, SQL queries. For many such programmers, a middle-level tool such as JDO that automatically creates queries, is an unwelcome step. Furthermore, SQL is a cross-platform, all-encompassing query language. JDOQL is locked into the world of Java. Ultimately, SQL may be replaced, but it seems more likely that the widespread replacement of SQL would be at the hand of a less vendor-specific technology.
Like most new technologies, you will find many opinions that are both for and against JDO. You must cut through marketing hype and understand what it will do for your core development process. At this point, it is difficult to state the future of JDO. We see it as a very promising technology that has come far for a first version.
The following are Web sites that contain additional information about JDO:
|Java Community Process:JSAR12||www.jcp.org/en/jsr/detail?id=12|
|Java Community Process||www.jcp.org|
|Sun Microsystems, Inc.||www.java.sun.com|
About the Authors
L. Oliver is a member of TDWI (Data Warehousing Institute) and PMI (Project Management Institute). She has experience as an IT Director, Programmer, Senior Systems Analyst, Project Manager, and a Data Architect/Data Architect Lead. She has experience in the Financial Services Industry and a strong background in relational database design. She is currently working as a Data Architect on a Data Warehousing Project.
Jeff Heaton is the author of JSTL: JSP Standard Tag Library (Sams, 2002) and Programming Spiders, Bots, and Aggregators (Sybex, 2002). Jeff is a member of IEEE and a graduate student at Washington University in St. Louis. Jeff can be contacted through his Web site at http://www.jeffheaton.com.
Page 2 of 2