Figure 1: Information gateway as featured within the University of Nottingham portal
Source: http://my.nottingham.ac.uk/cp/home/loginf
In recent years several online information systems such as ARENA have been created containing a portal interface. It is not surprising, then, that confusion can occur between these systems and enterprise level institutional portals discussed in this section. For the purpose of this article, portals such as ARENA should be thought of as information portals rather than institutional portals, which are the primary subject of the following section.
Enterprise level institutional portals differ from fixed design information portals such as ARENA. An institutional portal can be defined as an online environment offering personalised content aggregation to those at the institution concerned, e.g. students and staff at a university. Typically, an institutional portal features a single-sign-on username/password authentication system and the portal can provide a secure framework to provide a wide variety of online services and resources. Along with content aggregation, the look and feel of the portal can often be adjusted. These changes are maintained in the user's profile allowing the creation of a personalised online environment.
If the portal is the container, portlets can be thought of as the building-blocks that make up the content. Essentially, portlets are used by portals as pluggable user interface components that provide a presentation layer to information systems. In a typical institutional portal, portlets are presented across a predefined collection of pages arranged by tabs. The user can edit existing pages or create further pages within the portal by choosing 'which' portlets he/she requires, and 'where' they are to be arranged on the page. Portlet content can vary, it is not uncommon to find services such as library search interfaces, access to university web-mail, scheduled calendar systems and access to online databases to name but a few.
With the benefits of this technology so evident, many universities in the UK have started to implement portal and content management systems. Indeed, both the University of Nottingham and the University of Hull have aggregated the majority of their student services within an institutional portal (see Figures 1 and 2).
Figure 1: Information gateway as featured within the University of Nottingham portal
Source: http://my.nottingham.ac.uk/cp/home/loginf
Figure 2: Access to IMAP email system as featured within the University of Hull portal
Source: http://www.hull.ac.uk/esig/portaltour/Student/email.html
There are a number of different portal and content management solutions available, ranging from leading commercial packages such as IBM's WebSphere Portal or Oracle Portal Server, to open source products such as JA-SIG's uPortal or Apache's JetSpeed 2. As the number of different portal frameworks has grown, so too has the need to create portlets that can be used within each of these differing platforms. By defining the Java Specification Request 168 portlet specification (JSR-168), Sun and partners have potentially allowed developers to create a one-hat-fits-all solution to providing portability. In other words, if a portlet has been written to be JSR-168 compliant, then any portal framework that supports the JSR-168 specification can host it. Although this specification is indeed Java-specific, it has nevertheless been adopted as one of the definitive standards from which to base portlet development (see Section 4).
The standard method for deploying JSR-168 portlets is literally to 'plug' the portlet component into the various portal systems. Each portlet needs to be installed on the same machine as the portal, which can lead to issues regarding portlet maintenance and updates. For example, if changes need to be made to the portlet code then the host would need to acquire the latest version of the portlet and reinstall it into the portal system. When portlets have been developed in-house, this may not necessarily be too much of a problem. However, for institutions that have outsourced portlet development or perhaps acquired portlets from various online repositories, this could indeed become a concern.
The Web Services for Remote Portlets v1.0 OASIS open standard (WSRP) (Glossary) was approved in 2003 to help address such issues. WSRP is a Web services protocol for aggregating content and interactive web applications from remote sources. By using WSRP, the institutional portal can consume and aggregate a portlet within its framework without the need to host the actual portlet itself. This allows the most up-to-date version of the portlet to be displayed upon request.
© Internet Archaeology/Author(s)
University of York legal statements | Terms and Conditions
| File last updated: Tue Sep 27 2005