I am working on a project where a Java servlet front-end handling
UI interactions will work with a back-end engine (the one that implements
the "business logic") which in turn will use an underlying, transaction-capable
data store, probably an Oracle database.
The engine will abstract the functionality to the point where the client
servlet won't, and must not, know that Oracle is underneath.
As such, it will actually wrap tables into specialized objects that load
information from Oracle using SQL queries, and store information back into Oracle
the same way.
Has anybody grappled with the intricacies of such a three-tier architecture?
The implications for transaction control and cache coherency are interesting and
potentially huge.
In effect, our engine becomes a database in itself, as has been pointed out by an
OODBMS developer that we have spoken with -- and much of the logic we will need to
implement ends up mimicking or reinventing the functionality of generic O/R mappings
such as Castor.
I realize that this sounds vague, but anyone who has bumped into the problem before should recognize
the design issues, hopefully :-)
In researching the subject, we have looked at OODBMS products like Versant, ObjectStore and Ozone.
Of these, Ozone was the most convenient since its transaction model interfered minimally with the
application code, whereas Versant and ObjectStore both require explicit transaction semantics in the
code (resulting in, imho, a clutter of try-except-finally blocks and needless database code).
Unfortunatelly, Ozone does not seem mature, and it is based on RMI, which in our opinion would result
in excessive calls and object references across process boundaries.
We have also looked at Castor, the open-source O/R mapping framework, but Castor does not work well in load-balanced clusters, because Castor instances cannot communicate
with other instances -- this becomes a problem with record locking.
In short, we should *like* to use an O/R mapping or OODBMS, but so far the products evaluated have not matched our expectations.
