What went Wrong with J2EE
Thursday, July 13th 2006 | Ismael Ghalimi
Three months ago, I explained what I thought was wrong with J2EE. More recently, a lot of controversy was stirred when J2EE developer extraordinaire Richard Monson-Haefel, now a senior analyst with the Burton Group, predicted the death of the J2EE architecture in a SOA-dominated world.
When a schmuck like myself makes such a prediction, nobody really pays attention, and it might be better that way. But Richard Monson-Haefel is no schmuck. In fact, in the world of J2EE, he is as much a mensch as anyone else. And when someone of his caliber goes on the way he did, it gets noticed.
I worked with Richard six years ago when Intalio contracted him and David Blevins to develop our Open Source EJB container, called OpenEJB. The code he and his team wrote went on to become the foundation for Apache Geronimo, the only serious competitor to JBoss. Through this experience, I developed a great deal of respect for Richard’s technical wizardry and pragmatic judgement, which is why I got interested by his recent positions.
Without getting back into the core of the debate — others are more qualified than I am for that — I must agree with Richard’s main point that J2EE as a platform has reached a level of complexity that makes it virtually unusable for even the most sophisticated Java developers. And for the rest of us, VB guys, PHP folks, or HTML crafters, J2EE is so arcane that we only wish we will never have to deal with.
That is not to say that J2EE won’t be used anymore — in fact most of Intalio|BPMS is built on top of the J2EE platform, but the primary developer using it will work for software vendors rather than be part of an IT staff. J2EE will be everywhere, but very few people will touch it directly, much like very few people actually write assembly code today.
For simple things, simpler frameworks such as Ruby on Rails will be used. And for the more complex tasks, developers will turn to bottoms-up or middle-out BPM solutions, using a BPEL editor or a BPMN designer to model fully executable processes in a Zero Code manner.
J2EE is dead! Long live J2EE!
Entry filed under: BPM 2.0, Standardization
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|











I’m more inclined to say “J2EE is Dead! Long Live Anything Else!”
He is the real deal; someone who can use the tools, and not just write about them. When Aberdeen looked at the fine prints on my CV, and saw that I was a former AT BIOS and FORTH programmer, with experience in embedded systems design, they said, “you better get the hell outa here, you’re too technical.”
[…] But within a J2EE environment, with requirements to support the emerging Service Oriented Architecture (SOA), the challenge became an order of magnitude more complex. Ask any J2EE experts whether they think they could do their job in a Zero Code and One Click Deploy manner, and you’ll get a condescending smile in return, at best. There is nothing fundamentally wrong with J2EE, but it’s just too complex for your average developer to be productive with it, and totally unsuited for process analysts. This was discussed in more details in this previous article. […]
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment