Enterprise JavaBeans are explored under the following subject areas:
The JavaBeans specification was introduced by Sun in 1996 when Java development was largely client-focussed. JavaBeans are usually reusable visual components that can be used to enhance a client application (e.g. a JavaBean could be an image that behaves in special ways when the user moved the mouse over or clicks on the component).
A non-visual JavaBean can perform business logic and/or database access. Such a JavaBean might be called from a Servlet or a JavaServer Page (JSP) when using a simplified web architecture for a smaller web application.
Calling a JavaBean (e.g. from a Servlet or JSP) involves intra-process
Originally, the preferred approach for larger web-based applications was to develop Enterprise JavaBeans (EJB) which run as a separate layer on an application server. In contrast to JavaBeans, Enterprise JavaBeans (EJB) are always non-visual, run on a server and are accessed remotely (as part of a distributed application). In other words, calling an EJB involves inter-process communication.
With EJB, there is an important division of responsibility between:
The application server (or EJB container) must automate services for transactions, security, persistence/connection pooling, messaging and naming. The EJB uses defined APIs (e.g. to initiate a database transaction), allowing the application server to manage these services.
Isolating the business logic (in the EJB) from these house-keeping
activities provides portability across environments and allows for scalability.
EJB and CORBA components have striking similarities. Both can implement cross-platform components that can be used to implement business logic. In fact, the EJB architecture closely models the CORBA specification (which was established much earlier).
One notable difference is that CORBA provides a language-independent distributed environment while EJB is specifically intended for Java-based components. The two models are quite compatible, however. The CORBA 3.0 specification allows an EJB to be a CORBA component so any CORBA 3.0 compliant server can run EJBs. Conversely, the Java 2 Enterprise Edition Java Naming and Directory Interface (JNDI) API allows access from Java to CORBA services.
While EJB components can be made CORBA-compatible without undue effort, the eCommerce market (including vendors and organization developing eCommerce applications) seem to be investing much more effort on the J2EE model (which cherry-picks from CORBA) than the "pure" CORBA model. Some complain that the full CORBA model is very complex for vendors to support. Another common issue raised is that developing in a pure (non-J2EE) CORBA environment requires that a development team closely ally themselves to a particular CORBA ORB vendor. By contrast, developing applications for a J2EE-compliant application server involves much less vendor-specific code/configuration. In theory, J2EE allows organizations to develop completely vendor-independent applications. In practice, however, J2EE applications are less vendor-dependent than CORBA but it is still very difficult to make every aspect of a complex J2EE application 100% vendor independent.
EJB v1 and EJB v2 proved cumbersome to configure in practice and they did not scale as well in reality as had been hoped. For that reason, much of the market has moved on and used competing persistence frameworks such as Java Data Objects (JDO) and Hibernate.
Although EJB v3 has tried to address the complexity of the configuration, EJBs are no longer viewed as the "main" or even the best way to implement persistence in Java. The general consensus is that, at its best, EJB v3 are nearly as good as some of the competing persistence frameworks. However, due to negative experiences with earlier version of EJBs, there isn't a great deal of enthusiam in the overall marketplace about working with EJBs again.
... back to Java Topics