When To Use WSRP

Through a recent customer engagement, it's come to light the it is not clear when to use WSRP and when not to use WSRP. This entry will list the reasons for using WSRP in Portal design.

First, "WSRP" stands for "Web Service Remote Portlets". Is short, it is a technique to have a portlet generate it's HTML in one place and render in another. The specification is covered by standards. The WSRP "consumer" resides on the Portal that end users GET content from. The WSRP "producer" can reside on a remote Portal or a remote WebSphere Application Server. The "consumer" makes requests the "producer" for content. The "producer" produces that content. The "consumer" takes what the "producer" produces, formats it for the user and renders the HTML for the Portal page aggregator. The WSRP "consumer" only serves as a proxy for the "producer".

The valid reason for using the WSRP pattern include:

1. Delegation. It could be that the owner of the portlet data is distinct from the owner of the Portal that renders that data. The owner of the data wishes to control the rendering of that data. Therefore, the owner renders HTML for the portlet request on a Portal/AppServer under his control and the WSRP consumer fetches that HTML remotely.

A pattern that is closely related to this is the delivery of data to the target portlet/Portal via web services calls. The consumer is not WSRP, but a standard JSR286 portlet that renders data to the client browser by making a web service call to a service. The portlet simply makes the request for the data, formats it appropriately and then renders that data to the client. This pattern is endorsed positively as well.

The difference between these two patterns is that the WSRP producer also want to control the formatting of the data; not just the gathering of the data.

2. Quality Assurance: Because a badly behaving portlet can bring down an entire Portal, some Portal user's have a policy of running portlet in WSRP mode for a period of time before "promoting" that portlet to the main Portal.

Given the right reasons for using WSRP, what are some of the wrong reasons.

1. Tolerance of the "Uber Portlet". There are folks that have portlets that take considerable CPU time and have a lot of embedded state in those portlets. Think of a servlet with many pages (states) that has been blindly rewritten as a portlet. Then, because it needs a lot of horsepower and the writers have not invested time to make this converted servlet run efficiently and scalable in a Portal context it is decided to run this uber-portlet in WSRP to dedicate a whole machine to running it.

2. Tolerance of long render times. WSRP has a built-in time-out facility to keep the consumer from waiting too long for the producer. WSRP is used to avoid rewriting the producer of the HTML to always generate the result(s) in a reasonable amount of time. This pattern should not be used. Rewrite the producer so that the generation of results is predictable and stable.