WSRP Reincarnation of Service Oriented Architecture
Asif Akram1, Rob Allan1 and Rob Crouchley2
1
e-Science Centre, CCLRC Daresbury Laboratory, Warrington WA4 4AD, UK
2
e-Science Centre of Excellence, University of Lancaster, UK
Abstract
Portlets are not confined to one portal framework; Web Services for Remote Portlets (WSRP) defines
standard for interactive, user-facing Web services to make portlets hosted by geographically
distributed portal frameworks accessible in single portal. WSRP specifies protocol which is focused
on transferring the mark-up fragments generated by portlet producers to be consumed by portal/nonportal and Web/non-Web applications. This remote sharing of portlets will greatly ease the
construction of large-scale portal based systems, or Virtual Research Environment, enabling them to
be more scaleable, manageable and maintainable; core theme of Service Oriented Architecture (SOA).
WSRP is suggested to be natural tool for SOA systems; provides the missing presentation layer with
additional needed features in the existing SOA.
Introduction to Portlets
Portlets are user-facing, multi-step, interactive modules
that can be plugged in to a portal application. The JSR
168 Portlet Specification 1.0 defines a set of application
programming interfaces (APIs) that address aggregation,
personalization, presentation and security issues to
enable interoperability between portlets and portal
containers [1]. Portlets process requests from Web
clients and generate content fragments that create a
portion of a Web page. The complementary Web
Services for Remote Portlets (WSRP) specification was
created by the Organization for the Advancement of
Structured Information Standards (OASIS) with input
from a number of commercial organisations [2,3]. It is
based on mature XML and Web services specifications
that allow the plug-and-play of services in portals and
other Web applications that aggregate content from
disparate sources. WSRP is a cross-vendor protocol that
defines a set of interfaces for enabling portal and nonportal Web applications alike to incorporate portlets
deployed remotely. It was designed to enable businesses
to provide pre-defined interfaces to content or
applications in a form that does not require any manual
adaptation by consuming applications. WSRP thus
enables developers to consume portlets published by
other portal sites, regardless of the business system
(Portal Framework) they use. It allows business level
tools to integrate different similar and related portlet
services in a dynamic fashion (coupling of services on
the fly) by publication and discovery in registries such as
UDDI using WSDL. Like any Web service, WSRP is
also language agnostic although tooling currently only
exists in Java.
Components of WSRP
It is important to explore different components in WSRP
architecture, before analysing their working and their
role in SOA. Figure 2 illustrates each of the primary
actors within WSRP architecture and how they fit with
each other, although in the figure WSRP consumer is
only serving one user/Web Browser but there is nothing
to stop consumer servicing many users, WSRP consumer
has Portlet Repository, which is more than simple Portlet
Repository, Portlet Repository contains mapping of
WSRP Portlets offered by respective WSRP Producer
and personalization information of each WSRP
Consumer and selected WSRP Portlets.
Figure 2 Components of WSRP architecture
The WSRP Specification defines the following actors
within WSRP architecture:
ƒ WSRP Producer: Producers are modelled as
containers of portlets. The Producers are Web
service with common set of operations such as:
Self Description, Mark up, Registration, and
Portlet Management. Producers can optionally
manage the registration of consumers and require
them to pre-register prior to interacting with
portlets. A registration establishes a relationship
between Consumers and Producers. The WSRP
producer is a true Web service, complete with a
WSDL and a set of endpoints. Every producer in
WSRP is described using a standardized WSDL
document.
ƒ WSRP Portlet: A WSRP portlet is a pluggable
user interface component that lives inside of a
WSRP producer and is accessed remotely through
the interface defined by that producer. A WSRP
portlet is not a Web service in its own right (it
cannot be accessed directly, but instead must be
accessed through its parent producer).
ƒ WSRP Consumer: This is a Web service client
that invokes producer-offered WSRP Web services
and provides an environment for users to interact
with portlets offered by one or more WSRP
producers. Consumers are similar in nature to
routers that work on behalf of the end user. The
Consumer will route requests from users to the
appropriate Producer.
Interfaces for WSRP
To standardize communication between WSRP
consumer and WSRP producer, WSRP defines a set of
common interfaces that all WSRP Producers are required
to implement and which WSRP Consumers must use to
interact with remotely-running portlets. Standardizing
these interfaces allows a portal to interact with remotelyrunning portlets generically, since it has a well-defined
mechanism for communicating with any WSRPcompliant producer. The WSRP Specification requires
that every producer implement two required interfaces,
while allowing them to optionally implement two others
as well [8]:
ƒ Service Description Interface (required): The
Service Description Interface allows a WSRP
producer to advertise its capabilities to perspective
consumers. A WSRP consumer can use this
interface to query a producer to discover what
portlets the producer offers, as well as additional
metadata about the producer itself. This interface
can act as a discovery mechanism to determine the
set of offered portlets, but also importantly allows
consumers to determine additional information
about the producer's technical capabilities. The
producer's metadata might include information
about whether the producer requires registration or
cookie initialization before a consumer can interact
with any of the portlets.
interaction with another portlet on the same page
takes place).
ƒ Registration
Interface
(optional):
The
Registration Interface allows a WSRP producer to
require that WSRP consumers perform some sort
of registration before they can interact with the
service through the Service Description and Markup interfaces. Through this mechanism a producer
can customize its behaviour to a specific type of
consumer. For example, a producer might filter the
set of offered portlets based on a particular
consumer. In addition, the Registration Interface
serves as a mechanism to allow the producer and
consumer to open a dialogue so that they can
exchange information about each others' technical
capabilities.
ƒ Portlet Management Interface (optional): The
Portlet Management Interface gives the WSRP
consumer access to the life cycle of the remotelyrunning portlet. A consumer would have the ability
to customize a portlet's behaviour or even destroy
an instance of a remotely-running portlet using this
interface.
Communication Sequence
Most powerful capabilities in WSRP is the ability to
dynamically leverage applications from others servers.
Consumer Portal can be set-up to dynamically discover
and associate different portlets that are available from
different WSRP Producer Portals in the network
provided WSRP Producer publishes themselves in the
global Universal Description, Discovery, and Integration
(UDDI) [9]. The result is a brand new portal that can
dynamically integrate new functionality to streamline a
business process and empower portal users from
geographically dispersed Portal Servers. Typical
discovery scenario consists of following message
sequences among WSRP Consumer, WSRP Producer
and End User.
ƒ Mark-up Interface (required): The Mark-up
Interface allows a WSRP consumer to interact with
a remotely running portlet on a WSRP producer.
For example, a consumer would use this interface
to perform some interaction when an end-user
submits a form from the portal page. Additionally,
a portal might need to simply obtain the latest
mark-up based on the current state of the portlet
(for example when the user clicks refresh or
Figure 3 Sequence of Messages Flow [7]
1.
2.
3.
4.
5.
6.
7.
8.
9.
Consumer discovers a Producer.
Consumer and Producer relationship is established.
Consumer learns all the capabilities of a Producer.
End user establishes a relationship with a
Consumer.
Consumer aggregates pages, often with portlets,
for users.
End user sends a page request to a Consumer.
Consumer requests information from Producer.
Producer provides Consumers with logic and data.
End user sees aggregated page.
Loose-Coupling; (vi) Ease of Configuration and Use;
(vii) Statefulness; (viii) Identity Management; (ix)
Granularity; (x) Plug-and-Play Architecture; (xi)
Flexibility; (xii) Extensibility; (xiii) User Interaction;
(xiv) Application Connectivity; (xv) Process Integration;
(xvi) Information Integration;’ (xvii) Build to Integrate.
Service Oriented Architecture
Modular software is required to avoid failure in large
systems, especially where there are complex user
requirements. The concept of a Service Oriented
Architecture (SOA) was developed to avoid the
problems of having to re-write large portions of code to
accommodate changing requirements. A SOA is
essentially a collection of autonomous, self contained,
pluggable, loosely coupled services which have welldefined interfaces and functionality with little side
effect. A service is thus a function that is self-contained
and immune to the context or state of other services.
These services can communicate with each other either
by explicit messages which are descriptive, rather than
instructive or there could be a number of “master”
services coordinating or aggregating activities, e.g. in a
workflow. SOA is an architectural style whose goal is to
achieve loose coupling among interacting software
agents; stateless processors. SOA achieves this loose
coupling by employing two architectural constraints: (i)
a small set of simple and ubiquitous interfaces to all
participating software agents; (ii) the interfaces should
be universally available for all providers and consumers.
A service invokes a unit of work done by a service
provider to achieve desired end results for a service
consumer, in this case via a portlet. The consumerprovider role is abstract and the precise relationship
relies on the context of that specific problem. For a fuller
discussion of SOA and classification of possible service
components for research, education, collaboration and
access to information see [4]. Service-orientation is an
important complement to object-orientation that applies
the lessons learned from component software, messageoriented middleware and distributed object computing.
WSRP Extending SOA – the Portal Grid
The main objective of SOA, to aggregate services into a
system, is built to allow for change. The system can use
established services or adopt new services that appear
after the original services and clients have been
deployed, and these must not break functionality. The
availability and stability of individual services is critical
for the functionality and performance of the system.
WSRP provides enhanced and extended support for the
following crucial requirements of SOA in a portal
context: (i) Secure Login; (ii) Single Sign-On (SSO);
(iii) Quick Development; (iv) Component Re-use; (v)
Figure 1 Single Sign-On Portal View
The core of the idea is pretty straightforward - take all
your software and make them available as services on
the network. Enterprise software is not usually that
flexible and it was not built to be used as services so
companies have to add service layers to expose existing
“heritage” applications for them to be consumed and
integrated into other applications. This is a temporary
solution that seems to work for now; WSRP provides a
natural solution to the demanding challenge of
developing sophisticated Web-based user interfaces
through its plug-and-play approach with flexibility to
accommodate dynamic requirements. In WSRP the
consumer and provider interact via pre-defined message
exchanges independent of the content and context of the
problem which is key for a scaleable and practical SOA.
Implementation of a Virtual Research
Environment
Portlets are not confined to one portal framework. The
WSRP specification aims to define a standard for
interactive, user-facing Web services making portlets
hosted by different geographically distributed portal
frameworks accessible in a single portal, see [5,6].
Unlike traditional Web services however, WSRP defines
a protocol which is focused on transferring the mark-up
fragments generated by portlet producers to be
consumed by portal/ non-portal and Web/ non-Web
applications. A remotely deployed service with a portlet
interface can be published and consumed in many
portals. This remote sharing of a single portlet will
greatly ease the construction of large-scale portal based
systems, or Virtual Research Environments, enabling
them to be more scaleable, manageable and
maintainable; core themes of SOA. WSRP provides the
missing presentation layer to SOA while taking care of
the main requirements of SOA. WSRP is suggested as a
natural tool for SOA systems with additional features
felt missing in the existing SOA implementations.
WSRP is not confined to Web based Portal
development but can be used for non-portal
development, which increases its significance and
usability in different solutions ranging from Web
application to GUI applications, e.g. using Swing.
WSRP defines how Web services plug into portals and
as messages exchanged are simple XML-SOAP
messages and can be transformed to different format to
address the requirements of different devices ranging
from desktop to PDA. The WSRP standard allows
remote portlets to be implemented in various ways,
including on the Java/ J2EE and Microsoft .NET
platforms and published/ consumed in all sorts of
programming languages providing XML can be parsed
and transformed.
Example Scenario
Web services offer a mechanism to create platformindependent services, and JSR-168 defines a standard by
which to develop portlets. While Web services give the
ability to reuse back-end services, WSRP lets reuse the
entire user interface.
It might be useful to provide researcher a portal with the
ability to submit jobs on the remote machine. There is
likely, already a Web service which provides precisely
this capability. We can search for the UDDI registries
for a required/compatible Web Service. After
discovering such a service we need to code a client to
bind to and consume the Web service, as well as develop
a portlet to allow portal users to interact with the service
and deploying the newly developed portlet and Web
services client on portal server. By the end of the day,
we've developed and deployed job submission service
functionality to the end-user as portlet. Re-using the
existing services reduce efforts and development time.
Publishing this front end of service as portlet through
WSRP producer allows other researchers to search and
consume WSRP portlet. We need well maintained
repositories of WSRP Producer where researchers can
search the portlets available and use them in custom
tailored fashion, making Virtual Research Environment
by aggregating existing services and user interfaces in
countless ways. One portal can be aggregation of
different portlets developed by different people and
providing user interface to geographically distributed
services creating VRE based on SOA.
Summary
WSRP provides the complete solution to the SOA,
which is essential for the Integrated e-Science
Environment at CCLRC and in the JISC VRE
Programme [6]. WSRP is flexible set of interfaces which
can be extended to meet the requirements. WSRP
Consumer registers with WSRP Producer (although
registration is optional) to develop secure environment.
Producers identify each consumer with a unique handle.
This handle helps identify what portlets are available to a
particular consumer. WSRP Consumer can register or
subscribe to any number of WSRP Producers and makes
those remote portlets available to consumer. WSRP
Consumer is acting as limited portlet registry and end
user search this repository to aggregate different portlets
into portal. Portal can be aggregation of dispersed
portlets, which themselves provide interface to remote
services making true distributed environment. WSRP
Consumer maintains the repository of end users, with
their selected portlets, personal presentation preferences
and the order in which they are aggregated in the portal.
WSRP Producer sends the mark-up of individual portlets
and WSRP Consumer formats them according to the
customer preferences. This transformation may be
converting HTML into WML, VoiceXML, or any
custom format specified by the user, applying XML
Style Sheet. The benefit of this technique is re-usability,
saleability and endless solutions. WSRP Producer is
meant to provide general mark-up in HTML format
without knowing the requirement of end user and it is
WSRP consumer which transform and aggregates markup into different possible ways. All security constraints
can be deployed at WSRP Consumer to achieve Secure
Login; Single Sign-On; Session Handling; Registration/
de-Registration.
References
[1] Portal specification JSR 168 and API
http://www.jcp.org/aboutJava/communityprocess/review
/jsr168/
[2] WSRP Specification 1.0 by OASIS
http://www.oasisopen.org/committees/download.php/3343/oasis-200304wsrp-specification-1.0.pdf
http://www.oasis[3]
WSRP
Primer
1.0
open.org/committees/download.php/10539/wsrp-primer1.0.html
[4] R.J. Allan, A. Hardisty, S. Wilson and A. Powell
Service Component Classification
http://www.grids.ac.uk/ETF/public/WebServices/classes.
html
[5] R.J. Allan, C. Awre, M. Baker and A. Fish Portals
and Portlets 2003. Proc. NeSC Workshop 14-17/7/2003
(CCLRC and NeSC, 2004)
[6] R.J. Allan, R. Crouchley et al. VRE Roadmap (JISC
VRE Working Group, 2004)
http://www.jisc.ac.uk/index.cfm?name=programme_vre
[7] WSRP with WebLogic Portal.
http://edocs.beasys.com/wlp/docs81/wsrp/intro.html
[8] Bryan Castle (castle_bryan@bah.com) Introduction
to Web Services for Remote Portlets. http://www106.ibm.com/developerworks/webservices/library/wswsrp/?Open&ca=daw-ws-dr
[9] UDDI www.uddi.org/