In Lotus Web Content Management V7.0 you can use the JSR 286 Web Content Viewer Portlet (aka WCM rendering portlet) for rendering content that is hosted in the Web Content Management repository. You can also address the WCM rendering portlet via the Web Service for Remote Portlets (WSRP) standard and thus integrate the content hosted on a remote web content repository. See http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Performing_remote_rendering_with_WSRP_and_the_JSR_286_web_content_viewer_wcm7
for how to set this up and the limitations when doing remote rendering.
The default assumption should be that web content rendering is done locally. In most cases web content is an integral part of the web site, like the portal pages and therefore it does not make sense to have the web content remote. In most cases you also want to have the access control set consistently for the portal pages and the web content, which would require additional work in the remote case.
Lotus Web Content Management and WebSphere Portal 7.0 also allow you a tight integration between the portal pages and the content being rendered by mapping pages to WCM site areas and exposing the current selected content item as part of the friendly URL path. All those benefits would be lost when using remote rendering. It also will make it much harder to leverage site analytics features that would otherwise work out of the box for local rendering.
Another consideration to keep in mind is that the convergence between WCM and WebSphere Portal will continue in future releases and add additional features which likely will only be available in the locale rendering scenario.
In general there are several reasons why one would want to have an application being remote:
- off-load CPU intensive applications
- off-load memory intensive applications
- provide a sandbox for applications that are not thoroughly tested by IT infrastructure
- the application is not maintained by IT infrastructure, but another party in the organization or outside the organization
- a SOA infrastructure that has the applications and its content hosted in different parts of the organization
For WCM rendering reasons 1.-4. do not apply as the rendering portlet is part of the product and neither CPU nor memory intensive. Thus the major use is a site that has very little web content on its pages and is mainly driven by other applications rendered on the page. For those scenarios it may make sense to manage the WCM environment separate from the portal environment. This may also result in lower license costs for WCM, but has other infrastructure costs due to the added complexity of managing the remote scenario and the need for more hardware, as the remote calls add additional overhead.
Also note that WSRP is really a protocol to embed remote running applications and not well suited for rendering complete pages remotely. It therefore has no support for any aggregation concept, like links to other pages or other resources outside of WCM.
for a description of remote vs. local rendering for versions before 7.0 that still mostly applies to the 7.0 version when replacing the remote rendering portlet with the WSRP consumer portlet that connects to the JSR 286 rendering portlet on the remote content server.
One line summary:
Only use remote rendering after careful consideration of all the limitations and implications, if in doubt use local rendering.