Tracking change and innovation in the enterprise software development community
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
Create REST
-enabled Web Apps
with Project Zero
from IBM.
Posted by Floyd Marinescu on Feb 12, 2008 05:00 PM
Rod Johnson ran some job listings comparisons between EJB and Spring on Indeed.com, a job listings aggregation website, and by interpreting their results draws a few conclusions related to the evolution of EJB and its future. He frames the discussion around EJB by focusing on session and message beans and acknowledges the value of JPA which, as a separate specification, "is based on modern technology, and is proving its value." Johnson first writes about the significance of job demand trends:
Job listings are a good indicator of the true adoption of technologies. They indicate whether or not companies are spending money, making it possible to distinguish substance from hype; they indicate the importance for developers of gaining and growing the relevant skills (an important element of technology perpetuation); and they provide a good guide to the safety for companies in adopting a particular technology.
Johnson then presents a chart which shows that, in November 2007, Spring surpassed EJB in terms of skills requirements for Java job listings. He finds this amazing given the considerable amount of existing EJB-based applications.
Johnson draws some personal satisfaction from observing these trends as he has been predicting since 2003 that EJB will lose its relevance due to deficiencies he described in his book about J2EE without EJB. Even the new improvements in EJB3.0, in his view, are not sufficient to deter these trends:
EJB 3.0 improves things somewhat, but it's still too little, too late: the DI capability is less than has proven to be needed for the real world; the interception API recognizes the need for a solution to cross-cutting concerns, but provides the least capable, clunkiest and most error-prone solution yet seen (something I've been meaning to blog on for a while); it's saddled with the baggage of backward compatibility with now irrelevant previous generation technologies; the full EJB contract (which is hundreds of pages longer than the "simplified programming model") dictates a complex runtime with excessive overhead; despite its syntax sugar, it fails to address a number of deficiencies in EJB such as startup actions, singletons and the obsolete threading model. Finally, it's effectively tied to an app server environment, at a time of changing infrastructure.
He then interprets what the decline of EJB means for the industry as a whole and for individual developers:
- It's not necessarily a rejection of standards–just a healthy rejection of standards that don't deliver results. As I've long argued, Java EE is more than EJB, and anyone who cares about the platform as a whole should be honest about the relevance and quality of the parts.
- With better technology, business objects become POJOs, dependence on specific component models diminishes and labels become less important.
- Moving away from EJB provides greater architectural flexibility, at a time when requirements are changing, through the rise of SOA and other forces, and companies are increasingly choosing lighter-weight deployment platforms.
Johnson concludes that "as the absolute numbers are still very high, EJB is not going to go away completely any time soon. But the trend lines clearly suggest that it is becoming legacy." An EJB skeptic, Rick Hightower also believes that EJB will still be around for some time but points out a possible concern with the way the comparison was constructed:
However, EJB is far from dead, isn't it? Is it really fair to compare a general purpose framework like Spring (i.e., Spring MVC, Spring WebFlow, Spring XXX) with a very focused framework like EJB? Relative comparisons are not very fair to established players as you can see by this graph comparing EJB3, Seam and Spring.
Ray Van Eperen also commented in regards to the need to consider the possible impact of other technologies:
...there is an obvious omission of technologies such as Seam, that combined with EJB 3.0 addresses many of the historic weaknesses of the EJB model as well as provides many of the same advantages as Spring (use of POJOs, IOC, etc.), and in my humble opinion, does it better than Spring (for instance almost purely annotation-based rather than XML). I'm not knocking Spring, I'm just saying that EJB3 combined with Seam and other technologies such as JSF provide a very viable alternative.
Given that a significant share of EJB-based applications rely on application servers that use proprietary implementations of the EJB specification, these trends probably also show an increased confidence among companies in leveraging open-source frameworks for their core Java enterprise component models. While these comparisons prove the significant momentum the Spring framework is gaining, do they also signal that the EJB model is at the brink of starting to lose its relevance?
Podcast download: An interview with Dmitry Sklyut on OSGi
Scale your applications without punishing your database
WebSphere Virtual Enterprise 3 minute demo
RESTful todo list sample tutorial with Groovy & Project Zero
The Agile Business Analyst: Skills and Techniques needed for Agile
Growth data isn't so useful for technologies with low absolute numbers. As evidenced by the way the Seam graphic jumps around. The absolute number comparison is interesting and shows that Seam has a tiny proportion of Spring's usage. Regarding Raymond Van Eperen's comment that "in my humble opinion [EJB 3.0] does it better than Spring (for instance almost purely annotation-based rather than XML)", Spring 2.5 has far more sophisticated annotation support than EJB 3.0, including the JSR-250 annotations like @Resource that EJB uses for its DI. There's a summary here and more detailed information in this InfoQ article by Mark Fisher. Rgds Rod
I think it is the 10th article with similar approach and content from Spring guys, I have read on the net.
Growth data isn't so useful for technologies with low absolute numbers. As evidenced by the way the Seam graphic jumps around. The absolute number comparison is interesting and shows that Seam has a tiny proportion of Spring's usage.
Regarding Raymond Van Eperen's comment that "in my humble opinion [EJB 3.0] does it better than Spring (for instance almost purely annotation-based rather than XML)", Spring 2.5 has far more sophisticated annotation support than EJB 3.0, including the JSR-250 annotations like @Resource that EJB uses for its DI. There's a summary here and more detailed information in this InfoQ article by Mark Fisher.
Rgds
Rod
Well Rod, if you are going to take that approach, you could say, by looking at your blog that since EJB jobs have remained constant over time, this is an upper bound and Spring has only recently matched that upper bound.
One more thing, Your blog Rod, was really the first time I looked at any EJB/Spring job statistics. Based on your rhetoric over the years, you would have thought that EJB jobs would have been on the decline. Instead they have remained constant. I credit this to the work done in EE 5 and the emergence of Seam, but, hey, anybody can extrapolate basically anything they want from stats, right?
I'd like to find some fair way of determining if _developers_ would ever choose Seam/EJB over Spring. I know a lot of companies have been sold EJB by app server vendors, and a lot of architects (the kind who no longer code) have bought into EJB based on the safety network effect alone ("well at least we're not in this shitstorm alone..."). But I'd like to meet a developer who would would choose JSF and EJB3.0 over Spring and any number of the lighter-weight web frameworks for Java (Stripes comes to mind). Or a developer who would choose to use JPA (EntityManager) over straight-up Hibernate 3 (Core). I'm not saying they don't exist, or that they're wrong. But I would like to understand what they're thinking. Clinton
I think it is the 10th article with similar approach and content from Spring guys, I have read on the net.
I have written exactly one blog on this topic. If editors choose to pick up a blog, that's up to them.
Bill
Well Rod, if you are going to take that approach, you could say, by looking at your blog that since EJB jobs have remained constant over time, this is an upper bound and Spring has only recently matched that upper bound.
That could only be true if EJB had fully penetrated the enterprise Java market. Thankfully, it never did. As for an upper bound, the graphs only show information up to November 2007. Given the growth trend, as you would expect, Spring is far ahead today. Follow the links under the image and you will see there is now a large gap There are 6289 Spring jobs and 5690 EJB and the gap is enlarging weekly.
Rgds
Rod
Bill
Your blog Rod, was really the first time I looked at any EJB/Spring job statistics. Based on your rhetoric over the years, you would have thought that EJB jobs would have been on the decline. Instead they have remained constant. I credit this to the work done in EE 5 and the emergence of Seam, but, hey, anybody can extrapolate basically anything they want from stats, right?
I credit it to legacy.
It clearly can't be the emergence of Seam because then we would see Seam requirements appearing in for a significant proportion of the EJB requirements. In fact, "Seam and Java and EJB" returns 49 jobs. That's 4520 jobs fewer than the total for EJB.
Rgds
Rod
Correction. "Seam and Java and EJB" returns 49 jobs. That's 5641 jobs fewer than the total for EJB.
There is only one Java shop using Seam at the moment in the city I am in, a small government agency migrated from model 1 JSP to JSF/Seam/JPA. As long as JSF is still in the cold, it's hard for Seam to take off. How many shops using Spring? don't know. These days everyone says they use Spring, even if only to inject a few objects or use the JDBC convenience classes.
Just when I was started to respect infoq you had to go an kill it for me with this stupid post. I don't care what products are being compared. These skill requirement, job growth, job demand posts are f###ing retarded.
Just when I was started to respect infoq you had to go an kill it for me with this stupid post.
I don't care what products are being compared. These skill requirement, job growth, job demand posts are f###ing retarded.
Matt I get that you feel this way. It's our role to report on trends and Spring matching EJB on third party verifiable job sites seemed like a trend worth raising awareness of. Don't shoot the messenger. :)
@Rod: I wrote about a different view of these statistics. The point being that the true state of things is much murkier and grey than your perspective of the world Rod. I know you have to make it a black and white argument, you need to promote your company, which is totally fair.
It's our role to report on trends and Spring matching EJB on third party verifiable job sites seemed like a trend worth raising awareness of. Don't shoot the messenger. :)
It is just that it is such a "serverside.com" thing to do.
Bill Burk won't publish my response in his blog, so here is my response to a misleading statement posted there: "EJB3, which is a completely different thing. As I said in another place, I think they only keep the EJB name to not embarrass the creators of EJB2…" EJB3 still has stateless sessin bean, stateful session bean, 2.0 entity bean, and message driven bean.
EJB3 still has and only has ...
George Jiang, I have moderation turned on in my blog. Since I'm not online 24/7 you may experience a delay in seeing your post. If you look through comments on my various blogs, you'll see I'm pretty lenient on what is allowed to get posted. Yours was accepted as soon as I got around to administering my blog.
Rod - .. but you can clearly see by the following statistically irrelevant chart that Spring has completely bottomed out with JavaEE projects and JBoss is now going to dominate the universe: http://www.indeed.com/jobtrends?q=spring+javaee%2C+jboss+javaee&relative=1 Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
this one is more phallic: http://www.indeed.com/jobtrends?q=rod+and+johnson%2C+bill+and+burke&l=
Here goes:-
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
21 comments
Reply