pojo data persistence

pojo data persistence
pojo pojo pojo
pojo data persistence  
  CocoBase PURE POJO
  introduction
 


features of new v5.0
> pure pojo - ejb3
> magic mapper
> high performance
> o/r mapping
> querying solutions
> cocobase is free
> eclipse, spring
> technical spec's
>
whitepapers


  services
  customers
  tech support
  pricing
  purchase
  evaluate*

whitepapers  
 



DYNAMIC POJO DATA PERSISTENCE™
CocoBase® Enterprise O/R

The Current and Future Direction of The Java Platform Is Available Now!

The CocoBase® tool offers Dynamic Transparent Persistence (i.e. transparent to the object), both locally and distributed with an integrated Query Manager for use with standard plain old Java Objects that is now being referred to as "Dynamic POJO Data Persistence(tm)."

CocoBase® Enterprise O/R Whitepaper

 
   
 

INTRODUCTION

Sun Microsystems has recently proposed a new data persistence model for Java, POJO (Plain Old Java Objects) Data Persistence that will combine the strengths of two Java specifications. The specifications are EJB (Enterprise JavaBeans) 3.0, JSR (Java Specification Request) 220; and JDO (Java Data Objects) 2.0, JSR-243. The announcement comes from Linda DeMichiel, Spec Lead for EJB 3 and Craig Russell Sped Lead for JDO, both from Sun Microsystems, who called the effort a "reconciliation," and asked for support from the Java community which Thought Inc. is committed to offering.

CocoBase® already offers Dynamic POJO Data Persistence™. Developers have been using this part of CocoBase® for years. This means that developers can choose to use this method for persisting data in their applications with the support and assurance that the industry is clearly moving in this direction. As the specification materializes, Thought Inc. will simply integrate any specific APIs and details into the existing CocoBase® POJO framework.

CocoBase® is an easy to use enterprise-level mapping tool and framework that provides data persistence implementations for EJB, POJO, JDO, Dynamic Transparent Persistence™, Stand-Alone (no app-server), Application, Servlet, etc. CocoBase® is the only mature Java Object to Relational Mapping tool available encompassing almost a decade of Java only product development. The product is designed for ease of use making the development of fairly complex data mappings quite simple. CocoBase® cuts the cost of database access programming by up to 85% for a significant cost and time savings. Numerous Fortune 1,000 and Government Customers have deployed applications with CocoBase with millions of users while managing key data, proving that CocoBase® is the IT choice for Enterprise Data Persistence development.

THOUGHT Inc. strongly supports Object to Relational Mapping standards and related specifications. The CocoBase® tool currently supports all of the J2EE and J2SE platform with additional support for JDO 2.0 being completed soon. CocoBase® is the only tool that gives developers such a wide array of choices with which to implement persistence that best meets their project and architectural needs. Now, with the direction of the Java platform and Object Relational Mapping moving to combine JDO with EJB for what is called POJO Data Persistence, we find that CocoBase® already delivers the solution that meets the goal of this new specification today. CocoBase® was the first Java O/R Mapping tool available and has continued to deliver a powerful and elegant architecture for persisting data since its official release in 1997.

WHAT IS DYNAMIC POJO DATA PERSISTENCE™?

Definition: A unified persistence and query manager for local J2SE and distributed J2EE environments which is completely transparent to the object and does not require the modification of the bytecode of the object.

POJO Data Persistence is a transparent local and distributed method for persisting data into plain or ordinary Java Objects. Enterprise JavaBeans is a distributed method for persisting data that has proven to have some key drawbacks that has over time limited the use quite dramatically. Java Data Objects (JDO) is a local (non-distributed) method for persisting data but JDO has so far required special instrumentation of Java class files. Combining the best points of these two standards into a local and distributed method that is transparent to the Java object is the apparent goal of the new POJO spec.

CocoBase® already has an existing Dynamic POJO Data Persistence™ over both Local and Distributed environments with simple ordinary Java objects. CocoBase®'s Dynamic POJO Data Persistence™ is fully portable, extensible, and scalable. It is vendor neutral and 100% portable across J2EE/J2SE compliant systems. There is no need for the developer to write database specific code in order to persist objects. Dynamic POJO Data Persistence™ makes it possible to track and persist any object type, including POJO's, EJB Entity Beans, CORBA objects, RMI objects, and Java classes - and without the requirements of a database specific query language in application code, or object model intrusion.

