|
.gif){kind=small}
www.developer.com/java/article.php/918111
By Bradley L. Jones November 6, 2001 As developers create more serious applications for the Web, the issues they face get tougher. One issue that is critical for business-level applications is data persistence. Data persistence is the ability to keep data or information around even after a program ends. Because a browser is disconnected from a server, a program on the server can end; however, the user on the browser may still be using data from it. It is critical that the application running in the browser not only appears continuously connected, but that it also operates as if it were connected. Issues with Data PersistenceData persistence has several issues. First, when sustaining data, you want to make sure that multiple users can still access the data. Just because I'm viewing data on my browser doesn't mean that others can't be viewing or modifying it as well. Another issue that must be addressed regarding data persistence is that of transactional access. For real-world applications, you must deal with data in a transactional method. It is transactions that allow multiple people to work on the same data or program without worrying about "stomping" on each other. For example, you and I both grab a record containing "book" information. We grab it at the same time. You make a change to the price from $19.99 to $24.99 and save it. I make a change from the price of $19.99 to $17.99 and save my change after yours was changed. What should happen? If my change is saved, then your change was totally wiped ignored. Transactional processing puts into place a structure that would prevent my change from happening without first showing that the original price of $19.99 had been changed by someone else (you). Transactional processing is also important when multiple changes must occur. For example, if I buy a book, the first step is to change inventory to show that the book is being purchased. This prevents someone else from buying it. A second step would be to get a payment from me. If my payment fails, you don't want to simply quit. Rather, you need to make sure the book ends up back in inventory. Transactional processing will take care of this for you. A third issue with persistence deals with portability and ease of use. When you start coding solutions for persistence, you often limit a program's portability to specific environments. Additionally, the efficiencies and ease of use of the program begin to become complicated. How is Data Persistence Currently Achieved?Currently data is sustained in a number of ways. Most of the time these solutions are proprietary and thus not portable beyond the current application without added work. Such proprietary methods may include direct file I/O where the program contains code that writes and reads the information as needed. It also would contain code to deal with the transactional aspects of the application. This may involve serialization, the use of JDBC, or even JavaBeans in a java solution. Many of these solutions have issues. For example, serialization does not allow for partial reads or writes, nor does it provide transactional support. JDBC is generally not portable due to the various flavors of SQL. Using EJB is not a full solution because there are limited objects, plus several platforms, such as embedded and two-tier are not supported. Java Data Objects for PersistenceFor 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 are a pure Java API. Unlike SQL, this is not a language tied to a database. JDO provides a number of features including:
There are a number of benefits for developers using JDO. Transparent persistence gives the developer the ability to deal with just Java objects without worrying about dealing with non-Java database code. Underlying code within JDO takes care of working with the database and such. The developer doesn't need to learn a query language like SQL, rather they can focus on the Java language. For example, doing a database Boolean query against the data in the database is a simple Java Boolean query. There is no fancy syntax. Because JDO is a Java API, it is portable. Most database query languages are not portable. Although SQL was aimed at being portable, the major databases have spun off their own flavors. Microsoft SQL Server uses Transact-SQL. Oracle uses PL-SQL. JDO is actually a specification request (JSR-012). As a specification, it is open for vendors to actually implement JDO routines. For persistence, JDO deals with interfaces rather than with classes. A JDO vendor will implement these interfaces. JDO will be implemented to work with J2ME, CDC, and other wireless platforms. Additionally, it will work with J2SE, J2EE, and EJB. Developers will be able to focus on coding to a simple API without worrying about the underlying database. JDO will provide developers Transparent Persistence. Simply put, this means there will be a simple API that can be used. It will be a pure java implementation so it will be portable even at the binary level. There will be transparent mapping to the data store that includes query support as well as transactional support. Even partial reads and updates will be supported. Caching will not be an issue because there will be automatic cache management. In Summary...In summary, JDO provides a "programmer's way" of accessing databases from a Java application. It takes care of data persistence for the programmer, it allows for transactional processing, and it provides an interface so the underlying data source can be changed without re-writing your applications. # # # |
.gif){kind=small}
.gif){kind=small}