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

Re: embedded!=standalone

On Wed, 27 Oct 1999, Ann Tecklenburg wrote:
> I should clarify that by embedded, I did not mean "standalone"
> or running in single JVM or lacking networking or multiuser
> capability.
> 
> I meant that it had characteristics
> suitable for shipping and installing
> with a dedicated application in such a
> way that the database would be both transparent to the
> application programmers, the users and
> largely, to the administrators, of the application.
> 
> Embedded, for my purposes, also implies extreme
> robustness, fault-tolerance, and self-healing
> capabilities.
> 
> Oracle and DB/2 are  not  in this category, for instance,
> because of their size, as well as installation and administration
> requirements.
> 
> Solid, the Inprise product, and perhaps
> Adabas fit somewhat in the embedded category.  DBase, FoxPro,
> and Access are used as embedded, but they are pathetic excuses
> for database engines.
> 
> This is why I was interested to do Ozone:
> to have something as tidy as the latter,
> but pure java for Java application
> development ease and fully robust.
perfectly agree. Today I cannot see a reason why or a way to replace DB/2 by
any Java based OODBMS and this is definitly not the idea behind ozone!
However, I see many many application domains where DB/2 does absolutly not
fit. 

I don't know what all the words are to describe the goals of ozone but
robustness, fault-tolerance, pure OO, transaparent,easy programming are at least
in (my) top 10. Other entries for the top 10 ???

> 
> Without Ozone (or something like it) there is
> no potential to do WORA for Java applications
> which use embedded DB's.
> 
> PostgreSQL might be a contender in this
> category via JDBC:  but its too big for
> some types of embedded applications,
> and JDBC still isn't as easy or seamless to
> program as Ozone.  Not all OS's are supported
> and porting it and supporting it on
> a desired platform is *not easy*!
> 
> Also, a note:  single-process JVM's do not and IMHO never will
> "scale" well.  The way to build "large" distributed Java
> applications is to use lots of smaller components
> running in their own JVM,  and communicating and
> doing cooperative processing
> via a network or messaging architecture
> (or bus in the case of clusters).
> 
> This removes the "single point of failure": the central
> server, which potentially can improve fault
> tolernce and distribute network traffic reducing
> "traffic jams".
Yes - this this is the dream. A network of ozone nodes, where objects travel
to the node where they are needed and all the computers of a company form one
big distributed system. I know there are problems and I know we will not see
such a system working in the next few years.... who cares? It's the dream ;)


Falko
-- 
______________________________________________________________________
Falko Braeutigam                         mailto:falko@softwarebuero.de
softwarebuero m&b (SMB)                    http://www.softwarebuero.de