WSRP stands for Web Services for Remote Portlets, a handy specification from the folks at OASIS; it provides a standard for portal applications to share portlets between portals. Put another way, WSRP is the ability to produce an interface to useful functionality that can be consumed throughout your enterprise with little or no changes to existing code. Sound familiar?
Almost all of the latest versions of commercial and open source portal products support WSRP, though your mileage may vary based on the vendor. The basic mechanism is the same as any old web service. The producer provides a WSDL that instructs the consumer on how to generate a SOAP request. The difference between web services and WSRP is that with a web service the developers of the consumer application next need to figure out how they will use the SOAP response whereas the WSRP consumer receives a response at the presentation level; all the consumer needs to do is decide where they will display it. The portal frameworks abstract the heavy lifting and all that is required of developers is to configure the producer and consumer to achieve basic WSRP integration. In theory, this simplicity provides all an enterprise needs to reuse portlets across the enterprise “instamagiclly.” In practice, business requirements rarely let us get off the hook so easily. In fact, once an enterprise begins to use WSRP, the requirements tend to get more and more complicated, which is why the WebLogic Portal (WLP) has evolved to provide more and more WSRP functionality with increasing ease of development.
When WSRP Makes Sense
WSRP is a technology that provides three benefits. One is reuse; another is performance, (though oftentimes using WSRP will provide only one of these two benefits); and the third is the ability to release portlets asynchronously.
WSRP is not the only approach to achieving portlet reuse. Portlets can also be bundled into a WAR file and used as a shared library, or simply copied from one application to another. Where reuse is the goal, WSRP is the solution of choice when the portlet is used in more than one portal.
Sometimes, portlets are resource intensive. If a portal page contains a collection of portlets where system or network resources impact the usability of the portal, WSRP can provide a strategy where the processing is divided across servers to improve performance.
Portals provide the ability to aggregate access to applications. In many enterprises, these applications are owned and maintained by disparate groups where the coordination of release schedules can be difficult (if not impossible). Here, WSRP provides the advantage of allowing a portlet or group of portlets to be released independently of the main portal application.
The Best Way to Consume a Remote Portlet
In the WebLogic Portal, portlets are WSRP enabled by default since version 9.2, as shown below:
Figure 1: Default Portlet Properties
In fact, the notation in the .portlet file is required only if you are not offering your portlet as remote, as show by these two code snippets:
<netuix:portlet definitionLabel="simpleProducerA_1"
title="Simple Producer A">
<netuix:portletdefinitionLabel="nonRemoteExample_1"
offerRemote="false"title="Locals Only">
In a WSRP implementation, the remote portal is the producer and the portal displaying the remote portlet is the consumer. The consumer gains access to the producer by registering the producer as a remote producer by accessing the producers WSDL. The WSDL is generated automatically by WLP and available as an address from the producer’s web application in the format of [server_address]/[web_application]/producer?wsdl. The example portal applications referenced in this article are named wsrpConsumer and wsrpProducer, with the portal web applications being named wsrpConsumerWEB and wsrpProducerWEB; this would make the producer’s WSDL address http://localhost:7001/wsrpProducerWEB/producer?wsdl. This WSDL simply defines key details about interacting with the producer, such as security:
<wssp:SecurityToken TokenType="http://docs.oasis-open.org/wss/2004/01/ oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID">
And where to find various services, such as registration:
<s0:port binding="s3:WSRP_v1_Registration_Binding_SOAP"
name="WSRPRegistrationService">
<s4:address location="https://localhost:7002/
wsrpProducerWEB/producer/wsrp-1.0/registration" />
</s0:port>
Although the most basic of WSRP producers require 60+ lines of XML to define the WSDL, even the most complicated WLP applications will generate a WSDL for you. The only hand editing you may need to do is with simpler files such as wsrp-producer-config.xml and wsrp-producer-registry.xml.
Remote portlets are consumed in the producer with a proxy portlet, and WLP provides two ways to create a proxy portlet. One method is through the WebLogic Workshop IDE at design time. Defining a proxy portlet at design time requires providing an address to the producer in a .portlet file; this cannot be changed at runtime. Due to this drawback, this approach is not recommended in this article. If you want to see how it works in detail, you can follow the tutorial included in the WLP documentation.
The other method to define a proxy portlet is through the WLP Portal Administration Tool (PAT). To define proxy portlets in the PAT, you first must create a streaming portal. Streaming portals are database-driven rather than file-based (where users access the portal through a .portal file defined in Workshop). There are many considerations outside of WSRP in choosing between a file-based versus a streaming portal and are beyond the scope of this article.
To quickly illustrate the steps of creating a streaming portal and consuming a WSRP portlet, you will use the naming conventions from your example applications as well as the existing assets in the example. For simplicity, you will have both portal applications deployed to the same domain. With this in mind, here is the process to create a streaming portal and consuming a simple remote portlet:
With the portal server running, navigate to http://localhost:7001/wsrpConsumerAdmin for your consumer portal’s administration console (or, with the Portal perspective open in Workshop, select RunOpen Portal Administration Console) and log in with the admin credentials. From the Portal Management page, create a streaming portal and a desktop based on the .portal file you created in Workshop. In Figure 2, you’ve created a portal named “wsrp” with desktop named “default”.
Figure 2: Streaming Portal Created in Portal Admin Tool
Next, add your producer portal to your library by expanding Library and Remote Producers, and then click the Add Producer button. In the wizard, enter
http://localhost:7001/wsrpProducerWEB/producer?wsdl
and click Search. Click the Remote Producer in the search results, and then follow the self-explanatory prompts to complete registration.
Figure 3: Remote Producer Configuration Wizard
With your remote producer registered, click the producer’s name, and then Selected Portlets to access the Add Portlets button. The Add Portlets button will start a straightforward wizard to add your remote portlets.
Figure 4: Adding Remote Portlets to Consumer
Finally, add the Hello Producer to your Consumer Desktop using the intuitive PAT, which will display as shown in Figure 5 once completed:
Figure 5: Home Page Layout in Portal Admin Tool
In WLP 9.2, the process of placing your remote portlets must be repeated manually for each environment (typically, with varying names and number of environments, Test, Staging, and Production). Beginning in WLP 10.0, WSRP portlets can be included in propagation as other portal configurations are in earlier versions of WSRP (see “Propagating Weblogic 8.x Portals” for an introduction to portal propagation).
If you followed the naming examples in this article, you can browse to http://localhost:7001/wsrpConsumerWEB/appmanager/wsrp/default to see the results.
Figure 6: Federated Portal Desktop with WSRP
Congratulations. You have achieved portal federation with WSRP!
About the Author
Scott Nelson is a Principal Portal Consultant who strives to build portals with an ROI based on profitability, usability, and maintainability.
