Andy is a software engineer and consultant, currently working for CapTech Ventures in Richmond, VA. His specialties are JavaEE and front-end development, and is an open source and web standard enthusiast. He has over 8 years experience developing web sites and applications, holds several Sun certifications, and blogs at Andy has posted 4 posts at DZone. You can read more from them at their website. View Full User Profile

In Response to JSR-286: The Edge of Irrelevance

  • submit to reddit

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?


Published at DZone with permission of its author, Andy Pemberton.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Alex(JAlexoid) ... replied on Sat, 2009/01/24 - 10:53am

I have neve heard os a really "sucessful" postal  deployment.
Maybe, somewhere where nothing custom is required...
Otherwise, portal development is just a lot of hacks.

Witch is usually done better by (name ANY web framework in existence) .

Dan Turkenkopf replied on Sat, 2009/01/24 - 7:50pm in response to: Alex(JAlexoid) Panzin

I agree.

In most of the portal projects I've seen / been involved with, the decision to use a portal technology is made well before the desired functionality is defined.

This leads to building Web applications as a collection of portlets that leverage the proprietary portal code for navigation and inter-portlet communication (which wouldn't be needed if a standard web app were built).

I know I've fallen into the trap personally a few times, but it's very hard to tell a customer that we're not going to leverage their new shiny Portal server they just paid $80K for.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.