Summary: There are various content delivery options available in IBM Lotus® Web Content Management™ (hereafter called “Web Content Management”), and choosing the one that's right for you can improve the current performance and future scalability of your deployed environment. This article explains the available rendering options and how to choose the best one for your Web sites.
Pankaj H. Patel
Staff Software Engineer
IBM Software Group
Pune, MA, India
December 2009
Table of Contents
1 Basics of content delivery options
2 Usage scenarios
2.1 Local rendering portlet (LRP)
2.2 Remote rendering portlet
2.3 Pre-rendering
2.4 Servlet rendering
3 Conclusion
4 Resources
5 About the author
1 Basics of content delivery options
Web Content Management content can be delivered to users in several ways, including rendering portlets, a specialized servlet, and pre-rendered sites. Specifically, content can be delivered through:
- A local rendering portlet using the local IBM WebSphere Portal server.
- A remote rendering portlet located on a separate WebSphere Portal server.
- A pre-rendered site using the local Web server.
- The Web Content Management servlet.
By considering your existing environment and future needs, you can determine the most appropriate content delivery option. Figure 1 shows the typical rendering scenario in Web Content Management.
Figure 1. Schematic of a typical delivery environment ( Attached )
As the figure shows, Web Content Management content can be delivered via the following:
- Local rendering portlet (Web Content Viewer), which is located on the same server as a Web Content Management application.
- Remote rendering portlet (Remote Web Content Viewer), which is located on a remote WebSphere Portal server. A Web Content Management application is not required on a remote WebSphere Portal server.
- Pre-rendered sites, a standard Web site.
- Web Content Management servlet, a standard Web Site via the Web Content Management servlet that is installed with the Web Content Management application.
2 Usage scenarios
Let's discuss when to use, and when not to use, the various scenarios for content delivery.
2.1 Local rendering portlet (LRP)
When to use: If a Web site has a high volume of requests, you should use the LRP, which requires less network activity and can give you much better performance compared to remote rendering portlet (RRP).
When to avoid using: Moderate usage contents can be delivered via RRP and can reduce the number of licences required.
2.2 Remote rendering portlet
When to use: An RRP portlet should be considered when there is less volume of requests for the portlet's contents.
- RRP requires fewer Web Content Management licences, so for moderate usage contents, we can separate them out and deliver by RRP.
- If the Web Content Management server is behind a firewall and you want to deliver content, you should user RRP, which can be configured if redirection is set up and the fully qualified URL is disabled.
- RRP is preferred if you want to reduce the CPU load on the Web Content Management rendering server. (LRP can generate high CPU load on the Web Content Management server.)
- When you use RRP on a remote server and you need to upgrade, it is not necessary to upgrade the remote WebSphere Portal server. You can upgrade the Web Content Management server only, and content can be delivered by use of RRP.
Also, note the following:
- Administration and configuration of a RRP is more complex compared to a LRP.
- You can use the API with RRP; however, make sure that JSP is on the Web Content Management servers when the request goes in.
When to avoid using: RRP should not be used to communicate to a local Web Content Management server. The RRP uses a URL connection to communicate with the Web Content Management server, and using it to talk to a local server causes an extra request thread being needed to service the original request.
Under heavy loads, if all request threads are being used to serve “incoming” requests to the portlet, then the server will hang because each incoming request to the portlet cannot establish a “backend” request to Web Content Management. The network delay can cause performance issues with the RRP portlet.
2.3 Pre-rendering
Suppose you have a Web Content Management Web site that is generated by the connect servlet (in other words, you do not use portlets to present content), and that you view and locally store every page of your site. Each page view will generate a single HTML page, so you now have a copy of the entire Web site locally.
The problem here is that all links on all pages will always refer back to the original site. If you then rewrite all the links so that they link to other locally stored pages (and do the same for images and files), then you'll end up with your entire Web Content Management site as a set of interlinked static Web pages.
If you place these on a standard HTTP server, then there you have it: A pre-rendered Web site. That is what the prerender does for you: It generates a static Web site as a set of HTML pages. Users requesting a page will get the pre-generated HTML page rather than a dynamic page from the Web Content Management connect servlet.
Web Content Management Caching, Servlet Caching (DynaCache), and pre-rendering are used to improve the performance of Workplace Web Content Management Web sites.
Although pre-rendering is the fastest option, its various limitations mean that most users will choose Web Content Management Caching or Servlet Caching over pre-rendering.
When to use: If the Web site is not personalized and is never going to be personalized, then you can use pre-renderering.
This option is appropriate when you are accessing the pre-rendered site through Web Content Management. It increases performance because static content is accessed from the pre-rendered site, but dynamic content will still be rendered through Web Content Management.
When to avoid: You can pre-render a complete Web Content Management site into HTML and save it to disk. The pre-rendered site can then be used as the live site and displayed to end users by use of either Web Content Management or a Web server.
However, if your project is subject to the limitations described in section 2.3.1 below, then you should consider them before using pre-rendering. Also, note the following:
- Pre-rendering a large site takes a long time, and authoring users may experience delays until the pre-rendering process is completed.
- The entire site should be pre-rendered; if it's not, then you may get broken links within the site.
- The pre-rendering feature cannot be used to pre-render JSP components.
- The Page navigation component cannot be used in pre-rendered sites.
- Document Manager elements can only be pre-rendering if the document library from which the document is referenced has anonymous access.
- Personalization elements can only be pre-rendered if the personalization rule is configured for anonymous access.
2.3.1 Limitations
- Site security. Item security for read access for different users set in a Web Content Management environment is not transferred to pre-rendered sites. The security for the entire pre-rendered site is based on the connect.moduleconfig.cacher.rendereruser property as set in the pre-rendering configuration of the WCMConfigService.properties file.
- Restrictions:
- Sites, site areas, and content items cannot contain characters that are considered invalid in file names by the operating system on which you are pre-rendering. For example, on a machine running Microsoft® Windows®, these characters are invalid: / \ : * ? " < > |.
- The path to the content item, including the directory path to which you are pre-rendering (for example, site/site area/content), cannot exceed the operating system's maximum path length:
255 characters in Windows
1024 characters in Linux®
2.4 Servlet rendering
Users can access content displayed via the Web Content Management servlet by connecting to a URL as follows:
http://[HOST]:[PORT]/wps/wcm/connect/[PATH]?srv=
where:
- [PATH] can be the path to a site, site area, or content item but must include a library. This must be entered for all types of content, including components. In the case of components, this is the path to the site, site area, or content item with which the component is displayed.
and
- srv= is either "cmpnt" or "page". Note that srv=cmpnt retrieves a component either from the component library or from a site, site area, or content item.
You must also specify the following:
source= . This determines from where the component is being sourced--either from site, sitearea, or content.
cmpntname=[componentname]. This is the name of the component being retrieved.
srv=page. This retrieves a Web Content Management content item; since srv=page is returned as default, this can be left out of the URL.
The presentation template to use when displaying this content is specified by adding the following:
presentationtemplate=[presentationtemplatename]
This is the name of the presentation template being retrieved.
2.4.1 Examples
1. URL to a library component:
http://[HOST]:[PORT]/wps/wcm/connect/[PATH]?srv=cmpnt&source=library&cmpntname=component
For example:
http://host:10038/wps/wcm/connect/[library]/[site]/[sitearea]/[content]?srv=cmpnt&source=library&cmpntname=[component]
(2) URL to a content component:
http://[HOST]:[PORT]/wps/wcm/connect/[PATH]
?srv=cmpnt&source=content&cmpntname=[componentname]
For example:
http://host:10038/wps/wcm/connect/[library]/[site]/[sitearea]/[content]?srv=cmpnt&source=content&cmpntname=[component]
(3) URL to content:
http://[HOST]:[PORT]/wps/wcm/connect/[PATH]
For example:
http://host:10038/wps/wcm/connect/[library]/[site]/[sitearea]/[content]
(4) URL to content with a presentation template defined:
http://[HOST]:[PORT]/wps/wcm/connect/[PATH]
?presentationtemplate=[presentationtemplatename]
For example:
http://host:10038/wps/wcm/connect/[library]/[site]/[sitearea]/[content]?presentationtemplate=[presentationtemplate]
(5) Applying Custom Caching and expiring parameters:
http://[HOST]:[PORT]/wps/wcm/connect/[PATH]?CACHE=SITE&EXPIRES=REL+8000s
When to use servlet rendering. A Web Content Management servlet is good for creating simpler Web sites for which you don’t need out-of-the-box functionality provided by WebSphere Portal server.
In example (5) above, the content being retrieved via the URL will be saved in the Basic Site Cache and will expire after 8000 seconds, so this remote caching option may help to offload CPU-intensive rendering loads to the backend Web Content Management server.
When to avoid. When you create a Web site with servlet rendering, the page design defines the overall look of the Web page, whereas in WebSphere Portal it defines the look for a single Web Content Management portlet.
Also, there are additional parameters available in Web Content Management portlets that help to create site easily; these features aren’t available with servlet rendering.
3 Conclusion
You should now have a good understanding of the available options for rendering a Web Content Management Web site and the best practices for implementing rendering for your Web sites.
4 Resources
- developerWorks WebSphere Portal zone:
http://www.ibm.com/developerworks/websphere/zones/portal/
- WebSphere Portal and Lotus Web Content Management product documentation:
http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html
- wiki article, “Local and remote rendering with Web Content Management”:
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/local-and-remote-rendering-with-web-content-management
- wiki article, “Web Content Management JSR 286 portlet - Tips, Issues and limitations”:
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/wcm-jsr-286-portlet-tips-issues-and-limitations
5 About the author
Pankaj Patel is a Staff Software Engineer working with the Websphere Portal and Web Content Management Support team at IBM's Pune, India, facility. He holds a Bachelor's degree in Information Technology and is currently pursuing his MBA in International Business. He is also an IBM Websphere Portal, Web Content management and Sun certified solution developer. He has extensive experience in Portal and related technologies and worked as J2EE developer utilizing IBM rational tools & technologies before joining IBM in 2005. You can reach him at panpatel@in.ibm.com