Table of Contents
Advertisement
2.5.5 Separation of WCM from Portal Servers
Although WCM is an integrated sub-component of WebSphere Portal Server V6.0.1, for
reasons attributed to performance and scalability, one IBM recommended best practice is that
WCM is externalized in its own instance. This approach allows the primary WebSphere Portal
Server instance, which maybe clustered, to concentrate on performing the core Portal tasks
without WCM resource impact. When WCM is installed in such a manner, you still need to
install an underlying WebSphere Portal Server runtime specifically for WCM. However, such a
WebSphere Portal Server runtime does not participate in the primary Portal Server instance.
Note that this additional WCM Portal Server instance does not participate in the same
WebSphere Cell as the primary WebSphere Portal Server instance. As such, if WCM
clustering is a requirement, it is also necessary to install an additional instance of WebSphere
Network Deployment Manager to overcome this restriction.
Separating the functional aspects of the primary WebSphere Portal Server instance and the
WCM instance allows for loose coupling between components. As such, one immediate
benefit comes about when upgrading either component; there is no interdependency and
each component can be upgraded in isolation. WCM is intended first and foremost as a Web
content management system (Web-CMS). As such, it is primarily designed for creating,
managing, and publishing Web content consisting of text and images. This should not be
confused with the functionality provided by Enterprise Content Management (ECM) solutions.
Deciding to run WCM as an integrated sub-component of Portal Server V6.0.x remains a valid
and supported IBM option. However, care should be taken as this approach may place a
higher demand on processor utilization and the JVM heap.
Unlike previous versions of WebSphere Portal Server, prior to V6.0.x, which ran WCM as an
integrated sub-component, there is no longer the need to create a separate WCM JCR
database repository for each Portal Server cluster member. For a cluster consisting of six
members there is only the need for a single shared JCR repository. As such, storage capacity
requirements are reduced when compared to previous releases.
2.5.6 Separation of Web servers and WebSphere Portal Servers
In most cases, unless the hardware cost is a limiting factor, it is an IBM recommended best
practice to architect the Web server and WebSphere Portal Server on separate physical
nodes. This allows the greatest level of availability and performance. The Web server nodes
may be specifically tuned for static content serving. The major architectural advantage,
however, of such a configuration is that the Web server nodes may be placed within a DMZ,
and the WebSphere plug-in can communicate through the internal firewall to the WebSphere
Portal Server nodes located within another segment of the corporate LAN. Separating the
Web server from the WebSphere Portal Server also reduces any contention between
resource utilization. Potentially, this would allow a dedicated WebSphere Portal Server to
perform without the impact attributed to the co-location of the Web server and vice versa.
However, despite these limitations, co-location remains a valid option in low volume
environments within an architecture for intranet applications requiring Web server facilities
over and above those provided by the embedded Web container. It is not recommended that
the embedded Web container is accessed directly.
Surpassing the saturation imposed by a single Web server is easily and cheaply achieved by
architecting additional Web servers. These nodes are typically commodity based machines
(in comparison to mid and high-end UNIX® servers). Linux is well suited here, although at a
price' AIX also offers the benefit of the Fast Response Cache Accelerator (FRCA) kernel
based caching mechanism.
34
IBM WebSphere Portal V6 Self Help Guide
Advertisement
Table of Contents
Troubleshooting
