In Response to JSR-286: The Edge of Irrelevance

I have to admit, I can totally relate to Eric Spiegelberg’s article, JSR-286: The Edge of Irrelevance.
It’s a great article; in case you don’t have time to check it out, Eric’s main thesis is that:

the portal architecture lacks enough technical advantages and distinguishing features to warrant an increase in acceptance.

Over the past few years, I’ve complained about there being a “portlet spec, not a portal spec” - a thought Eric seems to echo in pointing out that most real-world projects require modifying the portal server but that in doing so, you’re tied to your vendor’s API and are no longer JSR168/286 compliant.

One of the other running themes in the article is that the portlet specs are perpetually out-dated. For example, the JSR286 spec itself (which went final release in June 2008) mentions its aim to align the portlet spec with JavaEE 1.4 (which went final release in November 2003)!

All-too-often portal is an after-thought: first came Spring MVC, then came Spring Portlet MVC; first came JSF, then came a new spec (JSR301 - the portlet bridge) to make JSF work in the portal environment. As frameworks like JBoss Seam are solving the truly challenging problems with web applications (contextual state management, back button, multiple browser windows), portal lags behind, requiring patchwork to support fundamental pieces of the new JavaEE.

Finally, I also agree with Eric that portal’s “greatest strength, the portlet, remains its greatest weakness”. On my current project, we fight with the portlet programming model every day. One could argue that if we’re having constant problems w/portal, then we’ve either got a bad design, bad developers, or we’ve incorrectly chosen to apply portal to our problem. I can hear the crowd now: “you’re doing it wrong”.

Regardless, I think our woes support the author’s point that the portlet development paradigm is “overly restrictive” and that the technology and features provided by portal don’t add enough value for the costs.

So, given the downsides, portal does have its benefits - IMHO portal’s primary strong suit is in aggregating web applications. Yet still I agree with the author that this benefit doesn’t outweigh the costs - you don’t get your money’s worth, so to speak.

So what do you all think?

Does Java EE need a new, less restrictive means for aggregating web applications?
Or do the author and I understate the benefits of portal? What other benefits do JSR168 and JSR286 provide?

From http://www.andypemberton.com/