Enterprise Java Bean (EJB) was the Java EE way for creatng enterprise applications without worrying about middleware requirements such as transaction management, persistence, security, distribution, remoting etc.
The older EJB programming model however had many problems and POJO programming model emerged as an alternative means to solve those problems.
Some of the problems with older EJB model were:
The EJB 2.x specification required developers to use interfaces from the EJB framework package, which created tight coupling with EJB framework package.
You were also required to implement several callback methods, even if you don’t need them, such as ejbCreate, ejbPassivate and ejbActivate.
You had to understand the complex EJP programming model involving concepts such as local interface, remote interface etc.
You need an EJB container to execute EJBs. EJB container is part of application servers such as JBoss, Websphere, Weblogic etc., but is not part of lighter web containers like Apache Tomcat.
Due to the requirement of an EJB container, it is difficult to unit test EJB components such as session and entity beans outside a container.
POJO stands for Plain Old Java Objects, and denotes regular Java classes that are not tied up to any interface.
POJO programming model benefits over EJBs
POJO classes did not have any dependency on any API or a specialized EJB container, like EJBs, and hence was easy to develop, test and deploy.
You were also not required to implement unnecessary callback methods.
POJO programming is more object-oriented, as POJO classes usually encapsulate behavior and properties; older EJB programming model was more procedural.