J2ee - Where Do You Put The Business Logic?

Hi all;I'm working in the J2EE environment and I have a question that borders me all the time; discussions with co-workers are endless and I want to know how you think about it:Whenever you do a MVC-Based J2ee applicaton in 99% it looks like this:You have a Client UI (Web, FatClient, whatever...), you have some EJB's and a Database; Let's take - oh what surprise - an E-Bank application; now the Business Logic fits into the EJB, so when a client deposits 100 Bucks the EJB reads the actual amount and add's 100 bucks to it and updates the database... Ups! I feel wrong here; What happends in a clustered environment with concurrent requests on the same account? What happends if in 5 years, if EJB's do not exists anymore? I would prefer that the business logic (what happends to an account if 100 bucks are deposited) is defined IN PROCEDURES ON THE DATABASE. ok, it still could be the EJB that invokes the procedure, but now the EJB does not know about the business logic; also, I think creating a JDBC - connection to a database is bad, the technology is slow and the approach to directly access datatables from a java program is dangerous;In our project we use TopLink as O/R mapper;A mapping from our Business Objects in Database tables ends in long long (Toplinkgenerated) statements that block datas for too long.The end of the story: you change your Business objects, now they look like data-tables and not anymore like OO-Design.Also the clustering brings many problems: TopLink caches the objects to gain performance: but in a clustered environment you waste much power to synchronize the nodes-caches; The end of the story: you disable the cache, you loose the perfomance boost;All these problems would not be if the logic would be in exp PL/SQL on the database; no cache synchronization, no OO-broken Business objects....How did you deal with these problems? CheersJDrive

Your concepts are totally wrong. First if you put the logic in DB stored proc, your program design is not OO anymore... You'll need to abandon all the OO pattern stuffs and UML... etc. THAT's a NIGHTMARE!Second, in clustered environment, it's the app server to handle the configuration, not the EJB domain model or Toplink POJOs. Your applications should be totally transparent to the system hardware architecture, so whether it's single app server or clustered app server it'll still run fine. Only app server configurations will be changed. And maybe some crosscutting concern like Toplink caching, need to set for clustered environment too... but that should not change the code. (But for Toplink I'm not quite sure... I use Hibernate btw )I think the typical design should be:MVC Web layer -> Stateless session beans as a session facade -> DAO -> Toplink/hiberate/JDO -> DBRemember, putting the logic inside stored proc is always bad, except that your application is data-centric.

Whenever you do a MVC-Based J2ee applicaton in 99% it looks like this:You have a Client UI (Web, FatClient, whatever...), you have some EJB's and a Database; Let's take - oh what surprise - an E-Bank application; now the Business Logic fits into the EJB, so when a client deposits 100 Bucks the EJB reads the actual amount and add's 100 bucks to it and updates the database...

Ups! I feel wrong here; What happends in a clustered environment with concurrent requests on the same account? What happends if in 5 years, if EJB's do not exists anymore?

I am not sure if you are talking about concurrency or two-phase commit. For concurrency you have transactional level control (transactional attributes +synchronization) which can be managed by the container. If it is two-phase commit, the answer is different. J2EE specification does not talk much about it and it assumes the delegation at each interfacing systems.

I would prefer that the business logic (what happends to an account if 100 bucks are deposited) is defined IN PROCEDURES ON THE DATABASE. ok, it still could be the EJB that invokes the procedure, but now the EJB does not know about the business logic; also, I think creating a JDBC - connection to a database is bad, the technology is slow and the approach to directly access datatables from a java program is dangerous;

Your idea is wrong.
You should not push business login into DB tier. The benefit is scalable system also we are not very successful in maintaining OO at DB tier.

Always OR mapping are the best.

Bala