The CocoBase® Dynamic POJO Data Persistence™ allows the developer to persist relational data with a simple, non-invasive, widely distributable object. These capabilities operate as an extensible persistence layer - invisible to the object. Without any byte code or object model intrusion, CocoBase®'s Dynamic POJO Data Persistence™ runs on local, as well as distributed environments, and is designed to minimize development and maintenance costs without sacrificing performance. It is built for both J2SE and J2EE performance. Mappings of Objects are versatile enough to be reusable, and to persist and manage objects simultaneously across a wide number of databases. CocoBase® employs an independent persistent monitor - invisible to the application object - which persists, retrieves, and reconciles copies of objects to ensure proper network programming and serialization with its persistence facilities. The Dynamic POJO Data Persistence™ can also manipulate multiple copies of the same object within the same JVM, so as to enable threaded servers to have a unique context and persist on parallel transactions.

CocoBase®'s stable object components are designed to allow developers to edit Object to Relational Maps without the need to change, re-compile, or re-process the object model. CocoBase®'s Dynamic POJO Data Persistent object is unaware of its own persistability: that is, the object is unaware of the mapping or data structure used to persist it, and is capable of being loaded or persisted to an arbitrary number of database tables. CocoBase® works through its runtime facility to operate without awareness of the object. Lack of binding to a specific database design, enables objects to be more reusable: for example, CocoBase® allows the developer to use the same map as an EJB in a J2EE application, or a Java Class in a J2SE application. CocoBase also allows the same object to be used against Oracle, DB2, SQL Server or other relational database systems, even when they provide different table structures or Query Language implementations.


IMPLEMENTATION OF DYNAMIC POJO DATA PERSISTENCE™

Maps and links can be created using a UML/XMI Modeling tool, or from reverse engineered object models, database schemas, or by hand. CocoBase® runtime classes can then be used to provide transparent persistence to a Java Object Model which corresponds to the created maps and links. Again, CocoBase® accomplishes transparent persistence with Java Object Models without using byte code manipulation, proprietary interfaces, or class hierarchy intrusion. As a result, no special classes or interfaces are required in the Java Object Model in order to achieve persistence with CocoBase® - the only default requirement being that the Java Object Model must have a default constructor with no arguments (which is also standard Java coding practice - but can be handled with a custom Instance Factory by the developer). There are three basic runtime components involved in the dynamic transparent persistence of objects:

The CocoBase® Runtime O/R mapping class. This class wrappers the JDBC
driver, issues queries, and makes the actual persistence calls. For example,
thought.CocoBase®.CocoPowder or thought.CocoBase®.CocoPowderPlugin20
(for JDBC 2.0 connections).

thought.CocoBase®.Transaction object.
This object tracks changes of instances, and acts as a change 'buffer'. If a Transaction object is used, it will only call a CocoBase® runtime driver (an O/R mapping runtime class) when txn.commit() is called - thus reducing database traffic
and overhead.

thought.CocoBase®.navapi.Navigator object.
This object tracks and detects changes in relationships based on link definitions.

The Navigator class can operate either in conjunction with a Transaction
object, or standalone. While complex object graphs can be transparently managed directly by the Navigator object - and without using the Transaction object - use of the Transaction object is generally preferred because of its buffering and update optimizations, which only persist those attributes which have changed.

All of these runtime facilities can be used together as a single API with the easy to use CocoBase Transparent Persistence API called the CBFacade. This open API wrappers the underlying implementations and provides an easier method of managing POJO persistence.

 

DEVELOPING APPLICATIONS WITH COCOBASE'S® DYNAMIC POJO DATA PERSISTENCE™

Having properly created the links and maps, corresponding Java classes can be generated by choosing File > Generate Java Code from the CocoBase® menu bar. The code generation target, Transparent Persistence Pure Standard Java Object, will generate a pure Java class with no propriety or CocoBase® interfaces. Once these generated classes have been compiled, CocoBase® runtime classes may be used to persist instances of them.

First, a CocoBase® connection should be opened. The following code illustrates how to accomplish this.

// Create a LOCAL CBFacade for local persistence
CBFacade cbf = CBFacade.create("thought.CocoBase.CBFacadeLocal");
Properties props = new Properties();
props.put("cocosource.name","thought.CocoBase.CocoPowderPlugin20");
props.put("cocosource.jdbcdriver", "oracle.jdbc.driver.OracleDriver");
props.put("cocosource.url", "jdbc:oracle:thin:@localhost:1521:ORCL");
props.put("cocosource.user", "SCOTT");
props.put("cocosource.password", "TIGER");
// Specify the Navigation Model for relationships
props.setProperty("cocosource.navmodel","Scott_Model");
props.setProperty("cocosource.factory","thought.CocoBase.InheritanceFactory");
// Specify the Inheritance model for polymorphism
props.setProperty("cbfactory.inheritancemodel","Scott_ModelInheritance");
cbf.connect(props);
cbf.setDebugLevel( ( (new Integer(args[5]) ).intValue() ) );
...

