Adapting Existing Search Tools for Use with the JSR 168 and WSRP Portlet Standards: The CREE Project
| Pages | 22-26 |
| DOI | https://doi.org/10.1108/07419050510644356 |
| Published date | 01 December 2005 |
| Date | 01 December 2005 |
| Author | Jonathan Hunter,Chris Awre |
| Subject Matter | Library & information science |
Adapting Existing Search Tools for Use with the
JSR 168 and WSRP Portlet Standards:
The CREE Project
Jonathan Hunter and Chris Awre
22 LIBRARY HITECH NEWS Number 10 2005, pp. 22-26, #Emerald Group Publishing Limited, 0741-9058, DOI 10.1108/07419050510644356
Introduction
The contextual resource evaluation
environment (CREE) project was
funded by the Joint Information
Systems Committee (JISC) in the UK
to, in part, investigate the use of the
recently released JSR 168 and web
services for remote portlets (WSRP)
portlet standards. Emerging
institutional environments such as
institutional portals offer the
opportunity to present search tools
locally to the end-user rather than
through diverse web sites. CREE
sought to investigate the adaptation of a
range of distinct search tools using the
portlet standards.
Full details of the investigations
undertaken can be found on the CREE
web site at www.hull.ac.uk/esig/cree/
This article focuses on the experiences
of one partner, at the EDINA National
Data Centre at the University of
Edinburgh[1], and the adaptation of a
bibliographic cross-search tool and
related OpenURL resolver for use
within a conformant portal framework.
Background
Viewed from the perspective of a
portal host, the JSR 168 and WSRP
standards have a similar goal: they aim
to make the aggregation of content into
portals a simple task. Assuming the
portal is compliant with the standards,
the portal host should be able to select
any conformant portlet and configure
their portal to deploy it. One of
EDINA's main roles as a Data Service
Provider is to provide online services to
the UK academic community. For an
organisation like EDINA the use of the
portlet standards offers the possibility
of a realistic means of embedding
national services within institutional
portal frameworks through the
provision of portlets compliant with one
or both of the standards.
For this case study, the two standards
are first briefly described, followed by
an overview of the services for which
portlets were developed. The
technicalities of portlet creation are
described, and finally a summary and
conclusions drawn from the experience
of partaking in the project are provided.
JSR 168 and WSRP
The JSR 168 specification defines a
set of APIs, or a contract, between the
portal (more specifically the portlet
container) and a Java portlet. A
compliant JSR 168 portlet is a software
module that should work in any portal
framework that supports the
specification. The APIs in the
specification address the areas of
personalisation, security and content
aggregation. The portlet container
provides the portlet with a runtime
environment in which the portlet can
process requests and generate markup.
The two most significant methods
defined in the interfaces are:
(1) processAction ± the portlet con-
tainer invokes this method every
time a user peforms an action in a
portlet window.
(2) doView ± called every time the
portal window is refreshed. Thus,
every individual portlet currently
in display has this method invoked
by the portlet container.
The specification does not address
which protocol a portlet should use to
communicate with external services, or
even whether it should have a reliance
on an external service: these attributes
are beyond the scope of the
specification, which is focused solely
on the contract between portal and
portlet.
The WSRP standard specifies the
interaction between an endpoint (the
user's browser), a WSRP consumer (a
compliant portal will provide this) and a
WSRP producer. Communication
between the consumer and producer is
done using the SOAP protocol, thus
allowing the developers to use their
language of choice for their
implementation. WSRP defines four
interfaces:
(1) Markup interface ± defines opera-
tions for obtaining the markup
from a portlet as well as processing
user interactions with that markup.
(2) Service description interface ±
defines an operation for acquiring
the producer's metadata.
(3) Registration interface (optional) ±
defines operations for establishing,
updating and destroying a registra-
tion.
(4) Portlet management interface
(optional) ± defines operations for
obtaining portlet metadata and for
cloning portlets for further custo-
mization.
Only the first two of these interfaces
are mandatory. The two operations in
the markup interface render and
performNonBlockingInteraction
are analogous to the two method calls
doView and processAction in JSR
168. This is significant; it allows a Java
portlet to be wrapped with web service
calls. The relevance of this with respect
to the Apache WSRP4J project is
discussed later in this article.
Those interested in a thorough
understanding of the JSR 168
specification and WSRP v1.0 standards
should read the relevant documentation
from the Java Community Process[2],
and the OASIS technicalcommittees[3].
To continue reading
Request your trial