Posted by boneill42
on March 3, 2008 at 8:30 AM PST
Traditional web application development may be better suited to languages that afford more agile development (e.g. Ruby on Rails) and enterprise application integration needs a SOA & ESB approach (backed by a messaging-system). This approach isn't/wasn't the central focus of J2EE, which may just leave it out in the cold, whilst the younger up and coming specs take the reins.
I recently presented at the Philly JUG . In my presentation , I asked the question, "Is J2EE dead?", half-kidding, but mostly serious.
I've spent the last six months developing in Ruby (some on Rails). It quickly went from just a past time, where I was developing a silly little beer review site called liquidMirth to serious business applications (at the day job: rVooz ). And now I have to admit, the compile, build, deploy cycle of a standard J2EE application seems unbelievably daunting. Combine that with the cumbersome and seemingly never ending twiddling of meta-data and deployment descriptor files required by the libraries and frameworks (e.g. Spring & Hibernate) that are supposedly helping the problem and you have an incredibly unproductive environment for web application development.
I'd emphasize that this is unproductive for web applications, because web applications need to be especially responsive to user requirements. J2EE simply isn't agile enough. There is a
fantastic video by someone out at NASA JPL that does a fantastic job comparing the latest web application development frameworks. He does a great job emphasizing this point.
Now, all that said, J2EE != Java and Java's present sweet spot is in SOA, and business process integration, where things need to be transactional, and message-oriented/event-driven. Web frameworks are having trouble in that area, where things don't fit into a nice request/response interaction. On the "back-end" you need a bit more rigor, and typically you need to integrate with systems that won't conform to convention.
So, IMHO -- let more flexible languages accommodate the fickle nature of users. Use Java, with specifications like JBI and SCA, to implement an ESB on the back-end to do the heavy business process lifting, systems integration, and B2B style interactions.
And if you do that, you'll quickly realize that you don't need much (if any) of the J2EE spec to get-r-done. Instead, OpenESB in J2SE, ServiceMix, or Mule fill the bill quite nicely.
just two cents, and here is another nickel's worth of similar sentiment .