JSR 286 is not Irrelevant

Eric got it wrong:

While there is nothing you can do in a portlet that you can’t do in a servlet, the inverse is definitely not true.

And it shouldn’t be, because portlets are specializations of servlets.

Many new portlet features either have long been available in servlets or simply solve portlet-specific issues.

What issues should a portlet spec solve?

With its render request, action request, and more complex lifecycle, a portlet is a different animal than a servlet, and finding developers experienced with portlets has been a significant challenge on every portal project I’ve been a part of.

It is the same for alternatives like Netvibes and OpenSocial.

If you are willing to acknowledge that it was this monolithic all-or-nothing design philosophy that lead to EJB being essentially rejected by the Java community, it is also reasonable to think that the same philosophy has and always will significantly hinder the portal architecture.

The comparison doesn’t apply, because portlets are lightweight applications, unlike 3.0- EJBs.

Reading between the lines, this means that the stated primary goal of the recently released JSR-286 is to align itself with the latest and greatest Enterprise Java technology of 2003.

Nobody pushed it, because there was a sales downturn and the OSS community, where development continued, wasn’t there.

Despite the recent release of JSR-286, I think the elephant in the room is that the portal architecture’s window of opportunity to become a mainstream technology has not only closed, but closed quite some time ago.

Many recent developments, like SOA and Web 2.0, have all to do with portals.

In practice, few applications can constrain themselves to the isolated and disparate functionality of portlets, and relinquishing this degree of architectural control is unrealistic in enterprise-level software.

I don’t know what he meant with “isolated” and “disparate”, but I agree with Subbu that the portlet programming model isn’t broken. “Portlet services” are to be provided by the outer Java EE container, not the portlet container.

Andy didn’t get it right either.

Shame on java.net.


4 thoughts on “JSR 286 is not Irrelevant

  1. You do have a couple of good points here, especially re: the portlet spec extending the servlet spec.

    I’m not all against the portlet specs; I just think that Eric’s point that the cons of the framework outweigh the pros is very valid.

    I don’t have too much time to respond here, but a few quick thoughts:

    1) Not sure how SOA and Web 2.0 have “all to do with portals”. The stats would show that most applications built out with what are being called Web 2.0 technologies are typically not even built on Java – with PHP being the most predominant language. Again, I’d argue that portal is an after thought when it comes to both the SOA and Web 2.0 movements.

    2) “Absolutely not.” – not sure that this is a worthwhile argument. Truthfully, I don’t feel that the portlet specs are as much irrelevant as they are too specific in application and over-applied to business problems.

    Anyway; enjoyed your write-up.


  2. The link between SOA and Web 2.0, and portals is that they are all aggregation technologies. The low use of Java in Web 2.0 applications seems off-topic to me.

    I have revised the “Absolutely not” argument, let me know what you think about it.

  3. Good points, yet again. =) I’d actually say the Web 2.0 point supports the argument that portal can sometimes be an afterthought, as these technology stacks were developed outside the portal and then brought into the portal after the fact.

    Regardless, I actually do think the portlet specs have their place; I’d like to see the portlet specs treated as an official and important part of the JavaEE specification, as opposed to ‘an afterthought’. I think this would do a lot for participation and maturity of the specs.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.