Primary goal of Enterprise Java Beans (EJBs) were to allow developers to write business side logic in enterprise applications without worrying about middleware requirements such as transaction management, persistence operations, security, distribution, remoting etc. The older EJB programming model had many problems and POJO programming model was an alternative means to solve those problems.
Primary goal of Enterprise Java Beans (EJBs) were to allow developers to write business side logic in enterprise applications without worrying about middleware requirements such as transaction management, persistence operations, security, distribution, remoting etc., as these could be easily added into the system as needed.
The older EJB programming model had many problems, especially design problems and many of these problems with the older EJB programming model actually triggered the birth of POJO movement. Latest EJB versions such as 3.x has improved a lot following the POJO programming model, but understanding some of the problems with the original EJB programming model is always good for understanding the POJO programming model.
Some of the problems with the older EJB Model
The EJB 2.x specification required developers to use interfaces from the EJB framework package, which created a tight coupling of developer code 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.
Public methods of business object implementation classes had to throw the RemoteException, which created further dependency on EJB and remoting technologies.
Due to above dependencies and requirements, the minimum code that needs to be written to develop an EJB application was always more than needed.
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. POJO based frameworks such as Spring, Hibernate etc. can be deployed even in 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 and as a work around in-container test frameworks such as Cactus were used; whereas POJOs could be unit tested as standalone classes as they are not dependent on any container.
Use of JNDI contexts from Java EE environment also created dependency on the Java EE environment, which lead to issues in unit testing.
Writing lot of XML-based deployment descriptor files for older EJB model was more time consuming and error prone.
Entity beans had many issues such as inheritance support was limited, and recursive calls within entity beans were not supported. Because of many such issues, they are deprecated in Java EE 6 in favor of JPA.
POJO stands for Plain Old Java Objects, and denotes regular Java classes that are not tied up to any interface.
POJO programming model benefits
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.
Searches whole web. Use the search in the right sidebar to search only within javajee.com!!!