Oracle 9i and RAC

Question

The client will be using Oracle9i as their database (which has Real Application Clustering), and also Oracle9iAS as their application servers. Their architecture is 3-tier, and development will be done on the J2EE platform. They are using Oracle's JDeveloper for development.
One of the potential risks that we found is that the client is planning to place most of the business logic (they define it roughly as "anything that requires data manipulation on the database") on the database servers. These will be programmed in PL/SQL. This was advised by Oracle consultants, saying that PL/SQL on the database server will perform better than Java entity beans deployed on the application server. Only very little business logic will be programmed as Java beans on the application servers. The client feels that logically this is still 3-tier and Oracle's Real Application Clustering will ensure scalability of the database servers.
Looking at this approach, we feel this is not very much 3-tier anymore, because the business logic is tightly coupled with the database. We foresee that there will be issues with independence of business logic and database access layers, flexibility, portability, modularity, maintainability and scalability.
What we would like to find out is:
- We'd like to hear your opinions on this approach of placing business logic on the database and using PL/SQL to code it.
- What are the risks of using this approach?
- What are the alternatives (entity beans? session beans? Java Data Objects?)
- How proven is Oracle Real Application Clustering and how much will it help client in this situation?

Answer 1

The client will be using Oracle9i as their database (which has Real Application Clustering), and also Oracle9iAS as their application servers. Their architecture is 3-tier, and development will be done on the J2EE platform. They are using Oracle's JDeveloper for development.
One of the potential risks that we found is that the client is planning to place most of the business logic (they define it roughly as "anything that requires data manipulation on the database") on the database servers. These will be programmed in PL/SQL. This was advised by Oracle consultants, saying that PL/SQL on the database server will perform better than Java entity beans deployed on the application server. Only very little business logic will be programmed as Java beans on the application servers. The client feels that logically this is still 3-tier and Oracle's Real Application Clustering will ensure scalability of the database servers.
Looking at this approach, we feel this is not very much 3-tier anymore, because the business logic is tightly coupled with the database. We foresee that there will be issues with independence of business logic and database access layers, flexibility, portability, modularity, maintainability and scalability.
What we would like to find out is:
- We'd like to hear your opinions on this approach of placing business logic on the database and using PL/SQL to code it.
- What are the risks of using this approach?
- What are the alternatives (entity beans? session beans? Java Data Objects?)
- How proven is Oracle Real Application Clustering and how much will it help client in this situation? Oracle consultants are paid to promote the product so the recommendation is not surprising.
if the app needs to be a 3-tier then it makes sense to put the business logic in app server. the advantage here is
you can clone the app server to scale for users/sessions (plus the scalability from the oracle RAC) that is a double whammy.
eventhough pl/sql is advantageous in terms of performance, it constrains you to oracle.
if the business logic is database independent. so you can switch to any other database.
the other alternative is writing the java code and publishing it as pl/sql procedures in the database. this is the middle path
approach, if you want to port the app to another database vendor, you can do with minimal effort (compared to rewriting the pl/sql).
the predomoinant factor in a web app is how are you going to manage persistance of a user session.
container managed persistence or database managed persistence, the choice of the level of sophistication at the web app level determines which way you
want to go. to give persistence feature you might have to put the logic in beans and put the beans in app server.
why do they need RAC for scalability?? they could create multiple clones of app server and have them work load managed , i guess that would be far cheaper than having to spend money on RAC hardware/software.
if 99.99% availibility is the concern then RAC makes business sense...
a few thoughts, which i hope you will find useful.
Mukundan.