The Java world has a JSR-286 standard for how portals and portlets should interoperate: software components sharing a unified web page.
There seem to be a number of portal implementations. But is there a live “marketplace” of interchangeable portlets that will run in them? From what I can find searching the web, it looks very lopsided – all portals and no portlets. It’s like if there were dozens of Android phones and no apps.
If a product were to base itself on JSR-286 (or some implementation thereof), what’s the likelihood of a corporate customer having a bunch of portlets that it might want to add to the portal?
It strikes me that most corporates will already have a portal-like page based on their choice of ERP or CRM product that their business runs on, or maybe even just MS Outlook’s “Today” page. So if I ship a new product intended for corporate customers, and I make it a portal (rather than a set of portlets) what is the likelihood of my customers abandoning their existing IBM/SAP/Oracle portal and using my portal as their new homepage? (I’m guessing: not great.) And if I make it a set of JSR-286 compliant portlets, are my customers going to have a way to host host portlets? (I’m guessing: also not great).
Finally, JSR-286 seems quite mute about HTML+JavaScript, i.e. how portals and portlets would interoperate inside the browser. It’s all about Java-based server-side stuff, defining a way to cooperate in the use of URLs so that each full-page-refresh can be routed to the correct portlet. It doesn’t seem to acknowledge the modern, rich AJAX approach. It mentions AJAX only in passing.
This blog post (and the comments under it) have provided a lot of food for thought and seem to confirm my suspicions:
Professional hands-on experience along
with the above research led me to the
conclusion that the portal
architecture lacks enough technical
advantages and distinguishing features
to warrant an increase in acceptance.
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… the portal architecture’s
window of opportunity to become a
mainstream technology has not only
closed, but closed quite some time
ago.
So to summarise this as a more coherent question: what actual value would I get by building on JSR-286 at this point?
The only advantage I know of offhand is that when vendors of enterprise software have “portal integration” on their feature checklist, it usually means they’ve written portlets according to the JSR-168 or JSR-286 standards. SAP, Banner, and Magnolia are some of the systems that we use here that work this way, and some organizations find value in the portal approach.
However, as you correctly point out, this imposes some frustrating limitations on the application author. We’ve also found the value of portals to be somewhat dubious when put up next to a Single Sign On system that saves the user the hassle of signing into multiple applications, but which still allows each application the full benefits of the browser environment.
FWIW, if you do decide to distribute your work as a collection of portlets, there are existing portal systems that are free/open source which you could provide for folks who didn’t already have a portlet container:
http://java-source.net/open-source/portals
Hope all of that helps a bit.