Web content system overview
Web content system types
- Single environment systems
- Authoring and delivery occurs within a single environment. Can be resource intensive. Use clustered servers to distribute load.
![]()
- Dual environment systems
- Authoring and delivery are split into different environments. Reduces the load on both authoring and delivery and also allows us to locate the authoring environment behind a firewall. This type of system would be used when delivering externally facing websites, or where you have many users authoring content or many users viewing a website.
![]()
- Staged systems
- Added between the authoring and delivery environments. The staging environment can be used for user acceptance testing (UAT) or to allow to accumulate changes from your authoring environment before syndicating the changes to your delivery environment in a single batch. Deployed when delivering large, complex sites with many content creators and you need to ensure that the website being delivered is accurate, error-free and can perform under load.
![]()
Environment types
- Authoring environment
- Create and manage web content. Used by the content creators and website designers. An authoring system can consist of:
- an authoring server or cluster.
- Individual UAT servers where site and content updates can be tested before being syndicated to the delivery environment.
- Staging environment
- A staging environment can consist of:
- Individual holding servers where changes from the authoring environment can be accumulated before syndicating the changes to the delivery environment in a single batch. Pairs of holding servers can be used to provide you with built-in redundancy.
- Complete replica of the delivery environment where UAT can occur to both review site and content updates, and to test the performance of the delivery environment.
- Delivery environment
- Used by the website viewers. A delivery environment can consist of:
- Pre-rendered sites delivering static content.
- WebSphere Portal server or cluster using servlets to delivery dynamic content, with no portal content or applications.
- WebSphere Portal server or cluster using local or remote web content viewer portlets to deliver dynamic content along with portlets or applications.
- A combination of the previous three.
Web content authoring environments
An authoring environment is used to create and manage web content and is used by the content creators and website designers. Most Web Content Manager sites need to support many content creators. A clustered server solution is the best solution for this scenario.
Standard authoring environment
A standard authoring environment consists of a single authoring cluster that syndicates directly to either a staging or delivery environment. The authoring environment may be used to create drafts, approve drafts, test changes, publish changes, and syndicate to the delivery environment.
For example:
![]()
Authoring environment with testing
We can add a test environment to the authoring environment to enable you to perform user acceptance testing on the content management system and website. We can create drafts, approve changes, test changes, and syndicate to staging from the authoring environment. In the Site UAT environment, we can publish the changes, have the system test the changes, and syndicate to the authoring environment. From the authoring environment, we can syndicate to the delivery environment.
For example:
![]()
Decentralized authoring environments
If content creators are located at different locations, or you have different groups of content creators, consider deploying has a set of decentralized authoring clusters. This scenario works best if the decentralized content creators work with separate content stored in different content libraries.
For example, if you have users located in different locations, it may be more efficient to install a local authoring environment at each location. Two-way syndication is used between all authoring environments with a centralized authoring environment to allow changes made at all remote locations to be visible to all users.
![]()
Decentralized authoring creates the risk of conflicting updates between authoring environments. To reduce the risk of conflicts, we can allocate different sites, or different sections of a site, to each authoring environment. We can also use different authoring environments for different user roles.
For example, Content creators could use a different authoring environment than presentation template designers.
Access to each decentralized authoring environment is controlled using a combination of authoring portlet access controls and item security settings.
For example, Only users requiring access to the local authoring environment would be granted access to the local authoring portlet. Users would be given "Read" access to all items, but only "Edit" access to items they are required to update.
RelatedDual-server configuration for WCM
Web content testing environments
This environment is used by the testers and can be as simple as an individual server where site and content updates can be tested before being syndicated to the delivery environment, or as complex as complete replica of the delivery environment where testing can occur to both review site and content updates, and to test the performance of the delivery environment. It can also be used to accumulate changes from the authoring environment before syndicating the changes to the delivery environment in a single batch.
Site testing within an authoring environment
When testing within an authoring environment a testing server is paired with an authoring server. The testing server simulates the delivery environment and is used to test major changes to a website. We can add a testing environment to the authoring environment to enable user acceptance testing to be performed on the content management system and the website:
![]()
System testing within a staging environment
When testing within a staging environment, data from the authoring environment is syndicated to a staging server where user acceptance testing is performed. If all tests are passed, data is then syndicated from the staging server to the delivery environment. We can perform system testing on a replica of the delivery environment before syndicating your changes to the live delivery environment:
![]()
Web content delivery environments
A delivery environment is used to deliver content to the website viewers.
Pre-rendered delivery
We can pre-render a complete website into HTML and save it to disk. The pre-rendered site can then be used as the live site and displayed to users using either Web Content Manager or a web server. You deploy a pre-rendered site when we are not using any WebSphere Portal features, such as portlets, and the content is static and is only updated periodically.
In a pre-rendered delivery environment, content is syndicated from the authoring server to the delivery server. The content is converted into has a set of static HTML files, which are then displayed to users through a web server.
![]()
To extract a rendered site in html format for offline viewing, we can try using something like Apache Nutch or Kapow. A free method is to use...
wget -k -m -np
Servlet delivery
Users can access content displayed using the Web Content Manager servlet. A servlet delivered website is used when you do not need to use any portlet-based features such as authoring tools.
In a servlet delivery environment, content is syndicated from the authoring server to the delivery server. The content is displayed by the Web Content Manager servlet and made available to users through a web server.
![]()
Local web content viewer delivery
Web content viewers are portlets that display content from a web content library as part of a portal page. If the presentation is simple, a single web content viewer can be sufficient, but we can also use multiple web content viewers to aggregate content from different libraries and provide a richer experience for the users. A local web content view portlet is used to display content within the web content delivery environment.
In a delivery environment using a local web content viewer, content is syndicated from the authoring server to the delivery server. It is displayed to users through a web content viewer portlet in a portal. When a local web content viewer is used, the web content viewer is installed on the same server as Web Content Manager.
![]()
Remote web content viewer delivery
WSRP support in the web content viewer is used to display content on a remote WebSphere Portal server or cluster.
In a delivery environment using a remote web content viewer, content is syndicated from the authoring server to a Web Content Manager server in the delivery environment. The web content viewer is installed on the Web Content Manager server. It is configured to communicate with the WSRP proxy portlet installed on another portal server in the delivery environment. Users view web content by accessing the proxy portlet on the remote portal server, typically through a web server.
![]()
Related:
Dual-server configuration for WCMWeb content system overview
Web content system types
- Single environment systems
- Authoring and delivery occur within a single environment. Deployed by a small organization delivering a small website, such as an intranet. Authoring and delivering content within the same environment can be resource intensive, so the type of environment you deploy needs to be robust enough to allow authoring and delivery to occur at the same time. For example, using clustered servers is a common solution for a single instance system.
![]()
- Dual environment systems
- Authoring and delivery are split into different environments. Reduces the load on both authoring and delivery and also allows us to locate the authoring environment behind a firewall. This type of system would be used when delivering externally facing websites, or where you have many users authoring content or many users viewing a website.
![]()
- Staged systems
- Added between the authoring and delivery environments. The staging environment can be used for user acceptance testing (UAT) or to allow to accumulate changes from your authoring environment before syndicating the changes to your delivery environment in a single batch. Deployed when delivering large, complex sites with many content creators and you need to ensure that the website being delivered is accurate, error-free and can perform under load.
![]()
Environment types
- Authoring environment
- Create and manage web content. Used by the content creators and website designers. An authoring system can consist of:
- an authoring server or cluster.
- Individual UAT servers where site and content updates can be tested before being syndicated to the delivery environment.
- Staging environment
- A staging environment can consist of:
- Individual holding servers where changes from the authoring environment can be accumulated before syndicating the changes to the delivery environment in a single batch. Pairs of holding servers can be used to provide you with built-in redundancy.
- Complete replica of the delivery environment where UAT can occur to both review site and content updates, and to test the performance of the delivery environment.
- Delivery environment
- Used by the website viewers. A delivery environment can consist of:
- Pre-rendered sites where a web content site is pre-rendered as has a set of HTML files which are then used to deliver a static website.
- WebSphere Portal server or cluster where content is delivered using a servlet. Servlet delivery is used to deliver websites containing dynamic content, but do not include any WebSphere Portal content or applications.
- WebSphere Portal server or cluster where content is delivered using either a local or remote web content viewer portlet. web content viewer portlets are used to deliver websites containing dynamic web content alongside other portlets or applications.
- A combination of the previous three.
Parent: Web Content Manager environmentsWeb content authoring environments
An authoring environment is used to create and manage web content and is used by the content creators and website designers.
Server type
Most Web Content Manager sites need to support many content creators. A clustered server solution is the best solution for this scenario.
Standard authoring environment
A standard authoring environment consists of a single authoring cluster that syndicates directly to either a staging or delivery environment. The authoring environment may be used to create drafts, approve drafts, test changes, publish changes, and syndicate to the delivery environment.
For example:
![]()
Authoring environment with testing
We can add a test environment to the authoring environment to enable you to perform user acceptance testing on the content management system and website. We can create drafts, approve changes, test changes, and syndicate to staging from the authoring environment. In the Site UAT environment, we can publish the changes, have the system test the changes, and syndicate to the authoring environment. From the authoring environment, we can syndicate to the delivery environment.
For example:
![]()
Decentralized authoring environments
If your content creators are located at different locations, or you have different groups of content creators, we might consider deploying has a set of decentralized authoring clusters. This scenario works best if the decentralized content creators work with separate content stored in different content libraries.For example, if you have users located in different locations, it may be more efficient to install a local authoring environment at each location. Two-way syndication is used between all authoring environments with a centralized authoring environment to allow changes made at all remote locations to be visible to all users.
![]()
Decentralized authoring creates the risk of conflicting updates between authoring environments. To reduce the risk of conflicts, we can allocate different sites, or different sections of a site, to each authoring environment. We can also use different authoring environments for different user roles.
For example, Content creators could use a different authoring environment than presentation template designers.
Access to each decentralized authoring environment is controlled using a combination of authoring portlet access controls and item security settings.
For example, Only users requiring access to the local authoring environment would be granted access to the local authoring portlet. Users would be given "Read" access to all items, but only "Edit" access to items they are required to update.
Parent: Web Content Manager environments
Related:
Dual-server configuration for WCMWeb content testing environments
This environment is used by the testers and can be as simple as an individual server where site and content updates can be tested before being syndicated to the delivery environment, or as complex as complete replica of the delivery environment where testing can occur to both review site and content updates, and to test the performance of the delivery environment. It can also be used to accumulate changes from the authoring environment before syndicating the changes to the delivery environment in a single batch.
Site testing within an authoring environment
When testing within an authoring environment a testing server is paired with an authoring server. The testing server simulates the delivery environment and is used to test major changes to a website. We can add a testing environment to the authoring environment to enable user acceptance testing to be performed on the content management system and the website:
![]()
System testing within a staging environment
When testing within a staging environment, data from the authoring environment is syndicated to a staging server where user acceptance testing is performed. If all tests are passed, data is then syndicated from the staging server to the delivery environment. We can perform system testing on a replica of the delivery environment before syndicating your changes to the live delivery environment:
![]()
Parent: Web Content Manager environmentsWeb content delivery environments
A delivery environment is used to deliver content to the website viewers.
Pre-rendered delivery
We can pre-render a complete website into HTML and save it to disk. The pre-rendered site can then be used as the live site and displayed to users using either Web Content Manager or a web server. You deploy a pre-rendered site when we are not using any WebSphere Portal features, such as portlets, and the content is static and is only updated periodically.
In a pre-rendered delivery environment, content is syndicated from the authoring server to the delivery server. The content is converted into has a set of static HTML files, which are then displayed to users through a web server.
![]()
To extract a rendered site in html format for offline viewing, we can try using something like Apache Nutch or Kapow. A free method is to use...
wget -k -m -np
Servlet delivery
Users can access content displayed using the Web Content Manager servlet. A servlet delivered website is used when you do not need to use any portlet-based features such as authoring tools.
In a servlet delivery environment, content is syndicated from the authoring server to the delivery server. The content is displayed by the Web Content Manager servlet and made available to users through a web server.
![]()
Local web content viewer delivery
Web content viewers are portlets that display content from a web content library as part of a portal page. If the presentation is simple, a single web content viewer can be sufficient, but we can also use multiple web content viewers to aggregate content from different libraries and provide a richer experience for the users. A local web content view portlet is used to display content within the web content delivery environment.
In a delivery environment using a local web content viewer, content is syndicated from the authoring server to the delivery server. It is displayed to users through a web content viewer portlet in a portal. When a local web content viewer is used, the web content viewer is installed on the same server as Web Content Manager.
![]()
Remote web content viewer delivery
WSRP support in the web content viewer is used to display content on a remote WebSphere Portal server or cluster.
In a delivery environment using a remote web content viewer, content is syndicated from the authoring server to a Web Content Manager server in the delivery environment. The web content viewer is installed on the Web Content Manager server. It is configured to communicate with the WSRP proxy portlet installed on another portal server in the delivery environment. Users view web content by accessing the proxy portlet on the remote portal server, typically through a web server.
![]()
Parent: Web Content Manager environments
Related:
Dual-server configuration for WCM