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

Re: [openspaces-dev] Ozone Integration

Hi Chanthy,

I will Cc: this to the ozone list too. It may help people to better understand
these FAQs.

On Wed, 12 Jan 2000, you wrote:
> Hi Falko,
> 
> > > >From what I have seen, Ozone use RMI. As Ozone will be integrated
> > > into the Space and so will talk directly with it, I dont understand
> > > why the connection between the two would use RMI whereas it 's
> > > a local commnunication.
> >
> > The ozoneRMI is an integral part of ozone. There is no way to talk
> "directly"
> > to ozone as there is no way to talk "directly" to an EJB server.
> 
> Ok, It looks a bit clearer. A thing I'd like to know is the main differences
> between
> ozoneRMI and java-RMI.
In fact, there is no difference. When I played with Java RMI to find I way to
use it in ozone I was not able to figure out how to make proxies that have
slightly different behaviour depending on their environment. Because it did not
seem to be a big problem to reimplement the RMI stuff and because I liked the
idea to have RMI that perfectly meets the needs of ozone, we decided to do make
our own ozone RMI.

> 
> > In general an OODBMS has to add some concepts to the underlying
> programming
> > language object model (identity, persistence, transactions,...) without
> adding
> > to much APIs or, even worst, new syntax to the language itself. Since
> calling
> > methods on object is the main paradigm of OO, an ODBMS has to control
> these
> > method invocations. The way we decided to use in ozone to control method
> > invocation is Central Activation + RMI. Without this, ozone is no longer
> an
> > OODBMS but just a clustered object serializer (and not the best I guess).
> 
> I think central activation is the same as the package in
> java.rmi.activation, and if it is
> could you tell me where I could find some documentation on Activation. How
> ozone
> is using Activation ?

java.rmi.activation is not "central" per se. The idea behind ozone's Central
Activation is that entities (to be precise: their identity) never leaves the
database server to avoid replication problems.

Most of todays OODBMSs were designed for C++. In most cases C++ is implemented
in a compiler. So C++ programms have to be linked. After linking there is (in
general) no way to add code to the program. Therefore an C++ OODBMS server is
unable to activate objects just in the server process. This leads to decentral
architectures where data and code form active object only in the client
process. This in turn leads to problems because an entity (it identity) can be
replicated. In ozone we avoid these problems and the code to solve them.

Of course, this leads to other problems but we had to make a running system to
actually find out advantages/disadvantages and when to use what.

> > An OODBMS provides you with an transaction based, virtual umlimited size
> object
> > cloud (not to say "store" because this leads to the database association
> that
> > is not wanted here). The objects in the cloud can be used/programmed just
> as
> > "normal" transient object. This is different from RDBMSs where we have a
> > typical fetch-transformToApplicationDomain-compute-reTransaform-store
> cycle.
> 
> What is the status of the transaction integration in Ozone? And what about
> the ACID
> properties?
ACID transactions are implemented in current ozone but only implicite
transaction demarcation. Right now I'm working to make ODMG transactions
(explicite demarcation) available. ODMG supports READ, WRITE, UPGRADE locks and
SQL92 isolation level 3.

> 
> > I hope this clarifies things a bit. Feel free to get back with more
> questions.
> 
> I'm beggining to understand OODBMS better. The main problem I have to deal
> with
> is my RDBMS thinking and the fact that OODBMS are not something very
> standardized,
> and everyone has is point of view and opinions on the question. Anyway
> thanks for answering
> my questions :-)
The lack of "standards" and the number of different view points is not only a
disadvantage, IMHO ... ;)


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