Table of Contents
The portal architecture as described above does not include a Content Management System (CMS) yet. The reasons are two-fold:
The first try to integrate a CMS ran into problems in the areas of security and programming language. The goal was to use the CMS for "content type" things in the portal, e.g. FAQs and messages. Unfortunately the API of the CMS used Perl and the portal itself used Java. This was not the only problem: The portal used instance based authorization while the CMS (especially the authoring subsystem) used a type based authorization.
Example 8.1. Authorization between portal and CMS
Most CMS require every piece of content to have a "type", e.g. "message" with an associated schema describing it. The authorization subsystem of the CMS can only associate either types with roles or specific instances of types with roles. In the case of type based authorization every member of a certain role gets access to all instances of a content type - not what a portal usually requires e.g. if messages should be private between a client it ITS advisor. On top of this, authentication mechanisms need to be compatible between portal and CMS as well.
The experiences with a portal built on Application Server technology alone have shown that a CMS has certain advantages:
better handling of content fragments and caching. Caching needs to be built from scratch in an application server based portal.
a complete authoring environment for pure content (e.g. FAQ, messages)
a permission based automatic workflow and release process allowing business users to control the portal content to a certain degree. This is not possible in a JSP based personalized portal.
a defined way to add meta-information to pages (later used to better mine site stats.
usually also automatic separation of navigation and content, supported by tooling.