Andy Pemberton Rotating Header Image

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?

8 Comments on “In response to JSR-286: The Edge of Irrelevance”

  1. #1 Edserman
    on Jan 22nd, 2009 at 7:50 am

    I’d like to understand your definition of “web application aggregation”, as I have been struggling to see the benefits of portal applications from a developer standpointy…I primarily see it as a having a usability and UI advantage, rather then a technical one, e.g. its primiarly for the benefit of the Portal user…

  2. #2 Chris Wash
    on Jan 22nd, 2009 at 9:47 am

    It needs to be embraced as part of JavaEE or abandoned. The other standards have been driven by innovation, this one is always too little too late.

  3. #3 let x=x › JSR286 and vendor sales teams
    on Jan 24th, 2009 at 9:20 pm

    [...] speculated that the new Java portal specification JSR286 was at the edge of irrelevance. And others agree. I think it’s worse than irrelevant - it’s a solution in search of a [...]

  4. #4 portalguy
    on Jan 26th, 2009 at 7:26 am

    Portal is a terrible solution for a RIA.
    It’s fine for simple pages but once things get complicated on the client side, maintenance becomes a nightmare, there’s no separation and bugs are frequent.

  5. #5 Dominique De Vito
    on Jan 29th, 2009 at 10:30 am

    You are right complaining about [the spec] being a “portlet spec, not a portal spec”.
    I would rather prefer a spec specifying portal pieces, like SSO, communication bus, conversation context… instead of a portlet spec. Well, these pieces are more and more specified, then the remaining part, the portlet spec, look like more and more useless, like living separated.

    Indeed, you could notice that some open source projects, like Seam, do provide feature like “conversation context”. The portal technology is “attacked” by other projects more widely accepted, and that cut roots of portal benefits.

    IMHO, a portal is just a sophisticated home page, with multiple content and SSO. I don’t buy constraining myself into portlet technology for an entire project, while only the home page may need that technology !

    The portlet API is cumbersome, too far away over traditionnal web development. And the portlet web development does not take benefits from other efforts from the more traditionnal web development.
    Then, yes, the portlet developments look like an after-thought, evolving slower than other more focused project, easier to grasp.

    Well, you know, after years, the portlet API is still not part of Java EE… It should be based on some reason the portlet way is not well widespread.

    Other alternatives look like existing or coming, like widgets or OpenSocial :

    Goodbye JSR-168 and WSRP portlets… Hello OpenSocial gadgets!
    http://blogs.alfresco.com/wp/luissala/2008/12/09/goodbye-jsr-168-and-wsrp-portlets-hello-opensocial-gadgets/

    Widgets vs. Portlets
    http://www.megginson.com/blogs/quoderat/2008/07/14/widgets-vs-portlets/

  6. #6 JSR 286 is not Irrelevant « Simples Assim
    on Mar 21st, 2009 at 11:53 pm

    [...] didn’t get it right [...]

  7. #7 Krishna Baddam
    on Jun 20th, 2009 at 5:15 pm

    I agree that Java world needs a better standard for web content aggregation. J2EE needs a SharePoint.

  8. #8 Craig R Hunt
    on Nov 4th, 2009 at 12:23 pm

    Excellent observations. Still the value proposition remains in empowering the user experience and related communities in distributed application sources. (Techies recognize this high value proposition in the concept of decoupling dependency to support changes) The problem is the JSR Portal Spec cannot, or at least has not yet, effectively addressed the distributed ownership rights issue because it is outside the traditional architecture domain addressed with specs. I do think it will come in time the form of standardized Portal hosting where WSRP-like portals permit trusted empowered users to interconnect their distributed sources in a public grid of home computers. Maybe the Linux developer community will put something like a customized JetSpeed II Web Portal in their package libraries someday.

Leave a Comment