Why EJB (Enterprise Java Beans)?

Enterprise Java Beans or EJB for short is the server-side component architecture for the Java 2 Platform, Enterprise Edition (J2EE) platform. EJB technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology.

Sun Microsystems in the beginning put forward Java Remote Method Invocation (RMI) API as a distributed object computing technology. RMI specifies how to write objects so that they can talk to each other no matter where on the network they are found. At its core, however, RMI is nothing more than an API to which our distributed objects must conform. RMI says nothing about about other characteristics normally required of an enterprise-class distributed environment. For example, it does not say anything about how a client might perform a search for RMI objects matching some criteria. It also does not specify how those distributed objects work together to construct a single transaction. Thus there is a realization for a need of a distributed component model.

A component model is a standard that defines how components are written so that systems can be built from components by different developers with little or no customization. There is already a component model called as JavaBeans in Java. It is a component model that defines how we write user interface components so that they may be plugged into third-party applications. The magic thing about JavaBeans is that there is very little API behind the specification; we neither implement nor extend any special classes and we need not call any special methods.

Enterprise JavaBeans is a more complex extension of this concept. While there are API elements behind Enterprise JavaBeans, it is more than an API. It is a standard way of writing distributed components so that the written components can be used with the components we write in someone else's system. RMI does not support this ability for several reasons listed below. Here comes the features that are not available with RMI.

1. Security - RMI does not worry about security. RMI alone basically leaves our system wide open. Any one who has access to our RMI interfaces can forge access to the underlying objects. If we do not impose complex security restrictions to authenticate clients and verify access by writing extra code, we will have no security at all. Thus our components are therefore unlikely to interoperate with other's components unless we agree to some sort of security model.

2. Searching - RMI provides the ability to do a lookup only for a specific, registry-bound object. It specifies nothing about how we find unbound objects or perform searches for a group of objects meeting certain requirements. For example, writing a banking application, we might want to support the ability to find all accounts with negative balances. In order to do this in an RMI environment, we would have to write our own search methods in bound objects. Our custom approach to handling searches will not work with someone's else custom approach to searching without forcing clients to deal with both search models.

3. Transactions - The most important feature for a distributed component model is transactions. RMI does not support transactions. If we develop an RMI-based application, we need to address how we will support transactions. That is, we need to keep track of when a client begins a transaction, what RMI objects that client changes, and commit and roll back those changes when the client is done. This is further compounded by the fact that most distributed object systems support more than one client at a time. Different transaction models are much more incompatible than different searching or security models. While client coders can get around differences in search and security models by being aware of those differences, transaction models can almost never be made to work together.

4. Persistence - RMI does not care about how RMI objects persist across time. There is a persistence utility that supports saving RMI objects to a database using JDBC. But it is very difficult to integrate with RMI objects designed to use some other persistence model because the other persistence model may have different persistence requirements.

Enterprise JavaBeans addresses all of these points so that we can literally pick and choose the best designed business components from different vendors and make them work and play well with one another in the same environment. EJB is now the standard component model for capturing distributed business components. It hides from us the details we might have to worry about ourself if we were writing an RMI application.