[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OzoneDB core/application (was: Re: Architecture/design questions)

On Fri, 09 Mar 2001, Jörg Prante wrote:
> Am Donnerstag,  8. März 2001 21:38 schrieb Falko Braeutigam:
> 
> > We really need to
> > discuss our plans, goals and ideas regarding ozone. If we don't do this, if
> > we don't finally discuss the relations of ozone to EJB, JDO, ODBMS, XML,
> > whatever-standard, if we don't finally put all of our knowledge and
> > experiences together, then we don't need to care about anything because
> > ozone will just die.
> 
> This will be very short and just dropped out of my mind, so please excuse me 
> if I turn into a totally wrong direction. Surely I could spend more time on 
> this subject and work out some details, but I don't have much time at the 
> moment.

We really really need those dropped-out-of-ones-mind messages. This keeps
discussion going and IMO often produces the most interesting approaches. ;)

> 
> Discussion is always an ongoing process, and I don't think it's a question of 
> "kill or die". OzoneDB will hardly get into a position of being a competitor 
> to EJB-driven database platforms. However there are advantages of OzoneDB. 
> It's a Java persistence engine with transactions and XML support, and this 
> core should be expanded - whether according to standards or not. If standards 
> exist, it's ok, if not, it's fun. The future market will set the de-facto 
> standards. Why shouldn't we try to become a part of the future market?

This _exactly_ is the point why I was talking about "kill or die". We will
definitely never compete with EJB. So we know what we will not do. But
at the same time we need to know what we _will_ do. If there is no clear
vision of the project goals (what is our "market"?), then ozone has no
relevance for real world projects, which for me means it is "dead". 

> The gap between EJB-driven RDBMS (and therefore the whole J2EE platform) and 
> object databases like OzoneDB is big. I think EJB is a mess. Still the 
> concept of beans as being reusable, embeddable, modular, vendor-independant 
> software components is a good one, because it's a door-opener for third 
> parties, for market shares, you know what I mean. But OzoneDB does not have a 
> concept of a bean component technology (please excuse me if I'm wrong). 

Ozone _does_ provide an object (component) model but this of course is
proprietary since ozone is way to small to establish a standard.

> 
> In my eyes, we could make a good target if we define something like "Java 
> Object Beans" (JOBs), together with a companion "Java Object Query Beans" 
> (JOQBs) -  ohh, I'm aware that they must not be called "Java XYZ" because of 
> Sun's copyright. These beans could serve as a common ground or a focus on 
> which OzoneDB developers can work on. JOBs are simply the objects which can 
> be processed by the OzoneDB core engine, and JOQBs are extended JOBs which 
> represent query objects for the engine, for implementing add-ons like W3C 
> XQuery, XQL and so on. 
> 
> In the end we have OzoneDB core vendors, and OzoneDB application vendors, 
> where only the beans need to be developed by the application vendors. With 
> the support of GUI tools for the beans, the latter task should be kept as 
> easy as possible.

This sounds like you are trying to compete with EJB after all.

I perfectly agree that the ozone object model has to be specified and
documented. I'm not sure if we should call ozone objects "beans". This may
cause consusion. Other suggestions?

One central question is the general focus of ozone: objects or XML? I
did not really test EJBs yet, so I'm not sure where we stand with ozone
regarding performance compared to EJB. Anyway, overtime EJB vendors will
optimize their products. So the questions is, does ozone provide a _general_
advantage over EJB?

On the other hand, currently I think we could make ozone a good XML store.
Right now we are evaluating XML databases and it seems that there is no open
source project that follows a future prove concept (what we call future proof
_today_ of course;)

And maybe there are other options.


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com