[Objectbridge-developers] [FYI] forwarding a request regarding ObJectBridge

[Thomas M. <tho...@ho...>]

Hi Simon,

I just received your message forwarded from Michael C. Smith. I don't
know if he answered your questions already, but as one of the original
authors of ObJectBridge I'd like to answer you anyway.

> ---------- Forwarded message ----------
> Date: Fri, 5 Jan 2001 10:32:44 +0000
> Subject: ObjectBridge: do you have an overal design-
> objectives doc?
> From: Simon Brooke <si...@we...>
> To: max...@hu...
> 
> At a brief look this might be a project we'd be interested
> in, we might even be able to put some energy into it. Java
> middleware layer is fundamentally what we do. But reading
> the docs on the SourceForge site doesn't give me enough of
> an idea of what you're trying to achieve.
> 

Oops, you got me. Until now there is no technical documentation apart
from the JavaDoc (which is quite detailed). There is only some "getting
started" stuff. 

> Is the idea that you can store arbitrary, stateful objects
> (including links to other arbitrary objects) into the
> database and later retrieve them and relink them?

The OJB PersistenceBroker allows to store and retrieve (and delete)
arbitrary JAVA objects (including references to other objects) into/from
JDBC compliant RDBMS.
You don't need any special coding to make your business objects
persistence capable apart from a public default constructor. Even
private attributes can be mapped onto DB columns.
The mapping between Objects/attributes and database tables/columns is
completely separated from the business code in a metadata repository.
The repository data is generated from an XML file that describes the
Object/Relational mapping.

I don't know what exactly you mean with "relink them". Are you thinking
about retrieving complex object-nets (say an Order-object with all its
OrderPosition-Objects (1-n) )?
Of course OJB is prepared to retrieve references (1-1 or 1-n)
automatically (by using the foreign-key information of the underlying
tables). So there is no need of relinking your objects programatically.
The PersistenceBroker can be configured to perform or not to perform
such a "cascading" for retrieve-, update-/insert- or delete-operations
on a per class basis (done in the XML repository).
The PersistenceBroker can also be configured to support VirtualProxies (
if you load an Order only lightweight Proxy-instances of all
OrderPositions are instanciated. The "real" OrderPositions are only
loaded on demand).

The PersistenceBroker supports EJB BMP EntityBeans. It has a special
method to retrieve PrimaryKey-Enumerations as needed in EJB
Finder-methods. A performance analysis shows that OJB can improve the
performance of J2EE EntityBean based applications by more than 800% (see
attached report). The perormance gain comes mostly from the usage of an
ObjectCache that reduces DB access and maintains Object-identity. (I.e.
if you perform a lookup with the same PK values twice (even accross
threads) you get one and the same instance and not two instances with
equal attibrutes.)

> 
> Is this intended to be (at least to some degree) database
> portable? We work hard on supporting Postgres, Oracle and
> MS SQL Server, and we know a *lot* about the interesting
> quirks of writing genuinely portable JDBC code.

OJB is intended to work with any JDBC 2.0 compliant RDBMS. There is only
one place in the code where I use a JDBC 2.0 feature
(ResultSet::isLast()). This can easily be modified if you have to work
with JDBC 1.0 drivers.
The generated SQL is VERY simple and should not be problematic on any
RDBMS.
If you find any problems with some RDBMS, we will try to solve them.
It's been successfully tested with MS Access, IBM DB2 UDB and InstantDB.

> 
> Should you be able to stop a complex Java application in
> mid-run, dump it to the database, and later read it back
> from the database (possibly on a different node with a
> different JVM) and just continue the computation where
> you left off?

Yes! You can use the OJB PersistenceBroker to "serialize" your objects
to a RDMBS from one VM. 
Later you can "deserialize" those objects from the RDBMS to the same or
different JVM.
Only effort: you have to describe the Object/Relational mapping for the
Objects (Classes) representing your computational state in a XML file!

There are some working samples in the source distribution that show how
applications using the PersistenceBroker look like. See
http://sourceforge.net/projects/objectbridge.
I'm planning to write a more sophisticated example that can
store/retrieve arbitrary XML DOM trees into/from a RDBMS.

The PersistenceBroker part of OJB is quite stable and should be ready
for usage in production level software. 

> 
> If yes to all these, it *does* look interesting...
> 

The described features are things that most Object/Relational Mappings
can do as well. (e.g TOPLink, Sun JavaBlend, CocoBase, etc.)
One thing that is special about OJB: The ODMG compliant ObjectServer.
The Object Database Management Group (www.odmg.org) defined the ODMG
Java API as a standard API for OO databases. Object oriented databases
like POET, Objectivity or Ozone implement this API. You might say: ODMG
is for OODBMS what JDBC is for RDBMS.

OJB will implement a ODMG 3.0 compliant ObjectServer (with transaction
management, multithreading/multiclient support, configurable Object
locking, OQL support etc.).
This ObjectServer does use the PersistenceBroker as its backend.
The result: the application developer does only have to program against
the ODMG API and not to bother with Object/Relational mappings, SQL,
RDBMS specific things etc.
Benefits:
1. Application code does not contain any O/R, or SQL code, but only
business code. 
   No Object/Relational gap in application code.
2. Application is portable accross RDBMS. It's even possible to run OJB
simultaneously
   against different RDBMS <cool-feature>i.e. store your orders in SQL
Server, 
   keep the OrderPositions in Oracle !</cool-feature>  
3. Database schemata can be modified without touching application code. 
   Only the XML Repository has to be modified accordingly.
4. Migration applications from RDBMS to OODBMS is possible with minimum
effort, as we 
   already use the standard OODB API

These part of OJB is still work in progress, but there is already a
working sample in the source distribution which will give you an
impression how programming against this server will look like.

I hope you got an first impression of our project, even without proper
documentation :-)
If you have any further questions don't hesitate to ask me,

best regards,

Thomas