STORE
Author: Peter Conrad, conrad@tivano.de
$Id: introduction.html,v 1.1 2002/09/16 15:47:58 conrad Exp $
STORE's Tivano's Object-Relational Engine.
It also is Not Java 2 Enterprise Edition
(the original name was dropped for obvious reasons).
Instead it is a simple package that implements some
of the nice parts of J2EE while trying to avoid the overhead that comes
with a full J2EE implementation.
In the past we have completed a couple of projects where J2EE was used quite
heavily, e. g. with Bea's Weblogic Commerce
Server. We have made the experience that in those projects the cost of
employing J2EE often outweighed the benefits. Cost, in particular, means
- Tutoring time for the developers
- Due to the fast pace at which J2EE has been evolving during the last few
years, our developers have spent a lot of time on keeping their knowledge
up to date. Therefore in this case tutoring time is not a one-time
investment but a continuous cost factor.
- Development time
- If you try to do things in the right way (in terms of J2EE), things are
more complicated. E. g. you have to get a JNDI context which you use to
look up the home interface for a bean, which you use to get a bean
instance, which you can finally use to invoke the method you were looking
for. So in some cases a simple method call can explode into four, not
counting any required try/catch clauses.
- Administrative overhead
- This may not be a big factor. A J2EE compliant application server usually
has an administration interface that makes some tasks easier (like
defining data sources etc.). Sometimes things have to be done by hand,
though, like setting up message queues for message driven beans. Sometimes
you want to be able to preserve configuration information in a simple form
but the only way to access it is some GUI.
- Resource usage
- CPU utilization can be significantly higher when using J2EE, especially
when beans are accessed via RMI. Also, database lookups can be
significantly slower (which may be an implementation detail, of course -
but sometimes you can't do anything about it). That means you have to
put more money into faster hardware to achieve the same application speed
compared to an implementation without J2EE. (One might speculate about
SUN's motivation for introducing J2EE here... ;-)
Of course, there are benefits, too:
- Entity beans provide a very convenient way to abstract the functionality
of a database. This is especially true for entity beans with container
managed persistence.
- J2EE-based applications scale - in theory. I haven't seen an application
that actually uses beans deployed on multiple machines. In theory you
can load-balance a J2EE application quite nicely by distributing it among
several machines. In practice, for the vast majority of web applications
at least, this is simply not necessary.
So, the goal of this project is to create a simple infrastructure that
provides some of the benefits mentioned above.
[ t]ivano software gmbh
www.tivano.de
Sun, Java, JDBC, JNDI and J2EE are registered trademarks of SUN Microsystems, Inc.
BEA and BEA Weblogic are registered trademarks of BEA Systems, Inc. All other
products and services are trademarks of their respective owners.
|  |
