I'm a software architect busy mastering the J2EE world.
After alot of study on J2EE architectures, the Java language, EJBs, Servlets, patterns, frameworks, tools, etc.
I have the following question:
Why use EJBs ? Why don't you call stored procedures that does the transaction for you ?
By calling stored procedures, the database handles concurrency. The database can handle transactions or the stored procedure can be wrapped in a java transaction.
It just looks like such a hassle to get a data model in your application server using EJB's or light weight DAOs.
I'm not convinced that performance is so much better to justify the complexity.
Please give your opinion.
You can also ask ... "why we use oo-language and not procedural-language?" ...
I'm glad you asked that question ;-)
If a 2-tier architecture (client -> database) suffices for your requirements, then most definitely, using J2EE or any other app server is over-engineering and a waste.
But think of a system which lives in the following environment:
- Multi-tier architecture.
- Transactions spanning multiple databases and non-database resources.
- OO design.
- Object model is the unit of persistence. i.e., conversion logic from objects to relational tables is well isolated from application code.
Then we automatically start thinking about what the app server can give us, like
- Load balancing and failover.
- Distributed transaction support (2-PC).
- Object caching and locking.
Of course, these are not monopolies of J2EE app servers. The nice thing about J2EE is that it standardizes (most if not all) of these features.