Is Ejb really significant in enterprise applications?

Ejb was introduced to Java technology to attain some features inherent in enterprise applications. Those features include instance pooling, inbuilt security, declarative transactions, container managed persistence, relationship of business objects and caching etc. Now that many people have built their applications using Ejb, let us go back and analyze if Ejb as a technology is really significant in developing enterprise applications. We are going to analyze both pros and cons of Ejb based on experience of people who have used Ejb.

Not Always

Some experts strongly believe that Ejb is not really that significant technology in developing enterprise applications over the top of Java-J2EE. They have their own arguments that goes against Ejb. Let us go in details with their arguments.

Financial Cost

If I myself am a manager and have limited budget to develop an enterprise application, I will have to consider cost aspect of the Ejb too before choosing it for the application development. To host Ejb, one need specialized Ejb container. Most time Ejb servers are not sold separately. But they come within a package along with web server combined known as application server. And such application servers are considerably costly. If the application is going to be developed with Ejb, there are very less open source choices left for the developers as sever implementation. Even if they are available, there will be need of experts to maintain them.
So selection of Ejb as a part of development technology is going to affect cost factor considerably.

Not Required

As I have mentioned in introduction, Ejb was introduced to attain some features in enterprise applications inherently and declaratively. But if they can be achieved without using Ejb why to take overhead, cost and time to develop Ejb? Let us view each feature that Ejb offers to see if they can be achieved without Ejb or not.

• Resource Pooling: This feature can be achieved in enterprise applications simply with any J2EE web server. Most modern web servers support connection pooling.
  .
• Security: Experience says that it is rarely required to authenticate a call to business component from a view or controller component (JSP or Servlet). If authentication mechanism is already implemented at controller layer, there is no need to authenticate internal call again. So this feature is rarely used in any application.
  .
• Transactions: Developer can easily maintain transactions from simple Java classes using JTA or any custom transaction implementation. Now-a-day Ejb is used for the purpose to maintain transactions only. But, looking at the performance overhead of Ejb, managing transactions without Ejb is more efficient way.
  .
• Container-managed Persistence: Most people who started using Ejb in development of enterprise applications, end up with separating Data Access Layer from Ejb for the purpose of manageability and transparency. People normally refrain from using container-managed persistence for many reasons. Also container-managed persistence some times comes with performance drawbacks and it lacks flexibility of implementation.
  .
• Scalability: Any experienced Java developer will agree that scalability can be achieved without Ejb and that is very easy too. It requires proper design and architecture of the application. If the application is designed in a particular fashion, it is not very difficult to attain scalability without Ejb in application.
  .
• Reusability: All java classes are reusable. In fact Java programming language being almost purely object oriented, offers this features by itself. Clear separation of layers will make java classes and libraries reusable if they are designed for reusability.
  .
• Remote Access: Remote access of objects has been in Java technology since years prior to introduction of Ejb to the technology. Remote Method Invocation and CORBA are in place and many people have successfully developed applications using these technologies when it is required to access Java objects remotely. So even for remote access Ejb is not mandatory.

Performance Cost

It has been well know fact that Ejb comes with performance overhead. Starting from deployment of application in the server to getting handle of Ejb and accessing methods adds significant overhead in performance of the application. As Ejb instance-pooling mechanism is maintained using Java Naming and Directory Interface (JNDI) acquiring handle to Ejb slower downs the application. Also method call takes time as they pass through container. Ejb 2.0 supports local calls to Ejb but they also pass through container, which is a separate JVM itself.
It has been observed that for these reasons, Ejb has performance drawbacks.

Development Cost

To develop and deploy Ejb successfully on any web severs there is always need to people having experience and expertise in working with Ejb. Also application development with Ejb takes somewhat longer time then similar process without Ejb because of complexity of Ejb. While developing enterprise applications with Ejb hiring people having knowledge of Ejb adds cost to the project considerably. Also maintenance after development of application requires people who are skilled in Ejb.
These factors denote that Ejb is going to increase costs at the time of development and also for its maintenance

But Sometimes

As I committed during the introduction, we are not going to conclude any thing without hearing from both sides. From above discussed points one may lead to conclude that Ejb is no an essential technology or no more required as a part of J2EE. But that is not the fact, there are cases when Ejb are significant to enterprise applications. Now we shall go in details of those cases where usage of Ejb can play a significant role.

Readymade Framework

As we have discussed above most features which are provided by Ejb can be achieved without Ejb also. But to achieve all those features in an enterprise application, one has to design and develop the application very carefully and only people having expertise in that area can do it. Normally people end up with having their own framework in absence of Ejb to attain those features.
Ejb comes with all those features in a bundle where application developers need not worry about implementing them. So to develop enterprise application with a rapid speed and to attain stability of application soon, Ejb can be used as a handy option.

Utilization of Skills

If you already have people in your organization having proficient knowledge of Ejb and experience in developing enterprise applications using Ejb in case, Ejb is not going to be very costly for you. Here there is no need to train people to use Ejb and if they have experience in developing applications with Ejb, they can develop new applications sooner with Ejb.

J2EE Best Practices

If you try to get best out of J2EE technology, and try to implement best practices tried by the world to achieve stability, maintainability, performance and other coherent features in enterprise application, you will have to develop entire architecture before you start developing the application. Again here people end up with developing their own J2EE framework to attain benefits of Ejb without using Ejb.
In such cases Ejb can be used to implement such best practices with an ease and simplicity.

For Component Providers

People who are in business of providing Java or J2EE components to application developers or provider of pluggable third party components should be more interested in Ejb. Actually Ejb was designed primarily for scalability of applications. Ejb is very easy to plug to any J2EE application because of its declarativeness. Even third party Ejb can be plugged in after completion of development phase of enterprise application. Also because of its remote accessibility, Ejb adds value to it as pluggable object.

To Cope With Complexity of Application

Sometimes enterprise applications are having too complex functionality and too wide scope of use that it becomes almost difficult to develop such applications without Ejb. Along with the complexity of the application, developers of the application have to take care of things which are automatically taken care by the Ejb container. In such cases, it is advisable to take advantage of Ejb technology, which offers a bundle of features with fewer efforts.

Summary

Well after hearing both sides it may seem difficult to conclude weather it is advisable to use Ejb while developing enterprise applications over the top of J2EE or not. But, we can safely say that usage of Ejb for enterprise application is no always mandatory. It can be avoided if the functionality of the application is not too complex to develop without Ejb. Also if application has requirement to implement Ejb specific features in a very custom way, Ejb cannot be used as it comes with its own standard implementation.