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.

Contents:

1. Introduction

In his piece "On Helicopters and Submarines" [1], 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?

3. Functional goals

(Display aggregation)

(Single sign-on)

(Personalization) - persistently

(Display refresh)

4. Architectural considerations

(Network layering models)

(MVC patterns)

(Security in the presentation layer?)

(Monolothic vs focused components)

(Simplicity, complexity and fragility)

5. Standards

(JSR-168)

(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?

(HTTP)

(Javascript)

(XML)

(SAML)

(Shibboleth)

6. Implementation considerations

(Java - the enterprise incumbent)

The reality of the Web is multiple languages communicating seamlessly with open protocols. C, Java, Perl, PHP, Python, Ruby, Visual Basic, Javascript and more are all widely used. New ideas tend to be prototyped in lightweight languages and maybe later imlemented in a more heavyweight fashion. Building a web infrastructure around a single language does not recognize this state of affairs.

(Inter-portlet communication: pubsub notification)

(AJAX)

(Async notification)

  1. 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

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.