headers
Kovács Gábor | 12 Nov 2007 16:02
Picon

Ozone based framework

Hi All,

I've been using/testing ozone for 4 years now in various test and proof 
of concept projects.
I've tested a few other object oriented databases as well. I'd like to 
share some thoughts with you.

 I think that ozone is unique, because AFAIK no other object oriented 
database server handles the object links as proxy objects. If you are 
developing a server side application this is a huge plus, since usually 
the hardest part of object retrieval is building and caching a complex 
object tree, and the main performance hit usually comes from that. 
Ozone, on the other hand, does the object retrieval in a natural and 
elegant way, reaching only for objects really needed. This method is 
perfect on the server side, and it works (but much slower) on the client 
side as well, if RMI communication is allowed between the server and the 
client.

We encounter problems with this model  when we need to send a complex 
object graph to a fat, GUI like client, process the data and store some 
objects back to the server.
Another problem is that when developing a real world application, 
sometimes allowing RMI communication between the server and the client 
is not an option.

I've done more than just thinking about this :). To solve these 
problems, I've developed a framework, where ozone objects can be 
detached from the server - a selected graph serialized  and sent to the 
client where the data is processed and offline modifications 
subsequently re-attached to the server.  The depth of the graph to be
(Continue reading)

Permalink | Reply | 4 comments |
headers
Gerd Müller | 13 Nov 2007 09:32

Re: Ozone based framework

Hi Kovács,

Although I'm not an active Ozone developer and user anymore it sounds 
really interessting to me. From what I understand you've built a 
client-side ozone cache by simply serializing certain ozone objects. But 
maybe we could see it from a more abstract point of view: what you need 
is a mirror of parts of an ozone database. Maybe it would more elegant 
to use ozone itself to manage such a mirror.

Than your application would always connect to a local instance of ozone 
with all the speed benefits. This client-side instance is attached to a 
server-side ozone database. If your application requests an object which 
is not in your local cache it loads it from the server, i.e. we need a 
transparent ozone proxy that implements a cache.

BTW: You will find CVS read-access here: 
http://sourceforge.net/cvs/?group_id=39695

Best Regards,
Gerd

Kovács Gábor schrieb:
> Hi All,
> 
> I've been using/testing ozone for 4 years now in various test and proof 
> of concept projects.
> I've tested a few other object oriented databases as well. I'd like to 
> share some thoughts with you.
> 
>  I think that ozone is unique, because AFAIK no other object oriented
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Merenda | 13 Nov 2007 11:47

Re: Ozone based framework

Hi Kovács,

the caching mechanism that you describe is typically (or should be) a 
basis functionality of an object database system. You query for certain 
objects, they are delivered to the client (which may be a remote client, 
e.g. a Java Swing GUI) and then - as you go on the navigate through the 
object graph - missing objects are transparently downloaded by the 
client-side caching engine. During commit or before the next query 
resolution the objects must be transparently sent back to the server. 
Often it is not sufficient to load the objects not until they are 
actually needed, thus you must have the ability to pre-load some objects 
as you know that certain associations will be traversed certainly. To 
give a short example: You query for all persons in the database and you 
want to display them in your GUI alongside with their addresses. It 
wouldn't be a good idea to make a remote procedure call for every 
address you navigate to during result iteration. (!)

In practice, odbms systems sometimes do not offer such a functionality. 
But often they do. I know that e.g. Versant does offer a caching 
solution for its objects database. But - for sure - it is not open source.

In fact it is a complex topic and difficult to manage outside the scope 
of a specific database. Please note, that caching must be also 
interconnected with transaction management and - as mentioned above - 
query resolution (which is - as far as I know - not ozone's way of 
thinking). Therefore I think there are two possible solutions:

(1) first, as Gerd Müller wrote, you integrate a caching engine directly 
into ozone. Then you upgrade ozone with a client-side caching engine, 
which would be quite nice, but a specific solution.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kovács Gábor | 18 Nov 2007 22:05
Picon

Re: Ozone based framework

Hi Gerd and Christian,

Thank you for your reply and sorry for the delayed answer, I had a busy 
week.

I didn't want to write a client side caching mechanism for ozone, since 
almost all the other object databases have it, and osone's philosophy of 
database object handling is different. When I started to write this 
extension I had two goals.

1. Provide some sort of basic indexing for ozone objects. These indices 
should be native ozone objects, as indices in most relational databases 
are special relational tables.

2. Somehow send detached, serialized ozone objects to the client side, 
same way we can do it with hibernate. Detach an object, send it to the 
client side for user display. If a client program changes a few objects 
it can send them back for save. But this is not a client cache, since if 
one object changes in the database, the client will not know about it.

These two functions are working now, but need a lot of testing. When 
we're coding database objects, we can model them with simple POJO 
objects with a few convention (they have to extend a database object 
ancestor, and should use naming convention: xxxx_POJO). An ant script 
then generates all the necessary ozone objects from them (xxxx_OZONE). 
The objects can have complex methods as well, not just simple properties 
and variables.

Server side application modules (servlets, EJB objects etc.) can still 
use the native _OZONE objects, having all the advantages of ozone's
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jimmy Stiefel | 24 Nov 2007 09:29
Favicon

Re: Ozone based framework

Hi Gejzir,

As you may have seen,  there has not been much activity in the ozone
project in quite some time.  As far as I know there are not presently
any active developers working on or maintaining the project.  I have CVS
access,  and I continue to use ozone,  though I am looking to migrate
off of it at some point in the future (mainly due to lack of active
development).

  I love the simplicity of ozone and the database's proxy architecture,
but the WizardStore turns out to have some performance limitations that
are increasingly problematic for my data sets.  I wonder if the work
you've done might aid in performance and/or migration from ozone to a
POJO backend such as Hibernate.

I'd love to check out what you've written,  and I'd be glad to help get
it checked in to CVS as well.  I think Gerd (and several others) have
the authority to grant access to CVS.  
http://sourceforge.net/project/memberlist.php?group_id=39695

~Jimmy

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 0 comments |

Gmane