[Objectbridge-developers] Re: Quid pro quo

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

Hi Mike,

maxomenos wrote:

> Hey there. I'm trying to implement ODMG for C, Perl and Python (I know the standard isn't
> defined; I'm pretty much going to be winging it.)

Do you want to implement an Object/Relational framework for those languages? Or do you want to
create new language bindings for existing ODMG compliant databases ?

> I have some Java and ODMG 3.0 experience;

Good! With which ODMG compliant databases did you work? I have some experience with Objectivity
and POET.

>
> I'll trade my work on some parts of your project, in exchange for your help with my project.
>
> My project is called Free ODMG (fodmg)
>
> Do we have a deal?
>

It's always good to share experiences and know-How! From your mail and the information provided
under http://sourceforge.net/projects/fodmg I did not catch what kind of software you want to
build actually:
- a new language binding for existing ODMG compliant DBs ?
- a odmg compliant O/R mapping framework to be used with RDBMS ?
- a Full fledged ODMG- compliant Object-Server with SQL backend ?

Please explain me your vision of this software.

Unfortunately I won't be a big help in most areas of your skill requirements:
no Perl, no Python, little C, no objective C.

But I'm a OO hacker for more then 10 years (Smalltalk, CLOS, C++, Java) and of course I've
started the ObJectBridge project.
here is a short introduction into my ojb-vision:

It's pure Java, no intention to port it to any other language.
It's a modular system containg of separately usebable components:
finished:
- A PersistenceBroker that allows to store, retrieve and delete arbitrary Java-Objects to any
JDBC-compliant RDMBS. This Broker uses an XML based Metadata repository that describes the O/R
mapping. The usage of such a repository allows to keep all information about persistence
separate from the business-objects that need to be persisted - no need of subclassing from a
special baseclass, no need to implement special interfaces. The broker does not implement any
transaction coordination. this has to be done by its clients. the broker does not implement
ODMG.
But: the Broker has some features that are very cool in the area of Java application servers: it
provides ObjectCaching, Connection pooling and support for Finder-methods. These features
improve the performance of certain J2EE-applications by a factor 2 - 5 !
- a very small framework (only a few classes) to build scaleable applications, providing a
Proxy-concept that allow lazy loading, dirty marking and smart updates.
- small demo apps that show how to build applications using broker and framework.
under development:
- an ODMG compliant ObjectServer, with mutltithreading, full transaction management. This server
is a client to the PersistentBroker. I.e. the Server does all the tx management, session
handling, lock handling, etc. But when it needs to materialize Objects or has to commit its
transactions it needs to access the underlying RDBMS and does this by calls to the
PersistenceBroker.
There is already a functional demo application that shows how application against this server
can be build. As of today the server is not quite complete but at least transaction handling is
there!
Feel free to experiment with our code. If you have any questions don't hesitate to ask!

I'm not quite sure about future direction of this project, but I'm thinking of extending it to
implement the upcoming JDO (Java Data Objects) API. This will be a great help in integrating OJB
into J2EE Application servers.
Of course this will be a somewhat different approach than a standalone ObjectServer!

regards,

Thomas