next up previous contents
Next: Portlet Standards: JSR-168 and Up: Introduction Previous: Introduction   Contents

Background to Portals and VREs

Early portals were very application-specific, stovepipe solutions with nothing re-usable. Examples include the work of Larry Smarr, who coined the term ``Grid'' in 1997 and started a portals project at NCSA. The Information Power Grid portal was started in 1998 at NASA. In 1999 Mary Thomas had a group developing portals at SDSC for the NPACI Grid, IPG was still making progress and GPDK, the Grid Portal Development Kit was started at NCSA. These were components of the US Grid Portals Project. There were also Geoffrey Fox's DoD portal and the NCSA Bioportal.

At the Portals and Portlets 2003 workshop [28], Dennis Gannon presented the ``big picture'' developed within the GGF Grid Computing Environment research group with particular reference to work at University of Indiana. Other material describing portal activities of the GCE-RG can be found from the GGF Web sites [32,33]. The portal software stack was shown as four distinct layers:

  1. Grid Portal - with the ability to launch, configure and control remote Grid application instances, possibly via a factory service;
  2. OGSA layer - generic services such as:
    $\bullet$ registration and name binding
    $\bullet$ policy
    $\bullet$ security
    $\bullet$ data management
    $\bullet$ reservation and scheduling
    $\bullet$ event and messaging
    $\bullet$ administration and monitoring
    $\bullet$ logging
    $\bullet$ service orchestration
    $\bullet$ accounting
  3. OGSI (or other) layer to link to infrastructure;
  4. Resource layer with link to remote compute and data servers.

Figure 1: Four-stage Tool Architecure

\begin{picture}(0,0)%
\includegraphics{arch.ps}%
\end{picture}
@font
picture(8349,4491)(289,-4015)

Figure 1 shows a simplified picture of a fairly typical architecture for Grid-based tools as used in HPCPortal from CCLRC [8]. Whilst some of the stages may be merged (typically stages 2 and 3), logically the architecture comprises:

Client:
client tools and user interface. The latter may be a Web browser, GUI, drag 'n' drop environment, script or programming library toolkit. Typically there will be a firewall between the client and the front-end server so CGI and/ or Web services will be used through port 80 or port 8080 via a Web cache;
Front-end server:
some services may be configured on other ports which could complicate the picture. It may also be desireable to have an internal firewall to protect ``private'' services, e.g. access to the real databases and computational resources. For this reason a front-end server acts as a gateway. If Web services are being used, it may validate the requests and it may also implement some form of primary access control;
Back-end server:
the ``real'' services are implemented on the back-end server which is only sent requests following the primary access control and filtering. The back-end server may implement some simple functionality for the users and also carry out important operations such as session and state management. If no additional firewall is required front and back end may be merged using a simple and fast interface. Some development tools such as WebSphere facilitate this approach;
Remote resource:
accessed from a back-end service by a remote procedure call using Globus or other Grid middleware such as LSF, Condor or PBS linked into the back-end services or a Grid service interface. They are not typically exposed directly to the end user. However, for anonymous services (e.g. registry lookup) a simple Web service will suffice.

This architecture has been found to be effective in practice and permits trade-offs between security, configurability and performance.

People are currently defining what types of services are needed in an Open Services Architecture [44,55,71]. The Grid could be defined as a collection of distributed services and a portal as a conduit to these. Solutions are built on components, where a component is a thing defined by (1) a public interface (2) semantics and a ``standard'' behaviour. Using a portlet framework's user interface, each component/ service can have its own interface, a portlet to underlying services. These are ``plugged'' or ``tiled'' in a customisable fashion onto one or more views in the portal.

This picture is typical of a family of Grid portals now providing rapid development and extensibility features. A user interacts by logging on and implicitly creating a "context" or ``session'' which comprises his/ her recently used objects, files, jobs etc. These are represented by a set of tools for remote access and Grid services each associated with a unique portlet. Users can select the portlets they require for a particular job and to customise their portal workspace.

The ``big picture'' from the JISC Common Information Environment (IE) portal activities was presented by Chris Awre. For other related information see http://www.jisc.ac.uk/index.cfm?name=programme_portals, http://www.jisc.ac.uk/ie/ and http://www.jisc.ac.uk/index.cfm?name=strat_ieds0105_draft2.

The IE programme wants a small number of sophisticated interfaces for increased ease of access and use of JISC resources. The IE technical architecture was developed by UKOLN. It encompasses: content providers (institutional or commercial); fusion layer (brokers, aggregators, catalogues, indices); authentication/ authorisation (currently Athens); service registry, preference services, metadata schema registries, resolvers, institutional preferences, terminology services.

A useful description of the JISC Information Environment architecture can be found on-line at http://www.ukoln.ac.uk/distributed-systems/jisc-ie/arch/. Portals are just a small part of this impressive programme of work.

There is a strategy for seamless and integrated access to digital collections. This includes connections to museums, archives and e-Science for learning and teaching. There are distinct building blocks with open standards.

The development programmes include:

For the JISC Information Environment portals provide the following functionality:

$\bullet$ Discovery tools, access search functions on (commercial) providers
$\bullet$ Lightweight, source remote content
$\bullet$ Common means of access via open standards, OAI, Z39.50
$\bullet$ Presentation of information
$\bullet$ User access via different routes: dedicated Web site, embedded functionality in known Web environment
$\bullet$ Could be a PDA in future

We note that in this sense Google, which is probably now the most widely used ``killer'' search-engine application on the Web, is not a portal, but a ``gateway'', it only tells us where the information is, it does not aggregate it, although its specialised functionality, such as image searches, is growing rapidly. More information on these and related ideas is provided in an FAQ at http://www.jisc.ac.uk/index.cfm?name=ie_portalsfaq.


next up previous contents
Next: Portlet Standards: JSR-168 and Up: Introduction Previous: Introduction   Contents
Rob Allan 2005-05-09