Summary
In a recent blog post, Bill Burke reviews the current popularity trends of EJB, a now ten-year old standard for building enterprise Java components.
Advertisement
EJB is now a ten-year old technology. Over this decade, alternative solutions emerged to the problem of enterprise component architecture, the most notable one being Spring. In a recent blog post, EJB maintains its dominance, JBoss' Bill Burke notes that EJB alternatives notwithstanding, the EJB landscape is still healthy, and that EJB's market share is still growing.
Burke bases his observations on the job market, downloads of JBoss' EJB 3 implementation, and the sales of EJB books:
Even after almost 10 years, EJB is still going strong and maintaining its dominance. With the emergence of Seam and Web Beans being incorporated into EE 6, I predict this trend to continue...
Over 3 years EJB jobs have remained pretty much constant. This is very encouraging news... EJB really did not have an alternative in the Java space until 2004/2005 when Spring started to be known and popular. It is very interesting to see that although EJB has had a serious competitor, it has maintained its dominance in Java application development over the years. You could even extrapolate from these numbers that EJB is an upper bound on the number of Java component jobs out there and that Spring has only recently matched this. This is proven by the fact that the Spring and Java graph trends are the same since they converged 6 months ago...
Burke points to job trend graphs between 2005 and the present to illustrate that EJB-related skills are increasingly appreciated by the market place:
How dominant do you think EJB is in your projects? Do you think the EJB 3 standard helped revive interest in using EJBs?
Thumbs down on EJBs. The concept behind EJB is worthless for most applications. What's the point of running things in a separate container if everything has to go to the same database? Just distributing the database calls is not gaining anything at all. There is practically zero time spent sending the query, so why cluster the "make and send the query" aspect? On the other hand, if you use EJBs as OR mapping, then use a real tool and not something that does OR mapping only as an afterthought.
EJB is over engineered bloatware with very unfavorable ratio of power to conceptual complexity, just like JSF and a lot of other things Sun gets involved in. Sun has no concept of elegance or thinness or simplicity. These are foreign concepts to Sun. Every framework Sun puts out is heavy, bureaucratic, verbose, and labyrinthine (A lot like Microsoft, except Microsoft hides their garbage behind 20 layers of GUI so you don't feel it as much). It's all made to sound good when you give a bullshit PowerPoint presentation to execs. It's got the buzz words and pretty boxes to look at and so on. But it doesn't carry its weight when real programmers use it.
Also the notion of a thin client connection to EJB container directly simply didn't materialize. People want Web applications and this desire is not going to vanish, but just keeps getting stronger.
Having said that, there probably are some applications that do benefit from EJBs. I will guess they do a lot of computation, like maybe statistics simulations or something like that. Then you can farm out work to various EJBs and collate the result.
The only people who use EJBs are those who still believe the old hype and who believe that "real men" must have an EJB layer, because it's bad ass and looks good on resume (never mind if it's useful or actually good for the application -- screw that!). So people choose EJB based on "I gotta have that EJB bullet on my resume" and not based on its technical merits (what merits?).
Quote: "Spring has only recently matched this" disappointing that a comment like that would come from a pioneer and a respected man in Enterprise App. Development.
Spring is *relatively* new, EJB had a considerable head start. The fact that it is catching up to the popularity of the conventional JEE approach is impressive (for Spring).
That Graph actually suggests that Spring will either equal EJB's in dominance or surpass it.
I've used both, and in all honesty I prefer Spring (that's a personal bias though).