Inside WSRP

by Subbu Allamaraju


WebLogic Portal 8.1 lets portals consume remote portlets by using the Web Services for Remote Portlets (WSRP) protocol. In most cases, portlets originally built and deployed for use by local portals will function the same when you move those portlets to remote WSRP Producers. WebLogic Portal and its WSRP Consumer and WSRP Producer capabilities are designed to shield portlets from the location of the portal. However in some cases, you may find that certain portlets behave differently or incorrectly. The most common cause of such behavior is implicit or explicit assumptions such portlets might have made about the location of the portal. In this article, I discuss some of the most common assumptions, and why such assumptions can interfere with the WSRP protocol in undesirable ways. My goal is to highlight best practices that you can employ to make portlets WSRP-friendly without necessarily compromising functionality.


Web Services for Remote Portlets (WSRP) lets you decouple your portlet applications from portals. This decoupling can offer significant benefits for managing large portal deployments. Instead of bundling all your portlets with the portal in a single application, you can choose to deploy your portlets in individual portlet applications, and let the portal consume those portlets using WSRP. For most large portal development projects, this decoupling eases team development, upgrades, and administration.

What is WSRP? The best way to understand WSRP is to compare it with, let's say, HTTP. The most typical application of HTTP is viewing and interacting with remote UI (for example, web applications) via web browsers. Using HTTP, browsers can talk to remote HTTP servers to get markup (for example, HTML), and post data (for example, by submitting a form). WSRP is a similar protocol between two applications, one application (the Consumer) acting as a client of another application (the Producer) for getting UI markup and submitting user actions. The Producer hosts the UI, and Consumers use the WSRP protocol to aggregate the UI and to interact with it.

Unlike browsers, Consumers are more sophisticated in the following sense:

  • Consumers can aggregate several UI components into a single page, and they offer features like personalization, customization, and security.
  • Consumers deal with markup fragments, not complete documents. Consumers get these markup fragments from different Producers and combine them into a single page by applying Consumer-specific page layouts, styles, and so on.

The WSRP protocol defines a set of web services that WSRP Producers implement. WSRP Consumers can send messages to these web services to view and interact with the UI. The WSRP protocol translates the typical browser-server interaction protocol into a protocol that is suitable for applications (Consumers) to act as clients for applications (Producers) that host the UI.

An important point to realize is that WSRP web services are synchronous and UI-oriented. Unlike business logic-oriented or data-oriented web services, UI-oriented web services offer a more coarse-grained application reuse and are more resilient to change.

WebLogic Portal includes both the Producer and Consumer components. WebLogic Portal Producer is a container that can host portlets. This is where your application code (Page Flows, backing files, other portlet classes, controls, EJBs, and so on), user interfaces (JSPs and other resources), and data used by your portlets reside. The Producer is designed such that you can convert any existing web application into a WSRP Producer with minimal changes at deployment time. Once a web application is enabled as a Producer, it can start to offer portlets available in the web application via WSRP interfaces.

In WebLogic Portal, the Consumer is tightly integrated into the WebLogic Portal framework. To consume a remote portlet, the user typically starts with the location of the WSDL of the Producer, adds the Producer metadata to the Consumer, and then creates a remote portlet (also known as a proxy portlet).  When such a portlet is added to a portal or a desktop, WebLogic Portal framework uses the WSRP protocol to present the portlet to portal users. 

Before proceeding further, you'll need to familiarize yourself with creating portlets and consuming those portlets using WebLogic Portal. The rest of the article assumes such familiarity.

An Example

To illustrate how a WSRP Consumer can interact with remote portlets, let's start with a simple Page Flow portlet.

A Search Page Flow
Figure 1. A search Page Flow

This Page Flow collects user input in a form, performs a search based on the user input, and displays search results. Here is the form presented by the index.jsp page.

<netui:form action="search" method="post">


  <tr valign="top">

   <td>First Name:</td>

   <td><netui:textBox dataSource="{actionForm.firstName}" /></td>


  <tr valign="top">

   <td>Last Name:</td>

   <td><netui:textBox dataSource="{actionForm.lastName}" /></td>



 <netui:button value="search" type="submit" />


Let's assume that you created this Page Flow at /Search/SearchController.jpf in the Producer web application, and created a .portlet file for this Page Flow using WebLogic Workshop. Here is the sample portlet file:

<portal:root xmlns:netuix=""




  " portal-support-1_0_0.xsd">

  <netuix:portlet definitionLabel="search" title="Search">






      <netuix:pageflowContent contentUri="/Search/SearchController.jpf"/>




For the rest of this article, I will assume that you have created a Consumer portal web application, created a remote portlet for the above search portlet, and added it to a portal or a desktop.


After creating the remote portlet, you can change its attributes like caching, definitionLabel, title, error page, and so on. You can also add a backing file to remote portlets on the Consumer side.

Pages: 1, 2, 3, 4, 5

Next Page »