Web Services for Remote Portlets (WSRP) and Application Syndication

295
CHAPTER 12
Web Services for
Remote Portlets (WSRP)
and Application
Syndication
I
N THIS CHAPTER
, we discuss the Web Services for Remote Portlets (WSRP) standard.
WSRP defines a standard way for portals to handle input and display for a portlet
running on a remote portal server. With WSRP, one portal server (or a cluster) is
responsible for hosting a portlet, and other portal servers can display the portlet
as if it were installed locally. We present an overview of the WSRP standard, along
with the steps you need to take as a portlet developer to use WSRP.
We also cover application syndication, just as we covered content syndication
in Chapter 9. WSRP is one way to syndicate an application; other ways include
integrated frames and proxied web applications. Some of the common problems
are branding syndicated applications, Single Sign-On (SSO), and handling person-
alization for different users.
We are not going to discuss general web services programming for Java in
this chapter. If you are interested in developing Java web services with Apache
Axis, see Enterprise Java Development on a Budget (Apress, 2004).
WSRP Overview
Web Services for Remote Portlets (WSRP) is a standard that defines how one portal
will communicate with another to display a remote portlet. The standard is
language-independent, but it was codeveloped with the JSR 168 Java portlet
API. Other languages and environments can also use WSRP. This standard is
useful for interoperability, because portlets written in .NET can appear in a
Java-based portal, and vice versa. OASIS (Organization for the Advancement of
Structured Information Standards) developed the WSRP specification, and if you
are interested in reading the specification, see the WSRP committee home page

(
www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp
).
2840ch12.qxd 7/13/04 12:44 PM Page 295
Download at Boykma.Com
Chapter 12
296
Most of the WSRP specification is aimed at software developers who are writ-
ing WSRP infrastructure for portal servers. Most portlet developers will not need
to know how to call WSRP web services directly—the portlet container will han-
dle all of their portlet application’s interaction with WSRP.
WSRP solves an application syndication problem. If one portal serves a portlet
application, other portals can display the portlet application as if it were running
locally. This puts the burden of hosting the portlet application on one group; oth-
ers can use the portlet application on their servers without being responsible for
ongoing maintenance. This is especially useful if one group has many more tech-
nical resources than other groups.
One example of application syndication is if the producer of a product is
responsible for creating sales tools for the web sites of partners who sell the
product. For instance, an auto manufacturer can create a configuration engine
for its product line to enable users to pick valid choices for colors, engines, and
other options. The manufacturer may invest a million dollars in this project, so
it is not feasible for small auto dealers to replicate the work. Instead, the dealers
can license the configuration engine from the manufacturer for use on their web
sites. If the configuration engine is installed on several thousand dealer web sites,
the auto manufacturer’s technical support costs will be huge.
Architecture
WSRP builds on existing standards, such as SOAP (Simple Object Access Protocol)
and WSDL (Web Service Definition Language). With WSRP, consumer portals will
aggregate portlets from local and remote sources and provide them to the user’s

web browser as a portal web page. Producer portals publish portlet applications
as web services that consumers can access.
We can include any WSRP-compatible portlet in any WSRP-compatible con-
sumer, independent of the content, user information model, or preferences model.
WSRP portlets are presentation-oriented, not data-oriented like other web services.
We don’t have to create a portlet that calls data-oriented web services and assem-
bles the results into content; instead, the WSRP architecture allows the portlet
markup to come from a web service directly. No business logic resides on the
consumer portal. Figure 12-1 shows a typical application architecture for a WSRP
deployment.
2840ch12.qxd 7/13/04 12:44 PM Page 296
Download at Boykma.Com
Web Services for Remote Portlets (WSRP) and Application Syndication
297
Local Portlet (JSR 168)
Local Portlet (JSR 168)
Portlet A (WSRP)
Portlet C (WSRP)
Portlet E (WSRP)
User's Web
Browser
WSRP
Consumer
Portal
WSRP
Producer
Portals
SOAP/
WSRP
Producer 2

