A recent Gartner Group report cited companies overspent $1 billion on EJB last year, when they could have just gotten by with Servlets/JSPs. This motivates our next discussion: once you've decided whether server-side Java is the way to go, you then need to make the all-important decision: are you actually going to use EJB on this project? Or is EJB overkill?
Deploying EJB is a pain, then learning curve. Then why EJB is such a hot topic?
According to some gurus EJB provides transparent scalibility?
What does that mean? What does A ejb can do what Database cant do in transaction management.
According to an article that came in Javaworld EJB has more disadvantages than advantages. Then author saying alternate approach is avoid EJB completely.
Expert One-on-One J2EE Development without EJB - by Rod Johnson, Juergen Hoeller
(now a blatant copy paste - and maybe advertisement as well)
Expert One-on-One J2EE Development without EJB shows Java developers and architects how to build robust J2EE applications without having to use Enterprise JavaBeans (EJB). This practical, code-intensive guide provides best practices for using simpler and more effective methods and tools, inlcuding JavaServer pages, servlets, and lightweight frameworks.
The book begins by examining the limits of EJB technology ? what it does well and not so well. The authors then provide an overview of alternatives ? both agile methods as well as new classes of tools that have evolved over the past few years. They then dive into the details, showing solutions based on the lightweight framework they pioneered on SourceForge ? one of the most innovative open source communities. They show simpler alternatives for basic functions like transaction management, persistence, remoting, and Web tier design; they also show how these alternatives impact testing, performance, and scalability.