Next, a transaction scope is created to manage any objects which are retrieved. Notice in the following code, how the transaction object is configured through parameters and property settings.

cbf.beginTransaction();

In the following code example, the pure Java Object Model class is used in a 'query by example'. Compatibility with CocoBase® is implemented invisibly through high performance Java reflection - that is, instead of requiring any special interfaces in the Java class itself. The top-level node should be selected in order to access this area of the code. CocoBase also supports a fully compatible EJBQL query language syntax that can also be used for issuing POJO queries.

// Setup our object to query
Department dept = new Department();
department.setName("SALES");
// This will read & bind all 'Department' objects to the transaction.
Vector deptVector = cbf.loadAll(dept),"Department");

With CocoBase®'s Dynamic Transparent Persistence, it is possible to step through each of the objects and their links if each link is defined as either a cascade load of true or lazy. Internally each link is automatically loaded on initial query, or when accessed - depending on the setting.

for(int i=0; i< deptVector.size(); i++) {
Department d = (Department)deptVector.elementAt(i);
// Because the cascadeLoad flag is set to true in the
// direction Department->Employees, the employees link
// will load automatically

Vector emps = d.getEmployees();
for (int j=0; j<emps.size(); j++) {
// raise salaries by 20%
emp.setSalary(emp.getSalary()*1.2);
...
}
...

Once changes are made to an object graph those changes can be synchronized using the updateAllLinks method such as:
cbf.save(d,"Department");

Committing the buffered object changes is undertaken with the following method call:
cbf.commit();

The preceding code introductions are fairly small, and can be run entirely on the server side using Entity or Session beans in J2EE environments without byte code or object model intrusion. Regarding locally executed non-J2EE applications, the application intrusion is very small - with only the 'load', 'synchronize', and 'persist' operations requiring a single method call for each root node. The CBFacade object supports one-to-one, one-to-many, and many-to-many link definitions with cycle detection. It can also detect these locally or by reconciling serialized or copied objects, again without byte code or object model intrusion. This technology is true transparent persistence, architected and designed for the
JVM[tm]-oriented Java language.


CONCLUSION

In closing, Sun's push to make the standard for persisting data with POJO's is a win-win with CocoBase®. The Dynamic POJO Data Persistence implementation in CocoBase® already exists and has been used by customers for years. It has proven to be a stable and superior system for persisting data both locally and distributed that is transparent to the Object. Of course, as a specification is clearly outlined and detailed by Sun, CocoBase® will modify it's implementation to conform while continuing to maintain existing APIs in parallel. This is expected to fairly simple to do because the CocoBase® architecture is so flexible.

For developers who have any level of complexity in their application hand-coding SQL, JDBC, etc. is just too time-consuming and a comprehensive data persistence tool like CocoBase® is a good choice. CocoBase® greatly simplifies the development of data persistence, a usually complex task. In fact, CocoBase® cuts the cost of database access development by up to 85% offering a significant time and cost savings.

We find that customers choose CocoBase® for it's reliability and extensive choices for how to map and manage data in their applications. Whether they use POJO's, EJB's, or another persistence implementation that best fits their technical needs it is the superior and mature persistence architecture (i.e. runtime) based on over a decade of development that keeps their applications running successfully.




LEGAL NOTICES

This document is copyrighted and owned solely by THOUGHT Inc.® 2004. CocoBase® and THOUGHT Inc.® are registered trademarks of THOUGHT Inc.®. Dynamic POJO Data Persistence™, Dynamic O/R Mapping™, Dynamic Object to Relational Mapping™, Dynamic Universal Querying™ and Dynamic Transparent Persistence™ are pending trademarks of THOUGHT Inc.®. CocoBase® technology is based on US patent #5857197 as well as additional pending patents directed to object navigation, object modeling, querying and caching. All other trademarks are property of their respective company. This publication is provided "as is" without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement, to also include any and all technical inaccuracies or typographical errors.

 
 

 

 

 




Related Info

CocoBase® Whitepaper
How to Meet ROI Requirements for Persisting Data in Enterprise Applications with CocoBase®.

CocoBase® Whitepaper
Dynamic Transparent Persistence™ for the J2EE and J2SE Platforms.

CocoBase® Whitepaper
Why Dynamic Repository Based Mapping is the Key to Success for Database Access with CMP / BMP Entity Beans.

CocoBase® Whitepaper
Mapping Concepts - Details on how CocoBase Maps Data.