Why Portals Must Die

A few days back I read a couple articles on some efforts by Google. These were an article on Googles Gadet effort and Google /BEA mash up talks.

While interesting in their own right and likely the kind of thing being done by Yahoo, Microsoft and others it got me to thinking about a mantra I have had going for some time:

Portals must DIE.

This is not to say portals themselves in concept are bad things. Only that they are often used or implemented poorly. I oversee a JSR-168 based portal myself and direct development of applications under that. The intent of portals is obvious. It provides a development group a unified display and authentication API set, among others, to work with. This helps to focus development skill and look and feel issues. A great thing compared to developing against a myriad of API's. Of course portal API's themselves don't talk to each other so little was gained for efforts outside the local enterprise (or enterprise group). In the Java camp the JSR-168 helps to focus efforts around a common portlet spec and that is great. Web services for remote portlets (WSRP) might have been a wonderful thing had I ever seen one example of it in the wild.

It is just that portals don't allow for dynamic mixing of content from various sites into my own space. I can't easily (yet) pull maps from Google, stock tickers from Yahoo, search interfaces from 3rd party databases sites and simply drop them into my page and have them work with authentication and styles (CSS) resident there. I want to be able to do this, so portals must die.

I believe that the common HTML DOM or a CDF derived instance is the common glue (as I spoke about in my OpenDoc posting). Combine this with remote AJAX applications that have some capacity for awareness of secure federated identity and we begin to see the a portlet concept in this environment. Secure "inter-AJAX portlet" communication could be done via a messaging middle-ware though I want to explore what Javascript allows in terms of intercommunication between various functions in a web page to see if that is possible. Look and feel issues could be addressed through systematic CSS utilization. In a manner similar to GWT.

To me the future portal is a simple DOM with portable code that can be pulled across the net to create its UI through local DOM object manipulation. Combine this with federated identity and CSS based styling for logging in and look and feel issues respectively. Let the whole thing talk to a services oriented architecture for logic execution. Hopefully the efforts of the W3C Rich Web Clients efforts will go well.