Chapter 10. EJB 3 and the Java Persistence API
Many developers were introduced to the promise of Enterprise JavaBeans (EJBs) eight years ago during the dotcom era where mad speculation about what was necessary to be successful in business with new technologies relied more on hype than reality for normal business operations. On effort after effort people were convinced that large solutions implemented with EJBs would solve all problems when most were easily handled by simple web applications accompanied by other services (security, caching, and so forth).
More often than not, complexities of the EJB architecture necessitated the development of bloated models too cumbersome to deploy and maintain on software deployments. XML deployment descriptor requirements for individual EJBs and extraneous callback method generation, along with difficult EJB Query Language constructs, all contributed to an unpleasant development experience that forced developers to seek alternative technologies for their enterprise implementations. Also, EJBs promoted non-object-oriented-like code generation that dictated the use of parameter passing constructs to marshal data collections across the network.
But the biggest reason why EJBs were a problem in the past was how entity beans gave rise to latency issues on the systems they ran on when those systems performed lots of transactions. In earlier releases, entity beans were individual resources, shared by both session and thread processes, that were always ...