SITE
  Documentation
  Download
  License
  Performance
  Mailing List

FACADE
  Documentation
  Download
  License
  Mailing List

STORE
  Overview
  Tools
  Download
  License
  Mailing List

JUNIT EXTENSIONS
  Documentation
  Download
  License

AMANDA CD-RW
TAPER

  Overview
  Installation & Usage
  Internals

STORE

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.