Re: [Objectbridge-jdo-dev] Non-JDBC data sources

[David Z. <dv...@at...>]

After while, I have returned to my initial problem: Non-JDBC data sources
There is a "model" of persistency of application I'm going to design
("App").
As you can see, there is something called "ODMG agency" (operative
appellation of "little wrappers that route user request to different ODMG
implementations" to avoid possible naming conflicts).
There are also (schematically drawn representatives of) persistencyBrokers
I'm going to provide in the near future.
What are the problems:
1) Is OJB drawn roughly correctly?
2) I think, ODMG agency wouldn't be so easy in case of distributed
transactions. Please let know, there will be couple of objects persisted to
multifarious datastores (both through OJB and other ODMG datastore) at the
same time.
What about another solution - provide ODMG persistencyBroker for OJB and
abandon "ODMG agency"? Performance of Application will not be critical.

Thanks
Dvid


---------------------------
> I know, that OJB's focus sharpness (faq: It's concerned with
> O/R mapping and
> nothing else.) is design/manage advantage, but I work on
> project, where it's
> crucial to integrate disparate data sources (RDBMS, ODBMS,
> XML based DBMS,
> flat-files, vendor specific formats..). I decided not to use closed,
> non-free solutions at all, so OJB (open-source, clearly designed,
> scalable...), seems to be suitable as a persistency-heart.
> Could you advise how to get on with OJB?


> 1) use OJB as a single persistency adaptor, manage several ODMG
> implementations, make some fascade to hide it, e.g. solve distributed
> transactions...?

If there are existing ODMG Java bindings to you other datasources this will
be vers easy.
Just write litte wrappers that route user request to different ODMG
implementations.

If there is no ODMG API for a given persistent store, you can implement a
dedicated PersistenceBroker for this special persistent store.
This way you can use the OJB ODMG (or JDO if you prefer) implementation to
access arbitrary persistent stores.

> 2) extent OJB (add persistency adpators to OJB) - if
> publically useful,
> release them under LGPL as modular OJB's parts/add-ons?

Yes, that's what I'm recommending. have a look at our persistence kernel
interface ojb.broker.PersistenceBroker.
It contains no specifics for RDBMS. It is a generic abstractiion of an
object store.
There could be implementations for OODBMS, RDBMS, XML databases, file system
or Directory Services !

You only have to provide a persistent store specific PersistenceBroker
Implementation.
Than you can use the OJB ODMG or JDO layer to work against those specific
brokers.

regarding OJB scope:
As OJB will be one of the foundation projects of the new db.apache.org site,
our scope is not longer limited as mentioned in the faq.
OJB will be a generic object persistence integration platform!

Thus having new PersistenceBroker implementations is very interesting for
us!
(especially XML, OODBMS, LDAP, flat-file)