Producer 1
Portlet B
Portlet C
Portlet D
Portlet E
Portlet A
HTTP
Figure 12-1. Typical WSRP architecture, with two producers and one consumer
The WSRP model should open enterprise architectures to a new range of
applications for portals because all portal applications will share a common
presentation model. This is important for organizations that have invested in
J2EE and .NET environments because portlets running in either display in
a consumer portal with WSRP.
Producers
Producers offer portlets to consumers as web services, using SOAP. The WSRP
specification defines four web services for producers:
• Service Description: Offers information and metadata about the producer
to consumers. This service is required.
• Markup: Provides content markup fragments for portlets, and processes
interaction requests. This service is required.
• Registration: Allows consumers to register their information and metadata
with the producer, including their capabilities. This service is optional.
• Portlet Management: Configures and customizes offered portlets for use
by the consumer. This service is optional.
The producer must implement the Service Description and Markup web ser-
vices, and may optionally implement the Registration and Portlet Management
web services.
2840ch12.qxd 7/13/04 12:44 PM Page 297
Download at Boykma.Com
Chapter 12

298
The producer does not have to be a portal that allows direct user access. For
instance, a large company could have a sales portlet application hosted on a server
cluster in a central location. The server cluster would be behind a network firewall
that allows traffic and access (using WSRP) only from consumer portals run by its
customers. The portlet’s user accesses the consumer portals and is unaware that
the portlet runs on a separate server. This environment has a deployment cost
advantage over a solution that requires the portlet application on each consumer
portal. Any upgrades for the portlet application are automatic, and the consumer
portal administrators do not have to worry about the portlet application details.
Consumers
Consumers call producers to discover portlets, ask for portlet markup, or send
portlet events to the producer for processing. They aggregate the portlet markup
fragments into a portal page, and return that to the end user’s web browser. The
portlet markup fragments can come from WSRP portlets or locally running portlets.
In many cases, the consumer will be a proxy portlet that uses the Java portlet
API to talk to the local portal and uses WSRP/SOAP to communicate with the
producer. Not every consumer will be a portlet or otherwise embedded in a por-
tal. Another scenario is to use the WSRP API to include syndicated applications
in a web application. For instance, the navigation for the web page could be gen-
erated locally, and the remote portlet can be displayed in the content area. The
web application would thus be responsible for much of what a portal does, but
would not display any other portlets.
Portlets
WSRP portlets are components running on the producer that process actions and
return markup or content. The WSRP portlets can conform to the Java portlet API,
or they can be proprietary Java portlets, .NET portlets, or any other language. In
addition, software applications that are not portals can be producers of WSRP
portlets.
WSRP and the Java Portlet API

The first versions of the Java Portlet API (JSR 168) and WSRP share core portlet
concepts, so JSR 168 portlets are compatible with the WSRP standard with no
additional code.
WSRP portlets return markup requests, which correspond to the JSR 168
render-handling requests. WSRP portlets also process interactions, which
2840ch12.qxd 7/13/04 12:44 PM Page 298
Download at Boykma.Com
Web Services for Remote Portlets (WSRP) and Application Syndication
299
correspond to JSR 168 action-handling requests. WSRP supports JSR 168 portlet
preferences. The consumer portal information maps to the Java portlet API
PortalContext
object. This information includes supported portlet modes, sup-
ported window states, portal properties, vendor name, and version.
WSRP supports the standard JSR 168 VIEW, EDIT, and HELP portlet modes. The
WSRP specification also defines the custom PREVIEW portlet mode for portlets to
provide a sample or demo of how they will appear. WSRP supports custom portlet
modes.
All of the standard JSR 168 window states are valid WSRP window states (normal,
minimized, maximized). In addition, WSRP supports the solo window state for
portlets that are the only portlet displaying in a portal page. WSRP also supports
custom window states.
WSRP Markup in Content Fragments
The rules for WSRP markup in content fragments are largely the same as markup
for Java portlets. One difference is that either the producer or the consumer may
do markup encoding and processing for namespaces and portlet URLs.
Namespace Encoding
Namespaces must be encoded in markup for JavaScript and Dynamic HTML
(DHTML), so two instances of a portlet running on the same page have unique
element names. One difference is that namespaces may be encoded by the producer

or by the consumer—Java portlets that use namespace encoding will use producer
encoding. If you would like to use consumer encoding, any elements in the markup
that need a unique namespace should start with the prefix “wsrp_rewrite_”. Then
the WSRP consumer is responsible for ensuring that the namespace is unique.
Character Encoding
The consumer and the portlet have to agree on a character encoding for the port-
let’s content fragment. The consumer tells the portlet which character encoding
it would like to use, and the portlet should use that character encoding if possible.
If your portlet cannot support the requested character encoding, the portlet may
use either UTF-8 or UTF-16 encoding.
Consider your portlet’s ability to generate different character sets if your portlet
will have an international audience that uses different character encodings.
2840ch12.qxd 7/13/04 12:44 PM Page 299
Download at Boykma.Com