Data Objects « Database JDBC « Java Articles

In a past article on XML Databinding, I showed how you could work with Java objects and have them persist as XML files.

Java programmers like working with objects (I hope!). Applications often, if not always, need us to persist information. Most server-side developers have worked with the JDBC API, which allows us to access databases, and is mainly used to query relational databases. Since we already have our model in our objects, wouldn't it be nice to be able to persist the objects that it makes sense to store? It can be a real pain to write code that jumps from our objects and saves the values away into a database. This can also get tricky when you get into relationships between objects. The Serialization mechanism allows us to take an object and save the graph to a stream, but Serialization is not built to allow multi-user sharing.

Data binding, in a nutshell (this is O'Reilly, after all), allows a mapping of data from an XML document to a Java object, and then back again. Of course, this is nothing new to the world of Java and XML, as there are numerous APIs that already allow some variant of this behavior: SAX, DOM, JDOM, dom4j, JAXP, etc. The list goes on and on; however, data binding has something unique that makes it worth delving into. Each of the APIs I just rattled off are document-centric. That means that you are dealing with data in some XML representation. In other words, you will get the content from an element, the value of an attribute, or the name of an entity reference. The problem with this approach is that it forces you to work within an XML structure.

JDO (Java Data Objects) is a specification for transparent persistence being developed as JSR-000012 in the Java Community Process. Transparent persistence allows developers to store their Java objects in transactional data stores "transparently", meaning that they do not need to explicitly manage the field-by-field storage and retrieval to and from the data store.

This book excerpt is from Core Java Data Objects, by Sameer Tyagi, Michael Vorburger, Keiron McCammon, and Heiko Bobzin , ISBN 0131407317, copyright 2004. All rights reserved.

The task of persisting Java technology objects to any relational database is challenging because it involves serializing the hierarchically structured Java objects to a tabular-structured database and vice versa. This challenge is unique because of the need to map Java technology objects to database columns and records in a way that is optimized for both speed and efficiency. The Java Data Objects (JDO) specification, Java Specification Request (JSR) 12, defines an API for a standard way to transparently persist plain Java technology object and database access. Using JDO, Java application developers can write code to access the underlying data store without using any database-specific code. JDO is designed to work in multiple tiers of an enterprise architecture including the Java Platform, Standard Edition (Java SE, formerly known as J2SE), web tier, and application servers.

Frank Sommers: There are currently several proposals to add native property support to the Java language. To what extent would language-level properties make data binding an easier task?

Downloading the code jar gives you full source code for the test program and all the data binding framework test cases. When the jar is unpacked (using jar -xvf xmlbind.jar" in an empty directory, or using a zip file tool) you'll find a test.sh file in the root directory. This is the actual Linux script I used to generate the results shown in the charts, and you can use it as an example of the command line parameters expected by the test program -- but note that to run it you'll need to also download the jar files for any frameworks you want to test and copy them into the lib subdirectory (see the Resources section for links to the framework sites). The jar files for the test program itself, the JiBX runtime, and the XMLPull parser used by the JiBX are already present in the lib subdirectory, and the XML documents used are in the docs subdirectory (along with the JavaDocs for the code).

At this point you should have a basic understanding of Service Data Objects and the JDBC DMS that WebSphere Application Server V6.x provides and where these technologies fit into the growing number of persistent data object technologies like Enterprise JavaBeans. These technologies are not the best architectural choice for every application, so take care when making the decision to use SDOs and the JDBC Data Mediator Service in your application.

Specifically, when most programmers hear data binding, they actually think XML data binding. The insertion of that little word?XML?causes most programmers to miss out on a world of extra functionality and flexibility, especially if the Castor API is being used. That's because when it comes to Castor, XML data binding is just a part of the puzzle. Castor also offers the ability to bind Java data to SQL databases, in addition to binding to XML documents. That's where SQL data binding comes into play.

Also, read "Next-Generation Data Programming: Service Data Objects," a whitepaper jointly prepared by IBM and BEA, for additional information on the Service Data Objects API.

The first question most developers will ask about Service Data Objects (SDO) is why. Isn't J2EE big and complex enough (and hard enough to learn) as it is? Also, other frameworks already support XML in the Java environment, don't they? The answer, fortunately, is one that should make most of us quite happy: SDO emerged as a means of simplifying the J2EE data programming model, thus giving J2EE developers more time to focus on the business logic of their applications.

Part 1 of this article series provided an introduction to Java? DataBase Connectivity (JDBC) Data Mediator Service (DMS)-based queries as well as a model for a typical SDO and JDBC DMS application. Part 2 examines several techniques and coding best practices that you can use to improve the performance of your SDO and JDBC DMS application. These techniques include:

At this point?assuming that you got the same cds.xml and output from UnmarshalTester ?you have a working installation. While you haven't done anything particularly complicated with Castor, you have done enough to make sure that Castor is working, your JAR files are set up properly, and Castor can do what it needs to do.

Simplify your Java? database programming with Java Data Objects (JDO), the first standardized, completely object-oriented approach to object persistence. This tutorial, which is designed for the intermediate to advanced Java developer with a solid understanding of relational databases, uses discussion, code samples, and hands-on exercises to demonstrate the practical application of JDO. (Updated source July 15, 2002.)

To start, note that using mapping files?with Castor or any other data binding framework?takes some time. You'll have to learn some new syntax, first of all. Even if the mapping file uses XML as the format?and most frameworks do just that?you'll have new elements and attributes to figure out. You'll also have to do more testing, ensuring that mapping from XML to Java code, or Java code to XML, produces the results you want and expect. And finally, you'll encounter a lot more errors in data binding, as you specify the mapping yourself rather than let your framework handle it. That means if you indicate your framework should map from the fiddler element in XML to the violin attribute in Java code, but you accidentally tell the framework the attribute is on the player class?and not the Player class?you'll get an error. Suddenly, spelling, capitalization, underscores, and single- and double-apostrophes become very important.

Service Data Objects (SDO) is a specification approved by the Java? community through the Java Specification Request (JSR) 235 (see Resources). It is also part of the joint effort from IBM and BEA Systems called CommonJ (see Resources). SDO is an API (application programming interface) that helps simplify and unify data access across different data source types, which is becoming more and more crucial in the IT industry. Monolithic applications are not built as often anymore and information is often stored in various types of sources (database, Web service, Lightweight Directory Access Protocol (LDAP), legacy, and so forth). This complexity requires developers to become skilled in many APIs (Java database connectivity (JDBC), Java APIs for XML-Based Remote Procedure Call (JAX-RPC), or J2EE Connector Architecture (JCA) to name a few). SDO simplifies and complements the Java 2 Platform, Enterprise Edition (J2EE) development mode, providing one unique API to access heterogeneous data sources. The specification also addresses other aspects of data handling that I will explain throughout this article.

Castor oil was once billed as a miracle cure. Even today, there are many Web sites that extol the amazing healing properties of Castor oil. Whether this was the inspiration for the name for Exolab's open source data binding framework or not remains a mystery. In fact, Exolab goes out of their way in the documentation to hide the origin of the name.

For Java developers, there is a new way to implement data persistence. Java Data Objects (JDO) is a Java-based solution to help solve data persistence in java systems. JDO can be defined as:

Java Data Objects (JDO) is a specification developed to enable transparent persistence of Java objects. It is a high-level API that allows applications to store Java objects in a transactional data store by following defined standards. Examples of traditional data stores are databases and files. This API can be used to access data on platforms such as desktops, servers, and embedded systems. JDO implementations can also be made to support cell phone, PDA, and other wireless technologies. In addition, JDO provides a means for treating data stored in a relational database as Java objects. JDO provides a standard means to define transactional semantics associated with these objects.