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.
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.
Shame on java.net.