We are beginning (or preparing to begin) a project moving our software to a
three-tier architecture. The main reason is that we need to support
multiple databases (the application is currently written in Oracle). We
know we're going to use Java for the middle layer and we're probably going
to use COM. I don't know much about it - I'm just beginning to read up on
the subject. Because we're supporting multiple databases, we do not want
to use a database-specific product like Oracle Application Server.
I have several questions/requests:
- Can anyone recommend some good books or articles on design
considerations for this type of architecture?
- Can anyone recommend some good third-party components for security,
connection, load-balancing, etc?
- Does anyone have any advice, rules-of-thumb, etc. for which application
logic we should move into the application server layer and which we can
leave in the database? I'm thinking that basic "database rules" (as
opposed to business rules) would remain in the database: maintaining
denormalized fields, complex constraints, that sort of thing. Although
I'll have to simplify my multiple-trigger row-level triggers in Oracle to
the statement-level-only-one-per-type triggers in Sybase and SQL-Server.
(I'm not looking forward to that - I love my Oracle triggers.)
- How does executing Java components from triggers compare to triggers
calling database packages/procedures in terms of speed, memory-use, etc?
- How does sending multiple instructions to the database from Java
compare to sending only a single instruction to the database and letting
the db handle all of the remaining processing?
Obviously, we're struggling with the eternal flexibility vs. speed
tradeoff.
Thanks,
Judy Morris
Received on Sat Mar 06 1999 - 13:12:06 CST
