PGI: Porthole Gateway Interface

Overview and Motivation

What are portals?

The Porthole Gateway Interface is a mechanism for implementing portal-like mechanisms with a simple interface akin to CGI. The word portal means different things to different people; here we use it as Sun seem to in their JSR168 standard. A portal-page is one which can be seen as drawing in content from a number of largely independent processes executing in a common environment and displaying them on a single page. The individual components to generate fragments of a page are commonly known as portlets however, as Sun have ninja lawyers, we should probably call them portholes.

There is no such thing as a page which is a portal, and one which is not, it is an attitude toward a page, an idea in the mind of an individual. The PGI system is a mechanism and infrastructure for implementors who wish to regard their page as a portal for the purposes of development. Pages which might be considered portals include:

• A corporate home-page type page containing many sidebars, and subwindows, arranging panels a little as an operating system might, in addition to central content. The canonical examples here are stock-tickers and weather updates, though day-trading and window-gazing are unusual activities for a corporation to be encouraging, with the ubiquity of these two examples we must assume they have some value. In an educational environment, RSS feeds of news from organisations advertising seminars and from funding bodies might prove popular "sideshows". Online help and community-contributed notes on a page could be further useful applications. This is the canonical heavyweight portal application, and creators of vacuuous instances of such portals have, unfortunately, given the whole idea a bad name.
• Some sites have a much simpler stucture, but could still benefit from being considered as portals. Many complex sites have navigation sidebars, centralised authentication across a number of "scripts", include headers and footers, and have content customized according to identity. These sites can be largely static except in the matters mentioned above but, with present technology, tend to be implemented dynamically, with much complexity and inefficiency as a result. A site with only a few of these features will probably not benefit from being considered as a portal, though those with more of these features almost certainly will.
• Complex web applications such as webmail, if implemented as native applications, would be implemented in terms of a number of windows or panes, and usually also have such an appearance in webapps. The separation of each of these panes, tied by a common environment, allows a modularisation of coding, effective cacheing, and so on, making the code more robust, and better performing.

The common connection here is that of a number of fragments which, whilst communicating with each other, are lagely independent and tend to be part of the same code only because of the rather tangential property of them being rendered on the same page. HTML frames were designed to solve some of these problems, even though they largely failed in those goals.

Existing implementations, and the need for another

The idea of the portal (in this sense) came from the Java world. Many implementations exist within that context and are supremely portable to the many other platforms with JVMs. portlets can be written in Java and run everywhere. Within this slightly imperial context, the portability problem is solved.

The motivation for this specification, though, was that such restrictions on club entry remain effective barriers to writing portals in many contexts where they would be useful. The choice languages of the web remain Perl and PHP, particularly for small projects. A portlet or porthole should be just such a small project, that's part of the value of the portal idea. Servlet containers, largely required for portal implementations, remain rare on many web-servers, even in relatively large organisations. They tend to be complex beasts, requiring trained handlers.

In education, the context of the development of this standard, value is greatly increased with simplicity of implementation because the required expertese in programming and systems administration decreases, so allowing entry to more field-experts. Requirements and Evaluation criteria are almost always far more complex tasks in educational software than is the implementation, and delegating this implementation as closely as possible to those active in the field will produce better quality software.

The lack of effective infrastructure to develop portals in the web-scripting languages of choice has meant that it's been difficult for a keen IT-non-expert, who tend to produce the best application software in this field, to contribute to modern complex sites. The lack of simple administration of the portal as-a-whole has put it out of range of many educational institutions, who simply cannot afford commercial systems administartion expertese.

The purpose of PGI, then, is to present a simple CGI-like interface for scripting in PHP, in Perl, in Java, in C, whatever. Simple, small modules, invoked as processes, allow a user to script simple portholes to place into a portal. Small support libraries in each language can also simplify the implementation task.

What services are provided by such an infrastructure?

The obvious service provided by controlling infrastructure is the invocation of portholes, the gathering of their content, and their assembly into a page. Further to this, a controller needs a machanism to route incoming request data to a particular porthole. Many implementations allow a distinguished porthole to receive the submited data prior to the aforementioned page-assembly, in order that the porthole may choose to profoundly alter the rendering of the composite page. Also, a porthole needs some mechanism of at least telegraphic communicaiton with other portholes, and also more persistent storage, if only to establish the location and type of common communication points. An argument system often allows the "containing" porthole (in an HTML sense) to pass parameters to an inner porthole.

The assembly mechanism has available unique information concerning the assembly process, allowing cacheing at this level which is unvavilable to the web-server, web-browser, or any of the portholes. It's important, then, that the assembler contains mechanisms for cacheing pages and fragments. This is particularly important given the apparently expensive process-creation mechanisms used by PGI to implement portholes.

These facilities naturally cover other cacheing needs which are currently poorly catered-for, including closed-set-static-pages where a computation is required to determine which of a small closed set of pages is generated at a particular URL (for example, by authentication, or by "skin"). Such pages are relatively common, and our cacheing mechanisms allow these pages to be statically served without script-invocation once they are cached. Though some of these pages may not be natural portals, PGI may be an appropriate solution for only this feature.

Contrary to the odd approach widely taken in the portal world, the outer frames are not distinguished and are implemented in PGI as another porthole. The assembler is also unconcerned with issues such as the mechanism of authentication or "skinning". An undistinguished more-outer porthole (or otherwise) can simply insert this information into the porthole communication channels, using distinguished headers to communicate with the assembler's cache. The assembler is thin.

This project was executed as an infrastructure component of an EPSRC CTA award at CARET.