When IBM created their new JSR 286-based Web Content portlet they included only a local rendering version. This means you have to have IBM WCM installed on the same server as Portal to render WCM content. In IBM’s previous versions, they shipped both a local rendering and a remote rendering portlet. The remote rendering portlet allowed you to install WCM separately from your production Portal servers, which hopefully improved response time.
Many customers have asked about this new local-only rendering portlet and wondered if IBM chose this path to sell more WCM licenses. In the scenario where you have four production servers, you would need more WCM licenses (4 licenses – one per portal) in a local rendering environment than in a remote rendering environment (1 licenses only).
What IBM didn’t really explain very well in all this is that you can still do remote rendering of WCM content, you just do it a little differently now. Have you heard of WSRP, or Web Services for Remote Portlets? This is an industry standard for delivering content from a remote server to your portal. So if we have one WCM server delivering content to our Portal environment, we should be able to deliver that content remotely using WSRP, right?
Dinesh Ramakrishnan from IBM has recently published a paper on the IBM Portal Wiki explaining just how to set up WSRP for rendering remote content. The title of the page is appropriately: Setting up the rendering Web Content Viewer portlet consumed from remote IBM Web Content Manager V7 using WSRP.
You can still use the new JSR 286 rendering portlet with WSRP to display your remote content. There are still some limitations due to using WSRP, but for the most part, they are minor.
We have a setup using WSRP to render content on pages containing other portlets. We are faced with an issue where the recommendation for WCM (not to use dynamic link broadcasting) means that the other links on the page do not work, and vice versa if dynamic link broadcasting is used. Are you aware of a workaround?
Thanks,
Andre
Sorry, I’m not aware of a workaround. If I find one, I’ll be sure to let you know.
Mark, thanks for your prompt reply. I really hope there is a way to resolve this issue, I cannot imagine that we are the only people trying to do this.