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

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

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

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