Figure 8: Viewing the Notepad
Experience gathered by the Archaeology Data Service from development of the HEIRPORT portal, the ARENA portal and the in-house catalogue search system, ArchSearch, has informed design decisions throughout the portlet development. Combining this experience with a recognition of the current trends of data reuse found throughout the web, it became apparent that the user should be able to take something away from a session. This was an important factor in contributing towards HEIRPORT lite as a 'research tool' rather than as just another search interface.
Investigations of the implementation of such a feature led to the Notepad mechanism, based on the concept of a typical web-based shopping cart system. Throughout the session, the user can add or remove various records to the Notepad in order to create a custom list of records that they found suitable for the research at hand. Further, it was suggested that the user should be able to export this custom list of records in a format suitable for reuse or dissemination.
The idea of the Notepad system combined with HEIRPORT's multiple data source model allows the user to aggregate information from various searches across the different datasets – a feature that is missing from the current HEIRPORT and ARENA portals.
Implementation of the basic Notepad extension went relatively smoothly because the various result sets held within the model were essentially stored as XML formatted string objects. Thus, it was relatively easy to allow the user to choose specific records from a results page to be added to the Notepad. Upon receiving such a request, the portlet essentially copies the relevant nodes from the resultsXML structure across to a NotepadXML structure.
The result sets have been defined in such a way that the user can add a selection of record summaries to the Notepad by ticking the appropriate checkboxes and clicking the 'update notepad' button.
At any stage of the query, the user can click on the notepad icon found alongside the other icons on the menu bar. By doing this the user is taken to the notepad screen where the NotepadXML data is displayed.
Aside from browsing the various Notepad entries as collected throughout the session, the user can either clear the current notepad by clicking the trashcan icon, or choose to export the contents of the notepad by clicking on the disk icon. The exported notepad data has been formatted as an XML document to ensure maximum reuse potential (see Figure 8)
Figure 8: Viewing the Notepad
Following the model of extending HEIRPORT lite with the Notepad extension, the notion of incorporating further geographic and data visualisation functionality by using external applications or resources was investigated.
Of particular interest was the potential of exploiting the geographical information contained within the majority of HEIRPORT records by using MapServer – an open source software package already used by the ADS for a number of different map-based projects (e.g. as the map-based search interface to the ARENA portal discussed by Kenny and Richards in this issue of Internet Archaeology). MapServer is a Common Gateway Interface (CGI) application that, although not being a full-featured Geographical Information System (GIS), offers enough core web-GIS functionality to create map-based web applications.
MapServer accepts input in the form of CGI variables sent via either 'GET' or 'POST' methods. It uses a template-based system to allow basic configuration of the output as defined in a MapFile. The MapFile can contain as little information as an imagepath and imageurl or contain a list of layers, points etc. The product of a typical MapServer query is a URL pointing to a temporary image created in a directory on the same server that hosts MapServer.
Communication between the portlet and MapServer was achieved by using both a Java Bean (a reusable software programme – Glossary) acting as a wrapper for the CGI application, and a basic MapFile template that returned MapServer output variables as a java collection. This mechanism allowed the creation of maps with dynamically generated points to be used within the portlet. The Java Bean was based upon an example bean as discussed within a thread found in the official MapServer mailing lists (Lime 2002). The whole mechanism is fairly simple yet serves as an effective demonstration of how easy it can be to wrap suitable external application functionality within a portlet application.
There were several suggestions about the best possible use of the MapServer functionality, ranging from the creation of a distribution map based on a set of returned records, to a simple location map on a per record basis. The later was deemed the most appropriate solution given the somewhat limited time constraints and the experimental nature of this endeavour.
One of the biggest shortcomings of the JSR-168 specification is the lack of support for Inter Portlet Communication (hereafter referred to as IPC). The fact that individual portlet applications can communicate between themselves is an invaluable asset to the specification and promotion of the idea of portlet-based research toolkits. Indeed, the current trend for the development of Virtual Research Environments, such as the Sakai project, which also supports JSR-168, could well benefit from the inclusion of a standardised method for IPC.
The JSR-168 specification makes it apparent that it is possible to package several portlets together to create what is known as a 'portlet application'. Further, all portlets contained within a portlet application have access to a shared 'portlet session' – an area where various information can be stored that is explicitly related to the individual users session. An IPC mechanism was achieved by exploiting these two features drawn from the specification.
To facilitate inter portal communication each portlet first needs to register an id within the portlet session. With these in place, a custom URL pointing to a specific id could then be created by any of the portlets within the portlet application. This URL, known as an 'actionURL', contains various parameters that mean something to the target portlet.
This mechanism was incorporated into HEIRPORT lite allowing the aforementioned Notepad and Map extensions to be presented in a modular fashion. The following 3-stage example has been included to highlight the steps necessary for the HEIRPORT lite portlet to communicate with the Map extension portlet using the IPC mechanism as outlined above:
Figure 9: Inter-portlet communication demonstrated via the Map extension
HEIRPORT lite was designed to conform with the JSR-168 specification; consequently the portlet can be 'plugged' into any JSR-168 compliant portal framework (as shown in Figure 10). HEIRPORT lite was succesfully deployed to both the ADS instance of uPortal and also the CREE Test Portal.
Following the sucessful deployment of the portlet using the standard method of installing individual instances locally per portal, the next step was to see how well WSRP worked in practice.
The WSRP mechanism (Glossary) is relatively straightforward: a WSRP Producer is responsible for hosting the portlet and offering it as a service, while a WSRP Consumer, such as uPortal, sends SOAP (Glossary) requests to the Producer for a portlet instance. The Producer sends the relevant mark-up back to the Consumer in order for it to be aggregated along with other local or remote portlets on a portal page. This 'handshaking' is a continual relationship throughout the portlet lifecycle – when the user clicks a portlet action, the relevant code is sent back to the Producer which in turn performs the required actions and sends the updated mark-up back to the Consumer.
Although simple in principle, the WSRP specification is still relatively immature and rather difficult to implement. The Oxford-based CREE partners, however, have developed a method of using Apache's WSRP-4J Producer software to communicate with uPortal's own WSRP Consumer interface. This has been made available as a detailed step-by-step guide (Dovey 2005). As a result of this communication interface, the ADS was able to set up a WSRP service based on the above configuration for the CREE project. This allowed HEIRPORT lite to be consumed by a number of test portal systems making data available from different sites in different locations for different user groups.
Figure 10: Instance of HEIRPORT lite in various portal environments
© Internet Archaeology/Author(s)
University of York legal statements | Terms and Conditions
| File last updated: Tue Sep 27 2005