Publisher Fault Tolerance – Part 1 | Function1 - WebCenter Interaction and enterprise portal services

Publisher is one of the most critical infrastructure pieces of the ALUI portal, since it provides some of the most visible pieces of the average portal page (such as the header and footer). For this reason, it should be configured to be as fault-tolerant as possible.

A common misconception is that Publisher is a single, self-contained application that must be load balanced to achieve fault tolerance in the infrastructure. In reality, there are really four separate pieces to Publisher, each with unique characteristics and fault tolerance configurations.

Name	Description	Target Audience	Can be redundant?
Publisher Application	This is the publisher application itself that drives Publisher Administration and Explorer, where Administrators create, edit, schedule, approve, preview, and publish actual content. Once content is published, it is moved to the Published Content server.	Admins	Not easily
Workflow	This is the workflow engine that moves Content Items through predefined workflows on their path to publication.	Admins	Not easily
Publisher Redirector	This is the part of Publisher that the portal connects to when retrieving Published Content. style='mso-spacerun:yes'> Essentially the portal sends the portlet ID to a published_content_redirect.jsp page, which looks up the location for the published content and issues a redirect back to the portal.	End Users	Yes
Published Content	Once the portal gets the redirection from the redirector, it issues another HTTP request to the Published Content web server, which is essentially a web server that sits in front of a file system that contains all the HTML and other content produced by Publisher.	End Users	Yes

The traffic flow is shown below; in general:

1) The portal goes to one or more Redirectors, which issues a redirection back to the portal.

2) The portal then issues HTTP requests to one or more Web Servers

3) The Web Servers retrieve the content from the file systems (either local or a NAS)

Also included in this diagram is how Publisher publishes content:

A) When new content is being published, Publisher can only write to a single file system or FTP server.

B) Some sort of mechanism needs to be implemented to synchronize the published content from one file system to another (if there are two). If the file system is actually a NAS, both Web Servers can be configured to point to the same file system location, since redundancy is already built in to the File System.

Because the number of End Users vastly exceeds the number of administrators, and content administration is not as mission-critical as actually displaying the content to hundreds or thousands of users, it really is only critical to set up the redirector and the Published Content itself in a load balanced/fault tolerant fashion. We’ll discuss configuring each of these in upcoming posts.