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

Re: Fw: *URGENT* -- Call for support



On Thu, 25 Jan 2001, Chris Trawick wrote:
> > Hi James,
> > although this is a very interesting post I didn't find the time to respond
> > earlier, sorry. I will just comment one particular sentence of your post.
> see
> > below.
> >
> > [snip]
> > >
> > > > * I'm quite convinced that ODBMS market is having a new birthday owing
> to
> > > > Java and J2EE
> > > > * EJB market is a huge potential for ODBMS
> > >
> > > They are really two different solutions to two different problems.  EJBs
> > > pertain to managing resources in a scalable manner and abstracting
> business
> > > logic from the application.  ODBMSs simply provide a persistent object
> > > store.
> >
> > I disagree. This is not true for Java DBs. ozone in fact _is_ an
> application
> > server! Yes guys, I'm not megalomaniac or something. The code to actually
> store
> > objects does not make 10% of the entire code base!!! Moreover, I never did
> > focus on that part of ozone (therefore it's by comparison still very
> simple;).
> > I always focused on the performance and features of the "object runtime
> > environment" - fast method calls, object cache, transactions, etc. No
> matter
> > what they say, basically EJB provides a transactional, persistent runtime
> > environment for (business) objects. But this is in fact exactly what ozone
> does
> > and what it was made for.
> 
> EJBs provide features such as load balancing and high-availability, ozone
> does not.  Until it does, I see it just like any other database.  In fact, I
> was thinking about putting an EJB layer on top of it to get around that
> limitation.

load balancing and high-availability is not related to the EJB model itself.
Some server provide such features all others claim to do in the future but
those fetures does not come out of the EJB model. They might be implemented
into ozone as well.

load balancing does not make the difference. "runtime environment" or not does.
All C++ OODBMSs that I know just provide the data of the objects. Objects are
activated (put logic and data together) on the client - completely out of the
control of the database server. ozone _does_ control the object. The object run
_inside_ the server.

> 
> 
> > This missunderstanding is a huge problem for ozone. People see that ozone
> is an
> > (OO) "database", well now they expect "database" behaviour. But the
> proxies and
> > the entire ozone programming model does not really fit into this picture.
> > Obviously this makes it hard for newbies to get familiar with ozone.
> 
> If you think about it, this is really just a reimplementation of a portion
> of the EJB standard.  In EJB's case, rmic and idlj take care of proxy
> classes.  However, the two technologies are subtly different in that EJBs
> operate with abstract business logic and data and ozone proxies operate on
> the persistent storage itself.  In fact, the two technologies compliment
> each other nicely.

What do you mean by "ozone proxies operate on the persistent storage itself"?
ozone proxies control the target objects inside the server. the same as EJB.
Am I wrong here?

> 
> 
> > I would really like to hear your opinions on that. How do you picture the
> > future of ozone? What are the advantages/disadvantages compared to EJB and
> > JDO and other solutions? Are there any anyway? Or should we just switch to
> EJB?
> > Or am I completely wrong?...
> 
> A couple are listed above.  I'm not familiar enough with JDO to really say
> one way or another, but so far I don't see any added value beyond EJBs so I
> just see it as yet another redundant standard.  But, I will maintain that
> before ozone can be considered a full app server there must be
> high-availability and load balancing.  However, I hesitate to ask for it
> since I'm QUITE sure that I wouldn't want to be the one to actually code
> it...
> 
> chris


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