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

Fw: *URGENT* -- Call for support

> 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.


> 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.


> 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