The Problems with Portals
WORK IN PROGRESS
Portals have been used very successfully to provide access to diverse information, but there seems to be a growing trend to use them for purposes to which they are not well suited, especially in the education and research domains.
NOTE: this is a strictly personal view of the role of portal technology, and is probably not endorsed by the sponsors of this web site.
If the only tool you have is a chainsaw ... then everything starts to look like a tree 
With enough thrust ... even a cow can achieve orbit 
In his piece "On Helicopters and Submarines" , Marshall Rose argues cogently against attempts to repurpose successful technologies beyond their deisgn environments. Even when attempts to do so are initially workable, and apparently address a pressing need, design stresses thus created will lead, over time, to fault lines appearing in the overall system architectuire that are not easily overcome, resulting in software that is inflexible, fragile and expensive to develop and maintain. I believe that the current use of portal technology (notably JSR-168 and WSRP), particularly with respect to Virtual Research Environments, represents such a case of technology being pushed beyond its reasonable design limitations.
The Internet applications which have seen widespread adoption and success are those which are well attuned to a particular role within the overall Internet architecture. Indeed, the runaway success of the Internet itself can be attributed to a well-conceived, minimalist design (TCP/IP) that focused on just what was needed (moving data between network endpoint applications) with a minimum of additional overhead. Such a system completely trumped the then-predominant and more fully engineered architecture for networking, viz. OSI, by being easier to deploy and much easier to extend and adapt to emerging ideas. In the field of Internet applications, we have seen simple protocols and designs, such as SMTP, HTTP, Jabber, MIME and RSS, find widespread use and adoption, even beyond their original design intent. This can be attributed to the appropriate focus of the original designs, technical choices that are easy to understand and implement, and a willingness and capability to work with rather than overlap other technologies.
I do not believe that portals, as they are being developed, are one of these technologies that can eventually be widely used outside a very niche market. I think that alternative, more flexible approaches, to the problems addressed by portal technology will eventually arise, leaving the present systems largely redundant. In the remainder of this memo, I shall attempt to explain why I think this is the case.
2. What is a Portal?
- (Integration of presentation from disparate sources)
- (Specific functions of portals)
- Single sign-on
3. Functional goals
(Personalization) - persistently
4. Architectural considerations
(Network layering models)
(Security in the presentation layer?)
(Monolothic vs focused components)
(Simplicity, complexity and fragility)
(WSRP) - emphasis is on remoting, but I argue main benefit is programming language independence. But doesn't it look a bit like HTTP with some bells and whistles?
6. Implementation considerations
(Java - the enterprise incumbent)
(Inter-portlet communication: pubsub notification)
http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=87&page=1 - Marchall Rose "On Helicopters and Submarines" about the problems of inappropriate repurposing of technology. Also contains the chainsaw and cow in orbit quotes.
-- GrahamKlyne 2006-02-15 09:17:00