+

Search Tips   |   Advanced Search

Web content system overview


Web content system types


Environment types


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.
Related

Dual-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...


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 WCM


Web content system overview


Web content system types


Environment types


Parent: Web Content Manager environments


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.


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 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:


Parent: Web Content Manager environments


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...


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