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 trafficand
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
