Interface 21 and BEA recently announced the release of Pitchfork, the EJB3 implementation within the Weblogic container, built using Spring. It is actually more than an implementation of EJB3 specification and provides the additional capabilities offered by Spring, viz. full use of AOP and AspectJ integration, advanced DI capabilities etc. Every EJB u build can use all Spring backed services along with JSR 250 annotations and EJB style interceptions.
This release has sparked off a war of words between the Spring and JBoss community. The trail at Raible's blog is an interesting read and provides in depth analysis and invaluable judgement to architects and developers building up their Java EE stack. At the same time it also opens up a new can of worms, enough to put the entire Java EE developer community into a bed of confusion. After struggling with the hell of deployment descriptors and the infamous programming model of EJB2, I had been enlightened with the lights of the landmark book by Rod Johnson, which instantly indoctrinated me to the Spring world of POJOs, Dependency Injection and IoC Containers. I had always felt that Spring + Hibernate make my day. But some of the recent developments in the Java open source world like the tie up of Spring with BEA/WLS has pitchforked me (no pun intended!) into a world of uncertainty. Myself, being a Java developer by heart (of course my CEO thinks otherwise and does not give me a raise for architecting a good piece of Spring bean :-(), can't help but seek replies from the elite community regarding the following questions :
Question 1
Regarding EJB 3, Bruce Tate once mentioned "Don't make me eat the elephant again". We all know, EJB is a standard and being compliant with the standard is like programming to the interface. I don't like to get locked in an implementation. EJB 3 is designed for extension - as Gavin has rightly mentioned in the same trail, we should strive to provide add-ons via extension points provided in the EJB specification and offer them portably on all application servers. JBoss is pledging to provide opensource extension to EJB3 that adds pointcuts, which would spruce up EJB 3's anemic dependency injection functionality. As of this day, JBoss offers an Embeddable EJB3 Container using which u can deploy applications in Tomcat. Next time when I offer my Java EE stack to my client, should I go for the most trusted IoC container (a.k.a. Spring) and run the risk of locking myself to a concrete implementation OR try to eat the elephant again.
Question 2
Is there anything under the hood in Spring's tie up with BEA ? With the open source community raging amock, BEA has started losing grounds, they have lost their innovation trail and has come to the hard realization that they need to have Spring in their arms to beat the time to market of their competitors. But what is the value proposition of Spring in this entire deal - are they trying to trade in their quasi-EJB3 container (quoted from Gavin King in the comments trail in Matt Raible's blog entry) with the standards based implementations used by the huge customer base of BEA and WLS.
Parting Thoughts
The deficiencies of the current EJB3 specfication and implementation have been documented in many burning blogs and articles. OTOH, all is not green in the Spring world either. Spring does not have SFSBs - hence cannot provide an efficient implementation of EPC, modeling conversations in Spring is also broken (I have not yet looked at Spring 2.0) and above all u need to deal with reams of XML for whatever u want to do. Gavin King, trying to desperately defend his stake on the EJB3 specifications, has branded AOP as an overhyped and failed technology - possibly all for the sake of pushing the JBoss camp. Believe it or not, the open source world of the Java community is on fire. They have realized that all innovation happens here but the technology needs to carry the endorsement of Sun for it to reap the commercial benefits. As Peter Thomas has rightly pointed out in his blog, the open source landscape is getting increasingly commercialized nowadays. The developer community needs to make the proper judgement before deciding whether to eat the elephant or not.
No comments:
Post a Comment