Enterprise Java Beans is a sophisticated Server-Side component framework that has changed the way the components used to be made till then. EJB is designed to give the abstraction at it’s best. Typically the components used to be developed with the interfaces and the implementation classes of those interfaces. Along with them the skeleton-stub code will be provided according to the specification of the interfaces. If the component needs any additional services like Naming, typically code to access the services has to be written into the bean. This carries a disadvantage. If any of such services are to be used differently, code has to be changed. In this fashion, if a lot many changes need to be made whenever the component is to be used/shipped to different environments to operate under different conditions, code has to be changed.
In generic component frameworks, there is no distinction between the components those represent the data and those which hold the business logic right from the framework level. This causes the pain for the designer to effectively model the components without wasting the resources. Components can only be partitioned at the code level. Another common problem the component makers face is the resource allocation and utilization. For example threads, database connections etc are to be managed most of the time rather than the component runtime taking care of such resources. So naturally the code should be written to take care of such. If the software has to use any particular database or other data source a very similar sort of code has to be written for every bean. This forces the EJB developer to develop the same code multiple times with a few changes. These are some other problems often faced by the component developers.
All the above-mentioned issues demand more resources while developing the components. So there is a requirement for an abstraction that can effectively manage all these complexities, so that the developers can concentrate only on the Business Logic. This is where EJB has it’s purpose.
EJB is built on the top of RMI which provides the basic infrastructure for Distributed Object Oriented computing. EJB has adopted a different way of accessing the services. Enterprise Java Beans wont contain any code to access the services. Instead it will have a text file(deployment descriptor) that tells the EJB runtime (container) the types of services needed for a bean(component) and its details. With this the bean when being used in a different environment with a different set of requirements, the deployment descriptor has to be modified and bean has to be repackaged. It fecilitates no code changes for the bean. This may be similar to the registration of threading details while registering a COM component. But EJB used this concept to a great extent that even the transaction details can be specified this way. It is the EJB container and server which interprets the deployment descriptor and understands how the bean needs the services. At the runtime EJB container(with the help of EJB server) provides the code to offer the services to the bean as per the deployment descriptor. To adopt this policy, EJB has changed the interface and implementation classes design. Unlike in other component architectures, the implementation classes(Bean class) are not derived from the interfaces. Instead the runtime classes will be generated which implement the interfaces and they delegate the method calls to the Bean class. With that the Container can exercise better control over the execution of the process to offer the services to the bean in a transparent manner.
EJB specification has divided the Beans into those which represent the data(Entity beans) and those which model the business logic processing(Session Beans). This distinction helps for cleaner design and better management of the resources including the bean objects. It went further to designate the beans as state full and stateless in the case of Session Beans. This helps in utilizing the resources that are used for tracking the state of the bean.
EJB specification clearly talks about the responsibilities of different systems involved in the EJB usage. According to it, EJB container has to do the resource pooling and maintenance. It is one of the great features that have changed the face of component development. With this feature, components no more worry about the resources like threads, database connections, etc.
EJB offers a different kind of bean “Container Managed Persistent Entity Bean”. For this bean, fields will be declared and they will be mapped to the data in the database using deployment descriptor. As a result, container provides the methods and other code to access/modify the data available in the database. Hence the user can just concentrate on the Business Logic rather than writing the same code for multiple beans.
EJB addressed most of the problems the component software developers/users face. Its abstraction is the strength behind the vast success of EJB. Sun is successful in identifying the loop holes in the other component software frameworks and to fix most of them effectively. This helped the component development take a different path from the conventional way.